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" <[email protected]>
To: "Alon Bar-Lev" <[email protected]>
Cc: "engine-devel" <[email protected]>, [email protected], "Itamar Heim"
<[email protected]>
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" <[email protected]>
To: "Itamar Heim" <[email protected]>
Cc: "Alon Bar-Lev" <[email protected]>, "engine-devel"
<[email protected]>, [email protected]
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" <[email protected]>
To: "Michael Pasternak" <[email protected]>
Cc: "engine-devel" <[email protected]>
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
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
