----- Original Message ----- > From: "Michael Pasternak" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "engine-devel" <[email protected]>, [email protected], "Itamar Heim" > <[email protected]> > Sent: Sunday, December 23, 2012 8:25:23 AM > Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new > feature discussion/implementation. > > On 12/21/2012 01:57 PM, Alon Bar-Lev wrote: > > > > > > ----- 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. > > why?, we do not have many layers in the system, creating: > "engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm, > node" > mailing groups will do the trick.
Because in open source you don't know who is actually out there. This is very different from proprietary. Also, features can be cross component / cross products / cross projects. You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe. > > > you can consider a group as all people who are CC to a bug. > > CC'ing people manually can't guarantee that all relevant people will > be included in the email (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 > >> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
