[Nix-dev] Reminder about nixpkgs branches

[Mathijs Kwik]

Vladimír Čunát <vcunat at gmail.com> writes:

> Hi,
> it's not at all so bad as it used to be. Last year it happened we had
> ~10 months running stdenv-updates that was in the middle getting more
> and more breakages with added commits. That wasn't good and all agreed
> on that.

I'm glad things currently go a lot smoother.
I wasn't trying to point any fingers, just to remain aware of the issues
that caused that situation.

>
> Extremely short (<1 week) one-topic branches may seem ideal, but
> currently they're very impractical, for several reasons:
>
> 1) Testing several changes at once is typically much easier than
> testing one-by-one, both in build-time and testing-by-using time.
>
> 2) Most people can't manipulate Hydra jobsets (including me), which
> would be needed for each mass-rebuilding update.

I can see how this is an issue indeed.

>
> 3) Sure I want features stabilized fast, but wishing it isn't
> enough. Moreover, how much a mass-rebuild change is potentially
> destabilizing can be tricky to estimate. For example, with freetype I
> tested building my whole system, including KDE, xfce and several gtk3
> apps, and still I didn't discover dozens of build regressions until
> Hydra tried building all. Those took me a few whole days of work to
> fix.

I don't see how this would become worse by having smaller
feature-branches. Something like a freetype-upgrade or fonts-handling
branch would quickly show which packages break. Of course that's
provided hydra wants to build the branch for you indeed.


>
>
> On 07/23/2014 11:29 AM, Mathijs Kwik wrote:
>> - staging hasn't been merged for > 2 weeks
> That's good, as there are quite a lot of build regressions ATM.

Then they should not have been in staging. Eelco's original email about
staging clearly stated staging should be mergeable into master at any
time and is only meant to get hydra up to speed so the channel won't lag
for days on large rebuilds.

If stuff causes regressions, revert it and move it to a feature-branch
to debug.

>
>> - big long-running x-updates branch  [...]
> This iteration of x-updates runs for about 5 weeks now (since June
> 16), which isn't so terribly long. Also, note that it started *before*
> the staging branch was even announced (~week after that), so I was now
> finishing it in a-kind-of old-style workflow.

Ah, that's quite short indeed :) Please remember, I wasn't pointing
fingers. I'm fine with x-updates. Having staging around doesn't change
anything in this regard. The changes in x-updates deserve their own
branch. I was just worried about x-updates becoming a bit more than just
core X11 stuff (mesa, freetype, xorg). IMHO stuff like qt / gtk should
not get into x-updates but straight to staging (minor upgrades) or a
separate branch (larger upgrades).

>
> Note that there are no added stuff in x-updates like
> enlightenment. That got merged in from master and needed a fixup after
> x-updates changes.

I probably didn't look well enough then. Sorry for the noise.
>
>
>> - upgrades that will probably break stuff
>>   - add the new version to master
>>   - users and maintainers can try if their packages work with it
>>   - change the default in a separate branch (ex: gcc-upgrade)
>>   - or change the default and pin breaking packages to the previous
>>     version
>
> I don't remember agreeing on anything like adding updates as new
> versions instead of changing the old one (maybe I misunderstood
> you). I rather think it would tend to create a high version bloat
> (think ffmpeg and worse), as maintainers will rarely be so responsive
> to update the dependency to newer.

The discussion was about llvm that time. And I believe it happened
before with gcc in stdenv-updates. There really is no reason to not get
a new LLVM version in master, just because some X stuff uses it.

A minor llvm upgrade should just go into master or staging.
If this potentially breaks X stuff, just add the new version and stick X
to the previous version. x-updates can then takes its time to work out
how to build against the latest version.

I do see the danger of having way too many versions around, so indeed we
should be careful about this. However, for non-x stuff like LLVM, I
don't see the logic in having users wait for some X stuff to stabilize.


All in all, the current situation is way better than it used to be and
I'm just nitpicking to find out how others think about this branching
stuff.

Thanks for your input,
Mathijs


>
>
> Vlada
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev