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

> 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