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

[Alon Bar-Lev]

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> Sent: Sunday, December 23, 2012 8:25:23 AM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- 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.
> 
> why?, we do not have many layers in the system, creating:
> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm,
> node"
> mailing groups will do the trick.

Because in open source you don't know who is actually out there.
This is very different from proprietary.
Also, features can be cross component / cross products / cross projects.

You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe.

> 
> > you can consider a group as all people who are CC to a bug.
> 
> CC'ing people manually can't guarantee that all relevant people will
> be included in the email (thread).
> 
> > 
> >>
> >>> (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
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
>