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

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, arch(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com&gt; 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(a)redhat.com&gt; >> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, arch(a)ovirt.org, >> "Itamar Heim" <iheim(a)redhat.com&gt; >> 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(a)redhat.com&gt; >>>> To: "Itamar Heim" <iheim(a)redhat.com&gt; >>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com&gt;, "engine-devel" >>>> <engine-devel(a)ovirt.org&gt;, arch(a)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(a)redhat.com&gt; >>>>>>> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>> 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.

> 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)

> > 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