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

[Michael Pasternak]

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.

> 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