[Nix-dev] On nixpkgs and reasonable code size

[stewart mackenzie]

On 23 Feb 2016 23:08, "Matthias Beyer" <mail at beyermatthias.de> wrote:
>
> On 21-02-2016 15:28:08, Bjørn Forsman wrote:
> > On 21 February 2016 at 15:17, zimbatm <zimbatm at zimbatm.com> wrote:
> > > tl,td; I think that we should split nixpkgs/pkgs in two
> >
> > Another way to do it is the Linux kernel way. Instead of splitting the
> > (git) repository in two (or more) pieces, split _maintenance
> > responsibility_ into a hierarchy. This is opposite to the flat
> > responsibility model NixOS development use today.
>
> I completely second this. The problem is IMHO _not_ that the repo gets big
> (there are other repos which are way, way bigger than nixpkgs) but the
> development model. AFAIK I said that before on this list. The problem is
that
> everyone who wants to be a contributer gets push access to master. It just
> screams at you "I won't scale"!

Splitting isn't needed. Nix is lazy, editors search, github searches.

Refactor the current dev process such that this becomes easier to
implement: http://rfc.zeromq.org/spec:22

Evidence: http://hintjens.com/blog:93

This is a falsifiable process, it follows the scientific process. What have
we got? Something that doesn't work. Fork C4, document it, evolve it. Let
others learn from it.

I was shot down for suggesting this, I think there were 300 PRs at that
stage, only to have quite a few people message me off list saying I can
ping them directly to merge quickly. This is an even greater sign of a
broken process, it's also the reason why I have pretty much stopped
contributing to nixpkgs.

Can we:
* stop releases and go for a rolling release.
* roll stable and unstable into HEAD.
* follow eelco's advice: nixpkgs env var supports urls
* if you've contributed 1 or more pkgs then you are immediately invited to
become a maintainer.
* everyday we could hit 0 PRs, there should be this ravenous hoard of
maintainers hitting the merge button.
* don't like the merged code? Fix it with another PR. Treat the code like a
well run wiki (not our wiki... which is now-read-only-not-wiki :-) )
* don't dwell on finding consensus in PRs just merge it and fix mistakes
with more PRs.
* seek advice from expertise *and* the people your decision affects, as a
way to sidestep a hierarchical structure and full consensus. Don't go the
way of linux, don't do consensus.
* if we can get this process right, our wiki will come alive and surpass
Arch.

I cross one leg over, raise my arms parallel with the ground and let my
neck go loose, then gently turn my palms skywards.

Let the shooting begin.

/sjm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160224/96085f8c/attachment.html