> 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/[email protected]/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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
