[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 12:01:25 PM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/23/2012 11:39 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 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.
> 
> how possible you will loose them? adding mailing-group/s of
> maintainers does *not* mean
> excluding the mailing list itself ...

So why do you need the group?
I don't understand... maybe provide another projects that works this way?

> 
> anyone that is interested in discussion can still follow it.
> 
> > 
> > Maintainer is not someone who is more important the contributer, he
> > just has commit access.
> 
> i do agree about maintainers not being "more important" than
> contributor, but for sure maintainers have more
> experience with the projects and planned stuff, so they can drive
> features to the right direction ...
> 
> > 
> >>
> >>> 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.
> 
> Alon,
> 
> i think you missed the point, read my answer ^ above, + entire thread
> was started,
> to make sure maintainers explicitly got involved in to design of the
> features and
> not changing it when the code is written (what for sure will make
> contributors frustrated)
> 
> > 
> >>>
> >>> 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
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
>