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

[Michael Pasternak]

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.

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