[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.

[Alon Bar-Lev]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>
> Sent: Friday, December 21, 2012 12:15:13 AM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Michael Pasternak" <mpastern at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Thursday, December 20, 2012 11:42:37 PM
> >> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >> the new feature discussion/implementation.
> >>
> >> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
> >>>
> >>> Hi All,
> >>>
> >>> In many cases OSS maintainers not always can be in the loop of
> >>> different threads what may
> >>> cause them missing important decisions being taken,
> >>>
> >>> As result later on during reviews of the patches they're not
> >>> accepting (already implemented)
> >>> features, what is causing not once for feature to be re-designed
> >>> and/or delayed, what is wrong
> >>> from the development cycle PoV.
> >>>
> >>> Therefore I'd like to suggest establishing dev-rules for the new
> >>> feature implementation,
> >>> what will make entire process much more easer for all of us:
> >>>
> >>> 1. discuss new feature on the mailing list
> >>> (requirements/constraints/etc.)
> >>> 2. summarise feature details in feature-doc
> >>> 3. send feature-doc to review to:
> >>>      3.1 ML (engine-devel)
> >>>      3.2 MG (mailing group of maintainers of the relevant layers)
> >>> 4. after feature-doc is accepted,
> >>>      4.1 implement the feature
> >>>      4.2 send it to gerrit for review to:
> >>>          4.2.1 lead maintainer/s (they will review/delegate it)
> >>>
> >>>
> >>> NOTE 3.2, 4.2.1 will require defining MGs such as:
> >>>         - engine-devel-core
> >>>         - engine-devel-ui
> >>>         - engine-devel-api
> >>>         - engine-devel-sdk
> >>>         - engine-devel-cli
> >>>         - engine-devel-vdsm ...
> >>>
> >>>
> >>> Thoughts?
> >>>
> >>
> >> i thought this is what we have the arch mailing list for, since
> >> any
> >> feature is going to cut through multiple layers/components, unless
> >> they
> >> are very specific, they should be sent to arch, and all
> >> maintainers
> >> should follow arch.
> >
> > What is missing is upstream bugzilla.
> >
> > A feature, after initiate stage should be represented with a bug.
> > The bug should be assigned to the right designated milestone.
> > All document references (including versions) should be attached or
> > referred by the bug.
> > Dependency between features can be established using bug
> > dependencies.
> > Status can be acquired from buzilla at any time, progress reports
> > should be input into bugzilla.
> > Contact details for the feature can be acquired too, relevant and
> > interested parties can be CCed explicitly.
> > I guess I can add more benefits.
> >
> > Mailing list is good for idea initiation, but not for lifecycle
> > management, nor for people to join at implementation phase and
> > understand why, how and when.
> >
> > Having upstream bugzilla will also help us plan ahead, and manage
> > the break the project into smaller components, to assign core
> > developers for each.
> 
> it still won't help tracking all relevant maintainers from rest api,
> ui,
> engine, vdsm saw the bug. we have multiple components.
> arch is mostly to cover cross component issues, such as features.
> (or we could create a feature mailing list).

Yes it is... for project width feature you have parent feature of the whole distribution and blockers for each component.

> but i do agree we could use bugzilla for tracking features per
> version,
> if wiki isn't tracking this correctly.

wiki is not the right tool for release engineering.

Regards,
Alon