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?
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.
- 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.
- 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.
- Engage with comments early.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"Pay no attention to the man behind the curtain."
-- The Wizard Of Oz
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
