[Nix-dev] On nixpkgs and reasonable code size

[Adrien Devresse]

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160224/a8b226df/attachment.bin