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