Re: [eclipse.org-planning-council] 2/2 Meeting minutes posted ... respon

[David M Williams <david_williams@xxxxxxxxxx>]

Scott, and others, 

Apologies in advance for a long note, but I plan on this
being my one and only response on this thread, since I do not think this
is the best forum or process for most of the issues raised. But, some important
issue were raised, and I want to give what little advice I can, and it
doesn't hurt for us write down some of the reasons and rationale for why
things are the way they are. I will make some high level comments, and
perhaps that will help you, or others, know better how to proceed. [I did
talk to Scott a little on Friday, on the phone, to make sure I understood
his concerns. I don't think there is anything particularly new I will be
saying here, and I am repeating some of what others have said already.]


First, please use care with statements such as "...given
the increasing requirements for SR participation". That is simply
not true and gives the wrong, negative impression of the Planning Council
and SR, if not Eclipse.  IMHO. The requirements have hardly changed
in effort required, since Ganymede, and while we could spend pages debating
if they are a little easier or a little harder, there has been basically
no change in many releases, and I do know of some things that were changed
to make things easier, more flexible, or clearer ... all based on feedback
from Project Leads and PC representatives. I could be missing something
that has gotten harder for you, or some projects, but it was certainly
not the intent to "raise the bar" ... though at times I wish
there was more ability and desire to do so. But, to say such statements,
as "...given the increasing requirements for SR participation",
to me, is like spreading ugly rumors and giving the wrong impression. IMHO.
Of course, you can say it if you really believe it, I'm just asking to
use care and not say it as though it was an established, agreed-to-by-all
fact or purposeful plan of the Planning Council.  

In general, the Planning Council is trying to make Eclipse
better via the yearly release. We do that by filtering the information
and requirements up from all the projects through their representatives,
and for uniformity, codify things most projects do anyway, or require things
which any professional quality software would be expected to do. That's
the goal. 

The Planning Council has intentionally been set up to
be hierarchical, that is, govern by representation. I wasn't there when
the by-laws were written, and am sure there were a number of reasons for
them being written the way they were ... but, the advantage of that kind
of organization (that I like,  that makes this effort feasible, IMHO)
is that there are several layers of filters, filtering priorities up to
the most important issues, within a top level project, or strategic member,
and then the planning council actually has a chance of discussing it and
making progress on it. The extreme alternative, a completely flat organization,
where each and every one of the 50 projects might participate would be
good for some things, but for the yearly release, it would just mean the
loudest would "win" and we could not get meaningful discussion
between 50 people, and very little would happen simultaneously. IMHO. Maybe
there are some improvements that could be made to the organization's by-laws,
and if you did want to change that, then that would be a matter to discuss
with your Committer Reps on the Board of Directors. 

I am sorry you don't feel represented. But you are. Both
technically (as others have said), and in practice; small projects are
always kept in mind. Many times during meetings representatives say things
like "... we can't do that since it'd be too much burden on the smaller
projects ...", Or, "... I've heard some people confused about
why this requirement is important to small projects, can we explain it
better, or change it ...".  I think you and your PMC (and Planning
rep) need to communicate better ... if I may be blunt ...  here is
how I wrote it in the communication section of the requirements document:


"Your representative to the Planning Council,
either from PMC or Strategic Member, must attend PC meetings and represent
you there. Presumably, of course, after meeting or communicating with you
and the other projects they represent, so they can fairly bring forward
concerns and vote on issue that effect all projects, if required. Put another
way, by committing to be in the Simultaneous Release, you agree to abide
by all the Planning Council decisions and rules, so be sure your representative
understands your project and your situation."

So ... be sure your representative understands your project
and situation. 

And, don't get me wrong, I am not saying its easy. I am
very sympathetic to the difficulty of participating in the Simultaneous
Release ... in releasing software in general. We would all like it to be
easier and better.  One problem is that the more projects that get
involved, the harder it gets for everyone. That is one of the driving motivations
for some of the requirements ... get things done early, use some standard
formats, write things where people can find them, etc. Things get harder
when more people and projects get involved ... that seems to be a natural
law, or something ... and kind of hard to complain about success ... but
does lead to some measures that require more standard procedures.  
There is another, maybe larger,  reason things might seem to be getting
harder, year to year. Resources seem to often get constrained, reduced,
or re-prioritized ... that too, is the nature of the software business
... but , I think it is the shrinking resources that gives the perception
of "increasing requirements" ... the requirements have not changed,
they have stayed about the same, but now there are less people to do the
work, so it seems there is more to do. Sometimes, the reduction is direct
and obvious; if a project has less committers, that is an obvious source
of "more work" for everyone else. But, there is a more subtle
effect that goes on at Eclipse (if not all software projects); reductions
in unrelated projects and staff have a way of effecting others. There are
less people to answer questions, write examples, create wikis, debug weird
build problems, a few more last minute regressions sneak in, a few more
builds come in just a few hours late, and all these have ripple effects
that multiply. (That is one reason for some of the "hard deadlines"
in producing some of our milestones, etc. ... that is, to minimize chances
to ripple). So, it is hard. I agree with that. But I think mostly due to
things besides the requirements increasing. And we'll all continue to try
and make it easier while also making Eclipse better. 

So, for some concrete advice.  If there are specific
issues you or anyone think are "too hard", you can always open
a cross-project bug, for at least discussion, if not solution. Such as
"signing jars at Eclipse is too hard to accomplish" or "Babel
participation should be fully automated", as fictitious examples.
Or, if you have very high level, sort of philosophical issues about Eclipse
(or the Planning Council) ... then a blog is probably best. But, if you
want to get the Planning Council to change requirements for participation,
then working through your Planning Council representative is the most effective
way to do that. 

My last comment is that the yearly simultaneous release
is very deliberately meant to be voluntary. It is extra work. It is not
for everyone. And those who join should do so with the goal of making their
project and Eclipse better ... it'd be kind of sad if it was just to "...
hit the lowest possible minimum bar, just because someone said we had to".
 And, honestly, I have sometimes thought some newer or smaller projects
felt a little too much pressure to participate. I'm not sure why they do.
I guess to prove they could do it? that they could not only "graduate"
but graduate all the way into a Simultaneous Release? A tough row to hoe.
But, there are, after all, many advantages to participating, so hopefully
most find the added effort worthwhile.  But just because a project
is not in the yearly release in no way means it is a "bad project"
or anything. Every project at Eclipse must always act according to what's
best for its committers and adopters; and that is not always the same for
all projects -- so I think you are asking the right questions;  whether
your project should participate. It is good not to be on autopilot, and
just assume everyone always needs to be in the yearly release. There are
pros and cons, and only you (and your committers and adopters) can weigh
those costs and benefits. 

Just remember, the intent is to make the yearly release
and Eclipse better. I look forward to your continued participation in that
process. 

Thank you, 
 





 





From:      
 Scott Lewis <slewis@xxxxxxxxxxxxx>
To:      
 eclipse.org-planning-council@xxxxxxxxxxx
Date:      
 02/02/2011 02:35 PM
Subject:    
   Re: [eclipse.org-planning-council]
2/2 Meeting minutes posted
Sent by:    
   eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

I would like to ask a question of the planning council
and perhaps start a public discussion.

I'm the project lead of a mature project (ECF) that has been a member of
the simultaneous release for the past 4 years.   David and others
familiar with our previous contributions to the simultaneous release.

Over these four years, ECF has not had any representation on the planning
council...and never been consulted or even asked about any decisions associated
with the simultaneous release (e.g. for whether/what *our* community is
wanting in terms of the simultaneous release).  

Over the past year, I've been made aware of several other projects that
have previously participated in the simultaneous release, but are reaching
(or have reached) the limit on their releng resources...and some are contemplating
not participating in Indigo...because of the releng load, because of the
increases in required 'todo' items, and perhaps some of these projects
perceive a mismatch between what the simultaneous release is now requiring
and what their community is telling them they want.  See [1] for a
discussion on the ECF mailing list about simultaneous release participation,
etc).

My question is this:  I don't see any indication in the planning council
notes for yesterday's meeting of *anyone* bringing up the issue of projects
(like ECF) questioning the utility for their consumers of participation
in Indigo (given the costs for the projects/committers...which seem to
continue to go up inexorably).  Can this issue get raised on the planning
council?  I know for sure that I'm not the only project lead that
is questioning whether the benefits of participating in the simultaneous
release (for the consumers/community) offset the rising costs on the projects
(mostly releng...but also IP process of course).   Although others
may disagree, I think this is not a good sign.

IMHO there is both a material problem and a process problem:  The
material problem is that smaller/non-strategic run projects are generally
starved for releng resources, and this is getting worse given the increasing
requirements for SR participation, as well as reduced resources for open
source projects in general.  The process problem (IMHO) is the (lack
of) representation of the smaller/non-strategic run projects on the planning
council.

Note I'm not blaming anyone for anything...for example I have the highest
appreciation for David Williams (in particular), the simultaneous release
builder/Buckminster team, and others that have been doing the actual work
of the simultaneous release on behalf of all the projects.  Bravo!

But I think it would be worthwhile to have a discussion about what I perceive
to be both the material problem and the process problem here...before we
get to April/May and projects start dropping out of the SR.

Scott

[1] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg04670.html


On 2/2/2011 10:56 AM, David M Williams wrote: 
I've typed in what I captured during
the meeting, but please review and correct anything I missed. I know for
sure I missed some "attendees", so feel free to correct that
table if you were there. 

http://wiki.eclipse.org/Planning_Council/February_02_2011

Good discussions, good progress ... good reminder of how much there's left
to do :) 

Thank you, 


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