----- 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 12:01:25 PM > Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new > feature discussion/implementation. > > On 12/23/2012 11:39 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 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. > > how possible you will loose them? adding mailing-group/s of > maintainers does *not* mean > excluding the mailing list itself ...
So why do you need the group? I don't understand... maybe provide another projects that works this way? > > anyone that is interested in discussion can still follow it. > > > > > Maintainer is not someone who is more important the contributer, he > > just has commit access. > > i do agree about maintainers not being "more important" than > contributor, but for sure maintainers have more > experience with the projects and planned stuff, so they can drive > features to the right direction ... > > > > >> > >>> 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. > > Alon, > > i think you missed the point, read my answer ^ above, + entire thread > was started, > to make sure maintainers explicitly got involved in to design of the > features and > not changing it when the code is written (what for sure will make > contributors frustrated) > > > > >>> > >>> 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 > >> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
