Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] RE: [cross-project-issues-dev] Galileo Must-do's


I think my own frustrations reflect those of the comments I see below and they stem from a slight problem with the process.  There are must-do rules that I didn't agree should be there.  I wasn't asked to agree to them, my opinion wasn't solicited, and I don't feel I have much choice.  I can whine, but that makes me a bad person.  I can bemoan the endless bidi problems that stem from trying to turn a development IDE that manipulates primarily LTR scripts into one that tolerates a mixture of LTR and RTL, but that makes me culturally insensitive.  I'm led to believe that I need to give a little more to get over the bar this year, which I'm told to expect will move a little higher the next time I try to clear it.  Hopefully it doesn't move right as a jump.  I'm sorry I could not be at the face to face, but does that really mean now I have to live with all the new rules?

Of course I agree with the principle that I benefit from the train so I'm willing to give back in kind. But if you stop and think about it, I only depend on the platform, so the train actually does very little for me directly, yet I try to make sure my builds are done in a day rather than in three days because I know that helps others.  But I don't have any spare resource, not one iota, so I need to balance  my workload carefully to ensure that my efforts produce maximum value.  Most importantly, I want to make those decisions myself.  I don't want to be coerced, I don't like feeling coerced, and when I start to feel that way, I feel that it's time to push back. 

When I spend a day making three plan.xml for components, and 10 other component leads spend time as well, some even a day they claim, only to find later that component plans can't be accommodated by the portal and hence I must spend another 1/2 day manually rolling them up, I'm really not happy camper. (Thanks Rich for making planURL work!) When I see more must do's after finally having time to look closely, I'm even less happy.  So now I'm feeling coerced. I have a low threshold of tolerance when I feel that the bar is being moved in front of me.  I have zero tolerance for being told I should give a little more.  I've given all there is to give and I will choose what more to give.

So if someone tells me that I must have an N&N, part of me says, shut up and just do it, it has value, the community will appreciate it, and it won't take but a little time.  The other part of me says, that's not essential to the success of the train. Why am I being forced to do this?  Why have nice-to-haves become must-do's?  That other part of me has been primed to respond negatively by the feeling of being overworked.  It's wanting to find a way to even the playing field where just little old me keeping all the different aspects of a project working smoothly can still have some time to do some interesting development work.  So I'm primed to pick a really stupid little issue out of principle and say no to it; just say no to see what happens.

The lesson here is that the train works because of the good will of the participants.  I give that good will gladly but I can choose to withdraw it bitterly when push comes to shove.  If  my smaller project falls off or decides to leave, the train ends.  Just as my cooperation is essential, so too is my agreement.


Richard Gronback wrote:
Re: [] RE: [cross-project-issues-dev] Galileo Must-do's Hi Martin,

Many of the things we’re requiring are just good Eclipse citizenship items that all projects should be striving for anyway.  Globalization effort is not only about larger companies or commercial adopters.  At least 2 of the 3 communities that all Eclipse projects are supposed to support require this for worldwide consumption.   I see these as Eclipse entry requirements, not only as train requirements.   See non-code aspects listed on the Release Review checklist:

I can imagine a larger company contributing to a smaller project to get it up to snuff if they are consumers of the project and require it for a commercial product, for example.  But, I doubt you’ll find a willingness to contribute for the sake of getting projects on the release train.  Instead, we’ll likely just see smaller projects falling off the train, or the respective project leads growing their project team to meet the requirements, and in the process, improving the overall quality/success of their project.


On 11/14/08 7:16 AM, "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:

Hi Richard,

I fully agree with what you say. I second the idea that participating in the train may cost something, because you also gain from it. I agree that we need rules in order to keep consistent as we grow.

But I do see a potential problem here:

The PC is comprised of a single representative of each PMC. These representatives are typically from the larger companies, who can
afford sponsoring Eclipse to a larger extent (by providing PMC personnel, expensing for travel to Face-to-face-meetings etc).

These larger companies are also the ones who are interested in globalization, and as a matter of fact many of the must-dos have
to do with globalization: String externalization, Babel, ICU4J just to name few.

Now by means of the Train, smaller projects (sponsored by smaller companies) get forced to invest in globalization although they would
normally not need that because they might be interested in English-only versions of their products based on Eclipse. It almost seems
that the larger companies (represented on the PMC's and the PC) take the Train as a vehicle to have smaller projects do work that only
they benefit from.

I'm in favor of Rules that can be argued to improve the Eclipse Architecture and consistency of the projects. I like Capabilities, UI Guidelines, Branding, Build, Execution Environment, OSGi, New&Noteworthy, Ramp-down-plan, Orbit. I can also understand Accessibility as a social responsibility and quality signal of Eclipse. But for rules that cannot be argued like that, I think that those who need or gain from a rule (the large ones) should also pay for it (by contributing to the smaller projects).

Again, I'd like to encourage everyone interested to participate in my poll: <>

Martin Oberhuber
, Senior Member of Technical Staff,
Wind River
Target Management Project Lead, DSDP PMC Member



From:  cross-project-issues-dev-bounces@xxxxxxxxxxx  [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of  Richard Gronback
Sent: Friday, November 14, 2008 12:32  PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev]  Galileo Must-do's

Each year, we raise the bar a little on release train  participation.  As I recall, the main bar-raising items are capability  definitions and New & Noteworthy pages.  These didn’t seem too  drastic by members of the PC that agreed to them, but maybe we were wrong (I  certainly hope not).

And to be clear, nobody is forcing anyone to do  anything.  Participation on the Release Train is voluntary, but comes at  the cost of agreeing to release at a higher bar than what is normally required  for releasing as a non-train project.  There’s not a whip involved here,  but a carrot.  If you’d like to be on the train, there is a cost, that’s  all.

- Rich

On 11/14/08 5:01 AM, "Thomas Hallgren" <thomas@xxxxxxx> wrote:

I miss the good old days when Open Source  communities were based on the contributions that they got, where the  contributors were heroes, and the quality of the resulting product were the  product of their goodwill and skill. I find that participating in the  Eclipse release train nowadays involves efforts that are somewhat  overwhelming and that I, instead of adding valid functionality to the areas  where I contribute, am forced to implement requirements that brings much  less benefit to the intended user base.

I think that when a central  management stipulates this many requirements for individual projects,  there's a high risk that all the fun is taken out of it. As a contributor,  and even as a project manager, I loose control. I no longer decide what's  important in my own domain. I no longer prioritize what to do with the time  I spend on the projects. Someone else does. A lot of the motivation is  thereby lost, replaced with a whip that forces me to comply with a strict  set of rules. Was that the intention? I don't think so.

Don't get me  wrong, I can see that there are benefits in having a common set of  requirements. I just think it's a tad too much  now.

Thomas Hallgren

Schaefer, Doug wrote:  
It'll be  interesting to see what happens when we get to the Release Review and find  few of us actually did all the must dos. Unfortunately, the must do's  didn't come with additional contributions and I can't seem to pull any out  of my, uh, never mind. I see Doom ahead unless a Christmas miracle  happens.




From: cross-project-issues-dev-bounces@xxxxxxxxxxx  [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]  On Behalf Of Anthony Hunter
 Sent: Thursday,  November 13, 2008 10:20 PM
 To: Cross project  issues
 Subject: Re: [cross-project-issues-dev] Galileo  Must-do's


Hi Team,  with respect to the questioning of the capabilities as a "must  do":
and  further comments should go on  
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software  Development Manager: Eclipse Open Source Components
IBM Rational  Software: Aurora / GEF / GMF / Modeling Tools  


cross-project-issues-dev  mailing list


cross-project-issues-dev  mailing list

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

_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx

Back to the top