On Mon, 10 Oct 2016, Martin Winter wrote:

Not what the exact plans is, but I prefer either a release branch started now or new commits which are not only bug fixes to be held up for a week to let the code “settle” and give everyone time to test.

Ok, lets wait till the end of the week then.

But we should go back to a discussion on how this should be done. Personally, I would prefer to never ever have such a large “proposed” branch. Preferrably commits to master on a continuous way.

Well, of course. :)

I think Paul felt the pain very well and I’m curious what his suggestion is at this time on how to do this in the future.

Some systematic way to collect patches, wait for some sync point on reviews, integrate to master and repeat. On an X-weekly basis (X := 1 to 4). Regular releases, 3, 4 or even more / year - if we've got new fixes or features, we can always release. Long cycles just hurt.

- Systematic way to collect patches could be:

  * Patchwork (it has issues over longer time spans, but prob ok on
    short ones)

  * Bugzilla

  * automated list crawler and applier (I'd prefer not to put closed
    tools in the middle of this though)

  Nothing is perfect though.

  If I could figure out why git-bz doesn't work with a proxy on Fedora,
  I'd say bugzilla was the no-brainer. Sigh.

- Reviews: People just need to pitch in with reviewing. Contributors
  need to get on with addressing comments.

  Ask not what your open source project should be doing for you, but
  what you can do for your open source project.

- Sync point and integration may require some human intervention.

  From experience with this project and maybe another, it's good to have
  a specific named person on 'duty' (to avoid cracks for things to fall
  through) and with the duty period limited (to avoid burn-out, and for
  continuity/repeatability).

Then we find people willing and able, so: Comfortable with the tools. Willing to donate some time on inevitable integration monkey work (even with perfect tools, there will be some of this, inc. on contributors side). Willing to apply the patches and the review comments.

regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Clarke's Conclusion:
        Never let your sense of morals interfere with doing the right thing.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to