----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "engine-devel" <[email protected]>, "Michael Pasternak" > <[email protected]> > Sent: Friday, December 21, 2012 12:15:13 AM > Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new > feature discussion/implementation. > > 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. > (or we could create a feature mailing list).
Yes it is... for project width feature you have parent feature of the whole distribution and blockers for each component. > but i do agree we could use bugzilla for tracking features per > version, > if wiki isn't tracking this correctly. wiki is not the right tool for release engineering. Regards, Alon _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
