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

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.

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