[Nix-dev] Again: Why don't these people have commit access

[Marc Weber]

> Marc I think it's the general case of more complex PRs. PR that change too
> much or add too much tend to be delayed. Not only because they are harder
> to test, but also harder to agree on by more peopl
Well - I did take care - I added the new cups version as "opt-in".
It was your choice. You were free to keep using the old one.

I think history is history.. we should talk about the future which also
might affect guix (http://www.gnu.org/software/guix/)

In the Vim community people leave over and over again because patches don't get
accepted or are not taken care of. Just about 2 days ago there was another case.

I think that being able to use nixos as desktop system (which implies being
able to print) should be a high priority.

We also have a new situation compared to "back in the old SVN days":

  _We have releases_

Thus breaking stuff is still bad, but maybe less bad than before.
The problem is: We all need stable systems - thus if everybody uses the "stable"
systems nobody is going to use the less stable - thus less testing will happen.

But let's talk about a specific case: My patches to apache httpd module:
  https://github.com/MarcWeber/nixpkgs/commit/7cdeb3f63ee1e26b6113754995284c56257ef162

The apache one breaks the API because I don't want to mess with port stuff
(to not mess with .htaccess) so I just created my own loopback device ..

Figuring out how to patch this in a backward compatible way was something I
could not afford.

My current situation is that I update my system only once every couple of weeks
because I cannot afford recompiling everything over and over again.


> Just to say, it's not lack of trust, or being negative. It's lack of time
> (or platform) for proper testing and lack of time for proper understanding
> (linux is becoming too giant) the consequences of a change.
Well - NSA cases and the one fosdem video (what would I do If I had one million $ and
if it was my task to compromise the world ..) was fun to watch:
http://video.fosdem.org/2014/Janson/Sunday//NSA_operation_ORCHESTRA_Annual_Status_Report.webm

Thus to truly improve you also have to start measuring who reviewed commits
to maximize value by spent time - and that not only for nixpkgs but also for
projects like openssh.

There is no way to ensure that an update will not cause a random failure
on hardware X which will happen only once a month.

One huge benefit from having "commit" access would be that "experimental or
complicated" stuff could be submitted as topic cranch to increase visibility
and that other people can join such effort and help taking it to a level where
it can be merged. I love topic branches because they use two files:

.topmsg
  => The commit message which would be created when all commits got collapsed.
  The nice thing is that each branch documents its purpose on its own.

.topdeps
  A list of other branches it depends on

Then there is a tg update command to merge with all dependencies and a tg
export command to collapse in order to yield a nice commit which can be
reviewed more easily.

The wiki contains a longer introduction. I don't say topgit must be used.
But I highly recommend having such topic specific file documenting the purpose
of a branch

That's another story: do we want many "official experimental topic branches?"

Making experimental branches visible to others would improve collaboration a
lot.

Marc Weber