Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] 2/2 Meeting minutes posted ... response to "difficulties in participating"

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>
Date:        02/02/2011 02:35 PM
Subject:        Re: [] 2/2 Meeting minutes posted
Sent by:

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.



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.

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

Thank you,

_______________________________________________ mailing list

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

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.

Back to the top