[Nix-dev] bash updates

[shea at shealevy.com]

> Hi Shea,
>
>  > Is there any reason we can't just do a full merge?
>
> who is "we"?
>

I haven't been around long enough to have been here for the last
stdenv-updates merge, but if I were handling it it would go something like
this:

1. Enable building the full release.nix on stdenv-updates, not just
release-small
2. Those who care about/maintain the major packages that aren't part of
stdenv (e.g. kde, xorg, etc.) test, fix problems that are in their domain,
and report problems that are errors in stdenv. This might entail updates
of packages
3. Those who care about/maintain the packages in stdenv (not just those
that have been updated, but all of them) respond to the reported problems
while trying not to add new features, use newer versions, etc. unless
absolutely necessary
4. When the major package maintainers are satisfied and hydra can
successfully build a similar set of packages as those that build on
current trunk, we merge back in

So in that scenario, "we" is anyone who cares about the packages in stdenv
or the major packages. That's a large subset of our devs, but I think
that's appropriate when we're completely changing our entire system. Of
course, I will probably not be handling the merge (though I'd be willing
to if people wanted me to), so the process may be completely different
than what I outlined.

>
> I, for one, don't want to be responsible for that task. I'll happily
> merge those parts of the branch that I know and that I can test, but I
> don't want to debug code that I don't use and that I don't know anything
> about, i.e. all of KDE.
>

 I think we'll need to hear from those with the standing to make this kind
decision, but certainly no single maintainer should be expected to test
and debug the entire affected code base for this kind of change.

~Shea

>
> Take care,
> Peter
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>