On 17-02-07 20:38:58, Ricardo Wurmus wrote: > > Hi Pjotr, > > during the panel on the Future of Guix we all agreed that there is a > need to lower the barrier to entry for package submissions to Guix, so > it is good to start a discussion about actionable steps we can take to > make this happen. > > > After yesterday's FOSDEM discussion I propose to set up a 'Guix > > incubator' git tree using Gitlab. The master branch will track the > > main Guix master but project can run on forked trees and branches. The > > idea is to have patches prepared by new committers or by people who > > simply prefer to use a web-based git environment. Each of these trees > > can become a guix channel - once we have channels to support that. > > During the panel we had a question from the audience about alternative > tools, e.g. to allow a workflow that is not email-based. While I can > understand the desire to use a workflow that you may be used to from > other projects (this goes both ways) there is a danger in establishing > alternatives to the channels on which we accept contributions. > > At this point in the evolution of Guix we have many more contributors > than people who can mentor the contributors, polish their patches for > inclusion upstream, or provide constructive comments. Having so many > people contribute is great! But it also means that we need to be > careful with our limited number of mentors. > > I see two possible outcomes of establishing an additional “incubator” > repository: it might fragment our review community as some people will > try to upstream incubator patches and others handle mailing list > patches; another outcome is that the incubator never gets accepted by > reviewers and mentors because it is more work, leading to growing > parallel infrastructure and second-class code. Neither of these > outcomes is desirable in my opinion. > > > It won't hamper the normal process since ready patches still get > > compiled and submitted through the mailing list (ML). In fact it may > > help scale the review process by getting peer reviewers involved. The > > idea is that we have an incubator environment before the ML which > > allows for playful learning and tracking of patches that may (or may > > not) make it into main line. I think it is very important to have a > > low barrier to entry when it comes to submitting package recipes. > > I appreciate your desire to reduce the work load of reviewers/mentors on > the mailing list. I have some doubts about whether this approach would > be feasible, though. There already *are* external repositories outside > of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as > your own “genenetwork/guix-bioinformatics” repo or the MDC’s > “guix-bimsb”) or as forks of Guix (e.g. public versions of what most > Guix developers do locally to add packages). I have not seen any > concerted efforts to upstream package definitions from either of these > classes of repositories. > > This makes me wonder if the presumed benefits of an incubator could > actually be realised. I would like to advise against recommending an > “incubator” procedure like this as an official alternative to > submissions to the mailing list. > > Our workflow involving the mailing list is far from perfect. We had > further discussions over post-FOSDEM dinner and drinks and there seemed > to be consensus among the people present (including long time > contributors, reviewers, and successful mentors) that it would be a > great improvement to keep track of package contributions in a separate > Debbugs instance (e.g. one “bug” per package submission). It gives us a > way to track the state of things more easily, it accomodates people who > prefer to use a web browser, it permits us to continue to use email, and > it doesn’t force yet another account onto submitters. > > Admittedly, the web interface that Debbugs comes with is kinda bland and > hard to use, so a second step would be to develop a better UI frontend > to Debbugs that would be closer to what people expect from an issue > tracker. > > This was discussed before at > <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00140.html> > and we could request a separate Debbugs instance for > “guix-packa...@gnu.org” *right now* if we wanted to. > > What do other people think about this? > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > >
The here mentioned debbugs solution would work now and it would have an immediate effect. I really welcome this solution as a first step to try out alternatives and I would make use of it. Regarding the approach Pjotr suggested: would it be like https://wiki.gentoo.org/wiki/Gentoo_Github ( See also: https://wiki.gentoo.org/wiki/Gentoo_Github#See_also ) ? I do share the voiced concerns - there are little reviewers, and while the situation with reviews is bad it is really a people problem. Tools can improve access for newcomers, but they won't fix the reviewers > patches ratio. Here are further ideas to motivate newcomers: We regulary get questions on HOW to start and WHAT to use (for contributing) etc. Okay, improving upstream documentation would be ideal, but until then we can have a better "get started contributing to Guix" section, and maybe a link on the website to this (we already kind of have), Encourage to read the open bugs (point to a "low hanging fruits" list of bugs and things to do around Guix), and even more get people to review through encouragment and ...stuff... (kind words, etc etc). Goodnight! -- ng0 -- https://www.inventati.org/patternsinthechaos/
