Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.

----- Original Message ----- > > From: "Michael Pasternak" <mpastern(a)redhat.com&gt; > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, arch(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com&gt; > > 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" <mpastern(a)redhat.com&gt; >>> > >> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>> > >> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, arch(a)ovirt.org, >>> > >> "Itamar Heim" <iheim(a)redhat.com&gt; >>> > >> 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" <mpastern(a)redhat.com&gt; >>>>> > >>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>>>> > >>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, arch(a)ovirt.org, >>>>> > >>>> "Itamar Heim" <iheim(a)redhat.com&gt; >>>>> > >>>> 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" <mpastern(a)redhat.com&gt; >>>>>>> > >>>>>> To: "Itamar Heim" <iheim(a)redhat.com&gt; >>>>>>> > >>>>>> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com&gt;, "engine-devel" >>>>>>> > >>>>>> <engine-devel(a)ovirt.org&gt;, arch(a)ovirt.org >>>>>>> > >>>>>> 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" <iheim(a)redhat.com&gt; >>>>>>>>>> > >>>>>>>>> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>>>>>>> > >>>>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>>>>> > >>>>>>>>> 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?