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

[Itamar Heim]

On 12/23/2012 11:28 AM, Michael Pasternak wrote:
> 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.
>
>> 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)
>
>>
>> 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.

i really expect all maintainers to follow the arch mailing list for this.

>
>>
>>>
>>>> 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
>>>
>
>