----- Original Message ----- > From: "Michael Pasternak" <[email protected]> > To: "Itamar Heim" <[email protected]> > Cc: "Alon Bar-Lev" <[email protected]>, "engine-devel" > <[email protected]>, [email protected] > 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" <[email protected]> > >>> To: "Michael Pasternak" <[email protected]> > >>> Cc: "engine-devel" <[email protected]> > >>> 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 > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
