[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] RE: [eclipse.org-planning-council] Submitted EMF 2.4M3 to Ganymede
|
I hesitate to even say +1 because even this note is kind of annoying spam.
But if it helps cut off longer terms spam then it's worth it. A summary
table provides much more value than does a long sequence of spam. I can't
imagine anyone disagreeing so let's assume 100% agreement and let's hear
from anyone who disagrees. If we hear from no one, the 100% agreement is
confirmed.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Kim
Moir/Ottawa/IBM@I
BMCA To
Sent by: "eclipse.org-planning-council"
eclipse.org-plann <eclipse.org-planning-council@eclip
ing-council-bounc se.org>
es@xxxxxxxxxxx cc
Subject
11/12/2007 04:45 Re: [cross-project-issues-dev]
PM RE: [eclipse.org-planning-council]
Submitted EMF 2.4M3 to Ganymede
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
+1 for less email and updating http://wiki.eclipse.org/Ganymede/Signoffs
every milestone.
Kim
Dave
Steinberg/Toronto/IBM@IBMCA
Sent by: To
eclipse.org-planning-council- eclipse.org-planning-council@eclipse
bounces@xxxxxxxxxxx .org
cc
11/12/2007 09:47 AM Subject
Re: [cross-project-issues-dev] RE:
[eclipse.org-planning-council]
Please respond to Submitted EMF 2.4M3 to Ganymede
"eclipse.org-planning-counci
l"
<eclipse.org-planning-counci
l@xxxxxxxxxxx>
Hi Bjorn,
It's true that we did talk a great deal about what process we would use to
close and declare milestones/releases, and ended up deciding not to use a
vote or sign-off process, opting for a fixed-time cutoff instead. However,
my recollection is that we didn't specifically consider using a table in
place of the build notifications we *already* do on the mailing list.
I know Nick proposed the idea as a "signoff table", but my interpretation
of his intent was simply to eliminate the confusing flood of messages that
gets sent to cross-project-issues-dev as people get their contributions in
place. And my interpretation of our decision last week is that we didn't
want to introduce a new process that would allow one project to hold up the
release train and the others to overrule that, etc. I don't believe that
we addressed the issue of this existing flood of messages. We certainly
didn't say that we should stop sending these notifications (I'm using the
term "notifications" instead of "sig-offs" now, in light of that fact that
we've decided not to depend on them before declaring a milestone/release),
and I don't believe we even considered moving them to another venue. So, I
think there's still room to have that discussion.
I know that, if it had been raised, I would have expressed strong support
for moving to a table on a wiki. Personally, I read
cross-project-issues-dev but have zero need to know when every last project
has put each contribution in place. I would find the list much enhanced by
removing all that noise, and I can't imagine I'm the only one in this
position. And, for someone who *does* need that information, surely going
to a wiki where it's all nicely captured and organized in a table would be
more useful that scanning through the 20-odd messages, trying to find the
most recent from the particular projects of interest. Throw in the fact
that the wiki *can* send notifications of updates, if desired, and I can't
imagine why anyone would prefer the current approach.
Cheers,
Dave
--
Dave Steinberg
Rational Software - IBM Toronto Lab
mailto:davidms@xxxxxxxxxx
Bjorn
Freeman-Benson
<bjorn.freeman-be To
nson@xxxxxxxxxxx> Cross project issues
Sent by: <cross-project-issues-dev@eclipse.o
eclipse.org-plann rg>
ing-council-bounc cc
es@xxxxxxxxxxx "'eclipse.org-planning-council'"
<eclipse.org-planning-council@eclip
se.org>
11/08/2007 09:56 Subject
PM Re: [cross-project-issues-dev] RE:
[eclipse.org-planning-council]
Submitted EMF 2.4M3 to Ganymede
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
Europa People,
At the Planning Council meeting here in Reston, VA on Tuesday, the Planning
Council decided that this fall's maintenance release problems were a
one-off and that we didn't need to add more process around it (unless it
happens again). We carefully considered the sign-off table, voting, and
other options and decided that we'd just leave the situation as is:
date-based deadlines and date-based releases UNLESS someone yelps for help
on the mailing list about needing a re-spin.
http://wiki.eclipse.org/Europa_Simultaneous_Release#Coordinated_Maintenance
- Bjorn
+1 for the table, and having everyone interested watch the page.
--
[end of message]_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council