Hi Paul, Le 25/04/2016 12:29, Paul Jakma a écrit : > On Thu, 21 Apr 2016, Donald Sharp wrote: > >> Lou - process for getting them applied and out? >> >> Bugfix release in 2-3 weeks make sense, just needs process >> >> Donald - Apply crash fixes to master and have Martin test >> Martin - another branch or master? >> >> Donald - prefer master rather than branching? >> >> Lou - should this use branching strategy laid out previously? >> >> Additional branching was Paul's desire >> >> Prefer to do what makes sense > > The idea was to be able to track the status of patches. Patchwork isn't quite > foolproof. So, getting proposed patches into git may help. Proposed patches > couldn't directly go on to master, as we can't rewind master, so it had to be > another branch. > > How will status be tracked? What will determine whether a patch is 'bugfix > only' to go directly onto master and what should be queued? > > The problem we had in the past was a sense that those with direct commit > access could get stuff in faster, and they weren't as motivated to provide a > reliable process for others as they didn't have to follow that same process. > > How will we avoid that issue? As propose before, Gerrit could be a good candidate. You could send easily your patch to gerrit for contributors, and for reviewers easily review the code. Both reviewer and contributor could amend the code without the necessity to re-submit a new patch or a patch of patch of patch ... Once happy with a patch, you add a '+1' to it. Once the code reach a certain level (I think it is configurable but not sure) the code is automatically merge into the master.
Now, I understand that it is a new process for everybody and need some effort to setup a gerrit server. > >> Donald - Process has become so slow it appears that we'll never get >> caught up >> After the 100 patches pending, another 250 pending > > I've traded some emails briefly on this with you. > > The issue is growing numbers of people trying to work on the same bits of > code. Everyone wants their own code in fast, but wants to be able to review > other people's contributions and be able to object. > > Wider discussion to be had. One aspect is making the actual commit process > faster: > > - More people involved to spread the load, find and squash > person-specific habits, and avoid burn-out. I was hoping we'd have had > more people involved and passed the 'patch herder' role around a bit > more quickly by now. With Gerrit many maintainers / reviewers could check the patch and add a '+1' to the request. You could add easily simple 'code reviewer' people who don't need to take also a maintainer role that could afraid some of them. > > - While part of the answer is optimising the commit side, another part > of the problem is the RTTs induced by having to build shared > understandings, and deal with nits. So, undoubtedly, part of the > solution in getting patches in faster lies in contributors putting > more effort into pre-empting those RTTs. Yes agree. Again, as with Gerrit you could amend a patch, the process will be easier avoiding to rebuild entirely the patch. > > - Better commit messages, that do more to explain motivation, > implementation and results - so that reviewers don't have to start a > conversation on that, and so those RTTs are avoided. Yes agree. Perhaps some rules could be added in the Hacking.txt. For example, maximum modified lines/files per patch ... to help contributor to split their patch (i.e. how many 'git commit -s' are necessary). > > - Engage with comments early. > > regards, Regards, Olivier
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
