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

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

you can consider a group as all people who are CC to a bug.

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