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

[David M Williams <david_williams@xxxxxxxxxx>]

I may be confused about what you are
talking about.

You said "I'd
like to restrict the total number of reviews that we have to do."

Maybe I don't know what you mean by
"reviews", but not sure how much further we can "restrict".


Already, in our PC document, we have
several forms of consolidating the release reviews. See http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php#pcReleaseReview.
And those are all oriented towards consolidating at the level of the 10
top level projects ... not the 35 rows in the table ... and "10"
is better than "35"!  

So, what's left not already covered
in our doc? I think IP logs always have to sort of be at the individual
project level (by definition?) I know in WTP, we have one "log document",
but inside of it, we break it down by sub-project. Is that what you mean?
That you want the IP logs combined into one literal document, even if broken
down inside each document by project? 

What's left after that? The Docuware?


I'm open to suggestions. 

I think we have already made great progress
in our documented process ... even more progress 
than "one per row".  Focusing
too much on each row will be going backwards. 

> What does it mean for projects to group themselves

> in a row anyway?
 
I do not know (but appears to be sub-sub-projects
under sub-projects). 

Maybe you are saying more about how
projects should form those rows, rather than restricting reviews to the
rows. If so, what guidance should we give? 
You seem to be saying "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".  Does that clear up anything? I would have
thought projects already did that, as we do in webtools. Can you provide
better wording? My hope was the wording we have in http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php#pcReleaseReview
would cause PMC's to do their own (top level) soul searching on how to
simplify or consolidate, but it does not mention the rows in the table
explicitly. 

Oh, and I wouldn't say that table's
is in its final form by any means ... I just seeded it with the data that
was there, I assume from last year. 
I will want to see only the 10 top level
projects on the far left, and break it down in tree form from there. Maybe
we should start with only that, 
to encourage consolidation!? 

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 .... This started a few years ago, 
(but you are right, originally only
two levels). There was 
a school of thought that this would
be cool and make things easier. I never quite completely understood why,

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