[***SPAM***] [Nix-dev] Re: new possible movement to git (?)

[Michael Raskin]

<1e1d23499a69570914f03bc0a196953a.squirrel at webmail.shealevy.com>
<87ei034yse.fsf at write-only.cryp.to>
<5833f9f3-bf70-4cae-9ad2-489170ad55ed at email.android.com>
<87ei03aw6p.fsf at write-only.cryp.to>
<894aedf1c3c6d28c2272e35ab266d932.squirrel at webmail.shealevy.com>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> > I don't think this accurately reflects the reasons we use
> > stdenv-updates. We don't put it all in the same branch because more
> > fine-grained branching is expensive, we put it all in the same branch
> > because we want the eventual merge of the changes to happen at the
> > same time.
>
>exactly who is "we"? Please speak for yourself. I, for one, do not want
>unrelated changes to be merged in one commit, because that habit breaks
>extremely useful tools such as "git bisect".

One commit and one branch are different things. 

>Besides, having many different stdenv/* topic branches does not imply
>that each of them must be merged into master separately. You *can* merge
>them all at once, of course, if you want to. It just so happens that I
>wouldn't want to do that because the practice violates elementary
>principles software engineering.

The problem is that actually merging them one-by-one is costly. Trunk
should receive one rebuild. And it is established practice to reduce
the count of stdenv rebuilds.

Also, there is little happening in NixPkgs that should be classified as
software engineering. Everything non-trivial in packaging is about 
finding out upstream quirks. 

To run NixOS, I need maximum amount of packages in stdenv-updates to be
non-broken. Tracking what is broken where across five topic branches is
insanity even without second-guessing what will start working on merge.