[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 11:28:13 AM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- 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 not about of including everyone in mailing-group, but
> maintainers,
> and you always know who maintainers are.

I am sorry, but this is not "open" discussion.
You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them.

Maintainer is not someone who is more important the contributer, he just has commit access.

> 
> > This is very different from proprietary.
> > Also, features can be cross component / cross products / cross
> > projects.
> 
> the one who implementing the feature knows what layers he is
> touching,
> and can trigger relevant mailing-groups (this way feature owner does
> not
> have to be aware of actual layer/s maintainers)

Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute.

If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses.

All discussions should be made in public, this is burden but also opportunity.

> > 
> > You can have default CC in bugzilla for the people you do know, but
> > you must enable other people to subscribe.
> 
> i'm not talking about bagzila, but the standard process of
> introducing new
> feature, - e.g discussion cannot take place in the bugzila (it's a
> tool to summarise the feature, etc.),
> but i'd like to male sure all relevant maintainers get involved in
> feature design/discussion
> before it get written and not only when they have to review the code,
> and mailing-groups is a
> right tool for that in my view.
> 
> > 
> >>
> >>> 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
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
>