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

[Itamar Heim]

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.
(or we could create a feature mailing list).

but i do agree we could use bugzilla for tracking features per version, 
if wiki isn't tracking this correctly.