[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
Alon Bar-Lev
alonbl at redhat.com
Fri Dec 21 11:57:05 UTC 2012
----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> Sent: Friday, December 21, 2012 12:44:51 PM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>
> On 12/21/2012 12:15 AM, Itamar Heim wrote:
> > 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.
>
> this is why i'm suggesting creating mailing-groups peer component,
> feature owner knows what layers are involved and should be
> responsible to CC
> relevant MGs in both BZ & thread.
mailing group is something nobody can manage.
you can consider a group as all people who are CC to a bug.
>
> > (or we could create a feature mailing list).
>
> ML/MG peer feature is too much i think.
>
> >
> > but i do agree we could use bugzilla for tracking features per
> > version, if wiki isn't tracking this correctly.
>
> +1
>
>
> --
>
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
>
More information about the Engine-devel
mailing list