[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>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

> > But stdenv-updates isn't meant as a really big topic branch. It's
> > meant as a place for changes that will require rebuilding the system,
> > so we can minimize the number of times we require that. How does git
> > help with that?
>
>Suppose that I modify GNU Make, for example, then that change ought to
>go into stdenv-updates. At the same time, you modify glibc, and that
>change goes into stdenv-updates, too. But those two changes are
>orthogonal. They don't depend on each other. So why should they be
>checked into the same branch? There is no conceptual reason to do that.
>Rather, there is a practical reason, namely the fact that creating two
>new branches for those two changes -- a.k.a. topic branches -- would be
>unfeasible with SVN.

If it were, creating stdenv-updates per se would be infeasible.

>When using Git, that restriction no longer exists. I can create a branch
>stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra
>could build both of them (in fact, Hydra would probably build all
>stdenv/* branches). In that scenario, other users are free to merge the

No. The space required could grow too fast. It was stated many times 
that Hydra jobsets will only be created by people running Hydra.

>contents of either branch into their personal "master"; they can choose
>whether they want to have the latest gnu make or the latest glibc or
>both. When both changes are checked into one monolithic stdenv-updates
>branch, however, doing that is not so easy.

The problem is a packaging problem, not version-management one. If you
update Make, a lot of packages break. If you update glibc, a lot of 
packages break. Some packages break only when you update both at once
(nobody knows how they manage this). 

Also, you want to minimize big rebuilds. 

Note how stdenv-updates really goes: we update _many_ things at once,
and then fix the bugs that show up with all the latest things. If we 
create small topic branches, we have a large risk of spending duplicated
effort fixing many things on many topic branches, then merging some of 
the topic branches together and fixing more things that depend on
combinations of versions, finding out the old fixes make things worse,
and so on. 

>Eventually, you decide that the new glibc is stable, and then you run
>"git merge stdenv-updates" on whatever happens to be your equivalent of
>the official master branch, and then you push the changeset upstream,
>which effectively makes them "stable" for everyone. The merge commit
>would even record the fact that you worked on a topic branch prior to
>that, and the history of that branch would become visible in "master",
>too.

Right, and the "make" change keeps hanging. So we are worse off than 
now, because we get two stdenv rebuilds.

>The workflow is not completely different from what we are doing now, but
>the granularity is much higher. There isn't just one stdenv-updates
>branch. Rather, there are many of them.

Any update will require lots of fixes. So, it is better to have one
stdenv branch, not ten 50%-broken branches.

And by the way, having all glibc-update branches called the same even
keeps the problem with Git history.

>Basically, all branches except "master" are considered unstable, i.e.
>work in progress. When they have become stable, though, then they are
>pushed into the master branch.

For packaging, notion of stable cannot be preserved across merges with
any kind of confidence..