[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
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? -- Michael Pasternak RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D
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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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. Regards, Alon
On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com> Sent: Friday, December 21, 2012 12:15:13 AM Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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).
Yes it is... for project width feature you have parent feature of the whole distribution and blockers for each component.
but i do agree we could use bugzilla for tracking features per version, if wiki isn't tracking this correctly.
wiki is not the right tool for release engineering. Regards, Alon
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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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. you can consider a group as all people who are CC to a bug.
(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
On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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 very different from proprietary. Also, features can be cross component / cross products / cross projects. You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe.
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
On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> > To: "Michael Pasternak" <mpastern@redhat.com> > Cc: "engine-devel" <engine-devel@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.
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
-- Michael Pasternak RedHat, ENG-Virtualization R&D
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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> >> To: "Michael Pasternak" <mpastern@redhat.com> >> Cc: "engine-devel" <engine-devel@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
On 12/23/2012 11:35 AM, Itamar Heim wrote:
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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> >>> To: "Michael Pasternak" <mpastern@redhat.com> >>> Cc: "engine-devel" <engine-devel@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.
Itamar, i think it's not feasible, people has a lot of constraints and can easily miss stuff, getting personal notifications is much more practical and can dramatically reduce redesign of the features during review processes, what is quite painful for the contributors, i think this way it will be much more easer to follow feature discussions, and i'm sure it won't cause maintainers to stop following mailing lists, just entire process will become much more productive for both sides.
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
-- Michael Pasternak RedHat, ENG-Virtualization R&D
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Sunday, December 23, 2012 11:28:13 AM Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> >> To: "Michael Pasternak" <mpastern@redhat.com> >> Cc: "engine-devel" <engine-devel@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.
I am sorry, but this is not "open" discussion. You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them. Maintainer is not someone who is more important the contributer, he just has commit access.
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)
Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute. If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses. All discussions should be made in public, this is burden but also opportunity.
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.
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
--
Michael Pasternak RedHat, ENG-Virtualization R&D
On 12/23/2012 11:39 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Sunday, December 23, 2012 11:28:13 AM Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, arch@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@redhat.com> >>> To: "Michael Pasternak" <mpastern@redhat.com> >>> Cc: "engine-devel" <engine-devel@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.
I am sorry, but this is not "open" discussion. You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them.
how possible you will loose them? adding mailing-group/s of maintainers does *not* mean excluding the mailing list itself ... anyone that is interested in discussion can still follow it.
Maintainer is not someone who is more important the contributer, he just has commit access.
i do agree about maintainers not being "more important" than contributor, but for sure maintainers have more experience with the projects and planned stuff, so they can drive features to the right direction ...
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)
Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute.
If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses.
All discussions should be made in public, this is burden but also opportunity.
Alon, i think you missed the point, read my answer ^ above, + entire thread was started, to make sure maintainers explicitly got involved in to design of the features and not changing it when the code is written (what for sure will make contributors frustrated)
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.
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
--
Michael Pasternak RedHat, ENG-Virtualization R&D
-- Michael Pasternak RedHat, ENG-Virtualization R&D
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Sunday, December 23, 2012 12:01:25 PM Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
On 12/23/2012 11:39 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Sunday, December 23, 2012 11:28:13 AM Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> > To: "Itamar Heim" <iheim@redhat.com> > Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" > <engine-devel@ovirt.org>, arch@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@redhat.com> >>>> To: "Michael Pasternak" <mpastern@redhat.com> >>>> Cc: "engine-devel" <engine-devel@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.
I am sorry, but this is not "open" discussion. You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them.
how possible you will loose them? adding mailing-group/s of maintainers does *not* mean excluding the mailing list itself ...
So why do you need the group? I don't understand... maybe provide another projects that works this way?
anyone that is interested in discussion can still follow it.
Maintainer is not someone who is more important the contributer, he just has commit access.
i do agree about maintainers not being "more important" than contributor, but for sure maintainers have more experience with the projects and planned stuff, so they can drive features to the right direction ...
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)
Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute.
If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses.
All discussions should be made in public, this is burden but also opportunity.
Alon,
i think you missed the point, read my answer ^ above, + entire thread was started, to make sure maintainers explicitly got involved in to design of the features and not changing it when the code is written (what for sure will make contributors frustrated)
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.
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
--
Michael Pasternak RedHat, ENG-Virtualization R&D
--
Michael Pasternak RedHat, ENG-Virtualization R&D
On 12/23/2012 12:16 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, "Itamar Heim" <iheim@redhat.com> Sent: Sunday, December 23, 2012 12:01:25 PM Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
On 12/23/2012 11:39 AM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Michael Pasternak" <mpastern@redhat.com> > To: "Alon Bar-Lev" <alonbl@redhat.com> > Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, > "Itamar Heim" <iheim@redhat.com> > Sent: Sunday, December 23, 2012 11:28:13 AM > Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for > the new feature discussion/implementation. > > On 12/23/2012 11:07 AM, Alon Bar-Lev wrote: >>> >>> >>> ----- Original Message ----- > >>>> From: "Michael Pasternak" <mpastern@redhat.com> > >>>> To: "Alon Bar-Lev" <alonbl@redhat.com> > >>>> Cc: "engine-devel" <engine-devel@ovirt.org>, arch@ovirt.org, > >>>> "Itamar Heim" <iheim@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@redhat.com> >> > >>>>>> To: "Itamar Heim" <iheim@redhat.com> >> > >>>>>> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "engine-devel" >> > >>>>>> <engine-devel@ovirt.org>, arch@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@redhat.com> >>>>> > >>>>>>>>> To: "Michael Pasternak" <mpastern@redhat.com> >>>>> > >>>>>>>>> Cc: "engine-devel" <engine-devel@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.
I am sorry, but this is not "open" discussion. You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them.
how possible you will loose them? adding mailing-group/s of maintainers does *not* mean excluding the mailing list itself ... So why do you need the group?
please see very first email of this tread, you will see there that suggestion works like this: 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) (3.1 answer your concerns from the previous email) -- Michael Pasternak RedHat, ENG-Virtualization R&D
participants (3)
-
Alon Bar-Lev -
Itamar Heim -
Michael Pasternak