[Nix-dev] Reminder about nixpkgs branches

[Vladimír Čunát]

>> On 07/23/2014 11:29 AM, Mathijs Kwik wrote:
> If stuff causes regressions, revert it and move it to a feature-branch
> to debug.

Perhaps. I'm not very clear about that. Typically I first try to fix the 
regressions within days, if possible.

Note that this revert+move workflow tends to hit a problem with unclear 
semantics of reverts+merges. The catch is that in the case of 
*temporarily* undoing some changes, people typically understand revert 
the other way than practically all VCS (including git), which leads to 
surprises. IMO it's also connected to being state-centric instead of 
(arguably more natural) change-centric approach.

Details: 
https://raw.githubusercontent.com/tonyg/revctrl.org/master/output-raw/Rollback


> A minor llvm upgrade should just go into master or staging.

Yes, these shouldn't break anything. BTW, from X stuff only mesa 
directly depends on it AFAIK, and it is typically among the first to use 
new major llvm updates. It's other "less hot" packages that often need 
to lag behind on older llvm versions.


> 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. [...]

I was just clarifying the situation. Some of the changes in x-updates 
would in fact rather belong into staging, as they are often just minor 
updates.


> 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.

Ah, I see... yes, for really disruptive things like new gcc branch. 
(Like we do have gcc49 in master, but nothing uses it yet, and even 
stdenv doesn't build with it.)



On 07/24/2014 11:52 AM, Mathijs Kwik wrote:> Vladimír Čunát 
<vcunat at gmail.com> writes:
>> Extremely short (<1 week) one-topic branches may seem ideal, but
>> currently they're very impractical, for several reasons:
>> [...]
>>
>> 3) Sure I want features stabilized fast, but wishing it isn't
>> enough. [...]
>
> I don't see how this would become worse by having smaller
> feature-branches. [...]

No, (3) wouldn't be worse. Maybe just because of (1) being more 
time-consuming to test/stabilize updates one-by-one.


Vlada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140724/1bb5b5a9/attachment.bin