[Nix-dev] On nixpkgs and reasonable code size

[Benno Fünfstück]

What I take from this thread is not that we need to enforce ownership (I
think it is right to say that the people committing to nixpkgs are cautious
to only commit to their own stuff), but rather that we need to document
this ownership better. Just a file, like chromiums OWNERS files could help
very much, since it makes clear who is responsible for this subpart and
also who makes the final decisions:
https://www.chromium.org/developers/owners-files.
Another reason that this is needed in addition to meta.maintainers is that
you have a person who is responsible for structural changes to this
subpart, which is not possible with the fine-grained maintainers system.
Also, the owners would probably more active nixpkgs developers and so
easier to reaxh than some random package maintainer who perhaps only
controbuted this particular package and has disappeared since then.

What do you think about this solution? IMO, it is very lightweight to
implement.

Adrien Devresse <Adev at adev.name> schrieb am Mi., 24. Feb. 2016 09:29:

> > I'm totally for that, but do note that there is an equivalent problem
> > in deciding who gets "PR approval" access. But, I suppose since we
> > control hydra/whatever and not github, we can roll our own logic like
> > allowing people to only approve PRs for automatic merging that affect
> > certain files / subtrees.
>
> Exactly.
>
> This is more or less what Fedora does through there fedpkg and pkgdb
> interface. Fedora maintainers can merge / modify only the packages they
> are associated with.
>
> You could easily transpose this to NixOS with something like :
>
> * Nobody has right to push master
> * The maintainer of a package can merge all incoming "hydra-built" pull
> requests associated with this package and nothing more.
> * New packages are reviewed and merged by a list of senior Nix-devs /
> maintainers for safety.
>
> And that's it.
>
> Again, this is nothing new. All others major distributions have a
> similar workflow.
>
> I'm convinced that the problem is more about "Who does what" than
> anything else, specially when I see how active the Nix community is.
>
>
> Adev
>
>
> Le 23/02/2016 17:13, Ericson, John a écrit :
> > And now this leads into my thread
> > https://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg18287.html
> > :).
> >
> > I'm totally for that, but do note that there is an equivalent problem
> > in deciding who gets "PR approval" access. But, I suppose since we
> > control hydra/whatever and not github, we can roll our own logic like
> > allowing people to only approve PRs for automatic merging that affect
> > certain files / subtrees.
> >
> > On Tue, Feb 23, 2016 at 7:12 AM, Matthias Beyer <mail at beyermatthias.de>
> wrote:
> >> On 23-02-2016 16:08:37, Matthias Beyer 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"!
> >>>
> >> Let me add: In my opinion, nobody should be able to push to master.
> Merging into
> >> master should be done either automatically (by a build-bot or something
> like
> >> this) or by a "merge this PR"-click in github, after some checks are
> succeeded
> >> (something like CI or lgtm.co (not proposing tools here but
> functionality)).
> >>
> >>
> >> --
> >> Mit freundlichen Grüßen,
> >> Kind regards,
> >> Matthias Beyer
> >>
> >> Proudly sent with mutt.
> >> Happily signed with gnupg.
> >>
> >> _______________________________________________
> >> nix-dev mailing list
> >> nix-dev at lists.science.uu.nl
> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>
> > _______________________________________________
> > nix-dev mailing list
> > nix-dev at lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160224/5434b0bf/attachment.html