----- 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 11:28:13 AM > Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new > feature discussion/implementation. > > On 12/23/2012 11:07 AM, Alon Bar-Lev wrote: > > > > > > ----- 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 not about of including everyone in mailing-group, but > maintainers, > and you always know who maintainers are.
I am sorry, but this is not "open" discussion. You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them. Maintainer is not someone who is more important the contributer, he just has commit access. > > > This is very different from proprietary. > > Also, features can be cross component / cross products / cross > > projects. > > the one who implementing the feature knows what layers he is > touching, > and can trigger relevant mailing-groups (this way feature owner does > not > have to be aware of actual layer/s maintainers) Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute. If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses. All discussions should be made in public, this is burden but also opportunity. > > > > You can have default CC in bugzilla for the people you do know, but > > you must enable other people to subscribe. > > i'm not talking about bagzila, but the standard process of > introducing new > feature, - e.g discussion cannot take place in the bugzila (it's a > tool to summarise the feature, etc.), > but i'd like to male sure all relevant maintainers get involved in > feature design/discussion > before it get written and not only when they have to review the code, > and mailing-groups is a > right tool for that in my view. > > > > >> > >>> 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 > >> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
