[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
Michael Pasternak
mpastern at redhat.com
Sun Dec 23 10:27:25 UTC 2012
On 12/23/2012 12:16 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern at redhat.com>
>> > To: "Alon Bar-Lev" <alonbl at redhat.com>
>> > Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>> > 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 at redhat.com>
>>>> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> > >> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>> > >> "Itamar Heim" <iheim at redhat.com>
>>>> > >> 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 at redhat.com>
>>>>>> > >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>>>> > >>>> "Itamar Heim" <iheim at redhat.com>
>>>>>> > >>>> 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 at redhat.com>
>>>>>>>> > >>>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>>>>>> > >>>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
>>>>>>>> > >>>>>> <engine-devel at ovirt.org>, arch at 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 at redhat.com>
>>>>>>>>>>> > >>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>>>>> > >>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>> > >>>>>>>>> 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?
please see very first email of this tread, you will see there that suggestion
works like this:
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)
(3.1 answer your concerns from the previous email)
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
More information about the Arch
mailing list