On Tue, 14 Jun 2016, Jafar Al-Gharaibeh wrote:
I see it happens a lot where the same fix is submitted over and over
again by different developers! we could use their time in better ways
:)
Clearing backlogs, and automating some integration work will go a long
way to speeding things up. There's still a good bit of work to do on the
backlog, but the end is hopefull in sight and things might go more
smoothly there-after.
Bug fixes should go into master within few days at the latest, no need
to hold them off. Maybe the first ACK should trigger such patches to
be queued up to go into master as soon as one of the maintainers get a
chance to do it.
Can you define 'bug fix'?
I'd love a way to be able to reliably and quickly sort contributions
into 'obvious quick bug fix' and 'other', but - and I've been doing this
a while - experience is that isn't always so easy. E.g., "big"
feature-add patches can sometimes be easier to get in than little 'bug
fixes', if the feature add is well-contained and doesn't affect other
code and the bug fix raises architectural issues.
As I'm fairly sure now that the required magic wand to fast-path
'obvious bug fixes' doesn't exist, I think the only way left is instead
to sift out the hard stuff and get it out of the way of blocking other
stuff. So everything goes down a common initial path, unless someone
gives it a 'kick' onto a slower path for whatever reason. Which implies
that speed requires optimising that common path.
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
When you go into court you are putting your fate into the hands of twelve
people who weren't smart enough to get out of jury duty.
-- Norm Crosby
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
