[Nix-dev] Commit access

[Guillaume Maudoux (Layus)]

Le 29/02/16 18:28, Thomas Tuegel a écrit :
> On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra
> <eelco.dolstra at logicblox.com> wrote:
>> Then when you make a PR, you should look up the responsible maintainer and
>> assign the PR to them. Having every PR assigned to somebody should also help
>> prevent them from falling through the cracks.
> 
> If we split up the Nixpkgs repository, GitHub gives us this
> essentially for free. The main Nixpkgs repository has too much noise
> for me to subscribe to updates for Issues and Pull Requests, but it
> would be no problem for me to subscribe to such updates for the subset
> of repositories I maintain. Right now, Domen is doing an excellent job
> of managing the Pull Request and Issue trackers, but ideally, we would
> lift some of this work off him.
> 
> Now, we could easily take a hard line on Pull Request assignment by
> saying, "Your pull request will not be merged if you do not assign the
> correct person!" But, I don't think we want to do the same for Issues;
> it should be as easy as possible to open an Issue. If we split up the
> repository, it's much easier to ensure the correct people see every
> issue and pull request.
> 
> Regards,
> Tom
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

I understand the desire to split the work and the amount of
notifications that such a big repo generates.

But on the other hand, I like the ability to submit a pull-request that
adds a package, a NixOS module and documentation while also bumping the
version of some dependencies. It makes it clear that one bunch of
changes are related.

Having different repos brings the difficulty to make different
pull-requests related to the same idea, and to convince different
maintainers that the change is useful. At best it slows updates as the
pull-request for the module will have to wait for the PR of the package
to be merged. At worst, we could get inconsistent decisions about merging.

The ability to find all the project history in one place is a tremendous
feature for understanding and tracking issues.

It should be easy enough nowadays to filter events based on the changed
paths in a PR, or on the project/feature declared in the issue.
I however agree that it is difficult with the minimal issue tracker
provided by github.

Regards,
Guillaume.