Re: [eclipse.org-planning-council] Notes from today's meeting ... and a

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

In the current development process,
"project" just means "code with a unique set of committers"
(a distinct Unix ACL). Any component that has a different set of committers
from its container is now technically a project. However we don't generally
call out all these nested projects, especially in this high-level planning
context. For example there is a "platform releng core" sub-project
of Eclipse Platform, because the release engineering team owns some tools
that only they have commit rights to, but from a planning point of view
it's not particularly relevant. Most sub-sub projects are "rolled
up" and just treated as parts of some larger project for planning
and release purposes. I think the granularity we are aiming for is one
row == one plan == one set of docuware == one collection of code that is
built together and contributed to helios as a unit == one contact person
(both releng and lead). Perhaps this will still be vague/unclear in some
cases but I'm not sure how else to express it...

John

Oisin Hurley <oisin.hurley@xxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx

12/04/2009 09:54 AM

Please respond to
"eclipse.org-planning-council"        <eclipse.org-planning-council@xxxxxxxxxxx>

To	"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
cc
Subject	Re: [eclipse.org-planning-council] Notes from today's meeting ... and        a request to those not there ...

> And Oisin, ...
>
> > On another topic, the mention of "sub-sub-projects"
is a little worrying,
> > after all, how far do the turtles go down? They used to go down
just one
> > level, now they go down three?
>
> I would like to jokingly reply "where have you been"? :)
> But, the fact that you don't know, speaks sadly to how confusing the
dev. process is.
> But yes. You can have projects in projects in projects ....

Ok, but just because project X 'lives in' project Y, does that mean it
is a sub-project? Maybe it's just a project. I guess the confusion I
have is whether codebase location is what the 'sub' means, or does
it have a different meaning.

Anyway. For some reason it is not as worrying to me now as it
was when I penned those words :)

 --oh


> (but some had to do with more independence, of related teams),
> and I think some of those ideas are losing favor among some that used
to like it.
> And, its my understanding, the Portal Infrastructure
> does not completely support it. One example of many levels, is that
under Modeling is EMF Technology and under
> that are Ecore Tools, EMFatic, Compare, etc.
> Or ... someone will correct me, and further prove how confusing it
all is! :)
>
> So, I'd like to end this overly long, too-late-at-night note with
the conclusion that "we need to give guidance on how to form the rows
in the table" but that only PMCs and their Projects can decide how
to consolidate their reviews -- as always. Agreed?
>
> Can someone provide better wording than what I rambled:  "sub-projects
or sub-sub-projects should group themselves into one row, if they can provide
one set of Docuware, and one IP Log document (even though IP is tracked
at individual project level) ... if it makes sense for them to have one
set of Docuware, but otherwise list themselves as a separate row and submit
separate Docuware". I'm sure I'll think of something better after
some sleep. :)
>
> Much thanks,
>
>
>
>
>
>
>
>
>
>
>
> From:
> Wayne Beaton <wayne@xxxxxxxxxxx>
> To:
> "eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
> Date: 12/02/2009 08:02 PM
> Subject: Re: [eclipse.org-planning-council] Notes from today's meeting
...        and        a request
to those not there ...
> Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> ________________________________
>
>
> The EDP allows for "rollup" reviews. Webtools, for example,
does a
> single release review for all of its subprojects. BIRT does the same.
> So, IMHO, there's no need to change the development process.
>
> I think that this speaks more to the conventions on the Participation
> page. What does it mean for projects to group themselves in a row
> anyway? I think that one implication can be that they do a single
> release review for all contained projects. For project that it doesn't
> make sense to group together, they can pull out to the "top level".
>
> More pragmatically, it'll allow me to have a better sense of how much
> release review work the EMO is going to have to do.
>
> Wayne
>
> David M Williams wrote:
> >
> > No, I do not think a change is _required_ in our PC documents
... but
> > if this "rule" deviates from the Eclipse Development
Process, then it
> > should be documented somewhere. I'd recommend the dev. proc.
document
> > be changed, if there's a fundamental change in rules. The Simultaneous
> > Release rules are more of _extra_ requirements that are agreed
to, not
> > different from the normal release process.
> >
> > But, what is the "rule" that you are going by? I doubt
we want it to
> > literally be "rows in table". I'm not sure what all
those rows
> > represent, but perhaps the rule should be "release reviews
are done at
> > either a top level project level or a first level sub-project
level.
> > Sub-sub-projects need to be aggregated to their first level
> > sub-project. This includes Docuware and IP Logs for anything
releasing
> > at the same time. If appropriate, sub-sub-projects can still
release
> > on their own, if they are the only thing releasing at that time".
Or
> > something similar to that. I suspect there's a spot or two in
the Dev.
> > Guide that could be changed, which would be best if you'd want
this to
> > be a consistent rule for all reviews ... not only the yearly
ones ...
> > which seems reasonable to me (though, I realize the other periods
of
> > time are not as "crunched", there'd still be a lot
of minutia even if,
> > say, 3 or 4 sub-sub-projects were releasing.
> >
> > I suspect this would be easier for most sub-sub-projects ...
a little
> > coordination to make sure someone was pulling it all together,
but
> > less documentation to produce.
> >
> > HTH
> >
> >
> >
> > From:                
 Wayne Beaton <wayne@xxxxxxxxxxx>
> > To:                  "eclipse.org-planning-council"
> > <eclipse.org-planning-council@xxxxxxxxxxx>
> > Date:                
 12/02/2009 05:34 PM
> > Subject:                
 Re: [eclipse.org-planning-council] Notes from today's
> > meeting ...        and a      
 request to those not there ...
> > Sent by:                
 eclipse.org-planning-council-bounces@xxxxxxxxxxx
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > +1 on all documents.
> >
> > I'd like to restrict the total number of reviews that we have
to do. In
> > that light, I'm going to push for one release review for each
row in the
> > table on the Participating Projects page.
> >
> > I don't think that this requires any changes in the documents.
> >
> > Does this sound reasonable?
> >
> > My apologies for missing the call.
> >
> > Wayne
> >
> > David M Williams wrote:
> > >
> > > I've updated our notes from todays call:
> > >
> > > http://wiki.eclipse.org/Planning_Council/December_02_2009
> > >
> > > Let us know if inaccuracies or omissions.
> > >
> > > For those of you had to drop off early (Oisin, Cedric) or
did not
> > > attend the call (Wayne, John, Chris, Anthony, and Christian),
I would
> > > appreciate you documenting here to the mailing list your
approval (or
> > > not) of our plan and requirements documents. While we had
a unanimous
> > > agreement of those present, and that would be a majority
(10 of 16) it
> > > is good form to document more agreement than a simple majority.
Plus,
> > > it is my way of not letting you off the hook for not attending
the
> > > meeting. :)
> > >
> > > I have update the main planning document in some minor ways
as
> > discussed,
> > > http://wiki.eclipse.org/Helios_Simultaneous_Release
> > >
> > > most notably pulling the participating projects table into
its own page
> > > http://wiki.eclipse.org/Helios/Participating_Projects
> > >
> > > and did some simple edits to requirements document
> > > http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php
> > >
> > > I'll announce these documents to Cross Project list on Thursday.
> > >
> > > Thanks very much for your help with the Simultaneous Release!
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > eclipse.org-planning-council mailing list
> > > eclipse.org-planning-council@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> > >
> > > IMPORTANT: Membership in this list is generated by processes
> > internal to the Eclipse Foundation.  To be permanently removed
from
> > this list, you must contact emo@xxxxxxxxxxx to request removal.
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> > IMPORTANT: Membership in this list is generated by processes
internal
> > to the Eclipse Foundation.  To be permanently removed from
this list,
> > you must contact emo@xxxxxxxxxxx to request removal.
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> > IMPORTANT: Membership in this list is generated by processes
internal to the Eclipse Foundation.  To be permanently removed from
this list, you must contact emo@xxxxxxxxxxx to request removal.
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
>
>
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: Membership in this list is generated by processes internal
to the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.