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"

Hi David,

A couple of thoughts in response.  First, I'll say thank you for responding...I greatly appreciate your consistently stunning personal effort on the simultaneous release, as well as your willingness to hear/respond to what I'm saying.

On 2/8/2011 11:50 AM, David M Williams wrote:
Scott, and others,

<stuff deleted>

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.  

I don't think conflicting opinion about whether requirements are actually increasing or not makes much each project has different experiences WRT the SR requirements.  My main point is that *given decreasing releng/other resources* (which I suspect many if not all of us...large and small...are experiencing), the net effect is that relatively more time/work has to be spent on simultaneous release things (IP review, build issues, coordination with other projects, etc).  This is to the necessary *detriment* of other things that a given project needs to develop new features, fix bugs, provide support, meet the consumer community's needs.

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.

I understand 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.

Yeah.  Sadly, I'm not confident that anything would actually be done about something like this (I say this as someone that was on the Board of Directors for two years myself as a Committer it's not as if I've not engaged this process previously). 

My main issue with the structure is that as things currently work...IMHO there's way more hierarchy and far less representation.  At least from my chair.

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.

How is this to be done?...i.e. without effectively breaking my back as a project lead?...i.e. spending all my time lobbying my various representatives (pmcs and committer reps)...or becoming one myself (which I've already done).  So now I have to chose between spending my time working on software (for the community), doing releng for the SR, or lobbying representatives on the Board?  My choice is pretty clear there.

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.

Then I would humbly suggest that the planning council, the pmcs, the Board, and the whole organization make easier and better (for the projects and their consumers) a higher priority.  

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

I'm not sure I buy that constantly shrinking resources is the 'nature of software business'.  It is obviously the nature of some sw businesses....but the EF...and it's committers, contributors, and consumers...are not themselves a 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.

I agree with as stated above...even if the SR requirements are not actually going up, the practical effect of continuously lowering resources is that they appear to the ones doing the work (us) to be going up.

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.

Thanks.  My only additional comment is that if this trend really matters to people...that care about this organization...then something should actually be done...because being starved out of an organization doesn't seem to me to be a natural consequence of doing an quality open source project.

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.

Yes, of course I know it's voluntary.  ECF is a mature project and has been part of the simultaneous release for the past 4 years.  I would venture that we have more than the average consumers/community for EF projects.  Yes, the simultaneous release would be of benefit to our community (which is why we've done it)...but here's what I'm faced with:  which is more benefit to the ECF community?  Finishing/testing/releasing the ECF impl of OSGi 4.2 Remote Service Admin [1], or doing the simultaneous release tasks?  Which serves my community better/more?  That's the judgment that I'm forced to make.

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

I know that's the intent...I'm not questioning anyone's intent.  But looking at the bigger picture...what I put to everyone reading this is:  Is that what's happening?

Thanks David.



Back to the top