Le 29/02/16 18:28, Thomas Tuegel a écrit : > On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra > <[email protected]> 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 > [email protected] > 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. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
