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 <vcu...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
