Paul,
On 6/15/2016 11:06 AM, Paul Jakma wrote:
> On Wed, 15 Jun 2016, Lou Berger wrote:
>
>> IMO we really need to get to a point where we have an active development
>> 'mainline' with CI and nightly regression. Every project I've worked on
>> since the 90s has had this and I'm sure many of us have this at least
>> internally. It dramatically reduces cost of integration, need for
>> rebasing, identification of problematic submissions, and other overhead
>> and bottlenecks....
> If someone wants to setup an auto-accumulating 'outstanding' head, e.g.
> by automatically applying the latest things in patchwork, that could
> help.
>
> The two fundamental aspects to work-flow are:
>
> a) the states a patch-set / contribution goes through
>
> b) the tools to track that state
>
> For a, the state machine is something like:
>
> proposed -> filtering -> review -> testing -> integration
>
> {filtering,review,testing} --[issues]--> pushed_back
>
> pushed_back ---[cause addressed]-->proposed
I think this is a little different than the proposed CE process, in
particular It has testing on contribution and anything that fails that
isn't even considered.
> For b, there's just mails on the list, private dirs with patch files and
> CVS working dirs (in the olden days), and lately patchwork. Or a bug
> tracker (ideally with good, but decoupled, tools for integration with
> the SCM). Or heads in the SCM.
Improved tooling is certainly a good enabler and I think this is being
discussed/covered in the google doc sent on list (I haven't had a chance
to read it yet...)
> Contributors could also try and raise the bar on making sure they have
> familiarised themselves with requirements and tried to address potential
> 'nits' in advance (e.g., commit messages, style, white-space, making
> sure contributions come in a series that tells a logical 'story' to aid
> reviewers, etc).
agreed.
> On 'rebasing', dealing with the backlog will reduce some of that. There
> are still issues though. In particular, "Design by coding behind closed
> doors", has the _biggest_ risk of having to re-do a lot of stuff later.
>
> Exploring solutions with code is one thing, but I'd encourage people to
> discuss architecture issues and questions here - *before* doing lots of
> coding. If you find yourself having an arch. related discussion
> internally on something, then probably you should have it here.
> Alternatively, accept that later on other people may have other
> opinions, and accommodate them - which may require re-doing code.
sounds reasonable.
Cheers,
Lou
> regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
