Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] How many Rules does Eclipse need (was: Galileo Must-do's)

AC Members,
I find the discussion (below) from the cross-project list very interesting. How much control should be imposed on projects in order to come up with something consistent and highly usable out of individual components, for the benefit of all participants?
Do we get the best results if every project just does "their own thing", or do we need architectural guidelines (rules) in order to keep things stable? How much rules do we need? Do we just need to advertise benefit of the rules better such that projects opt-in to the rules by themselves?
Eclipse is being perceived as too bloated already compared to specialized toolings, because everybody just stuffs their things in; on the other hand, the ability of broad integration into one toolset is one of the biggest selling points for Eclipse.
For the sake of the Galileo Train, projects choose to opt-in to the train, so the pressure of actually complying is higher than for projects not on the Train. But this is one of the discussions that we - as the body responsible for the Eclipse Platform Architecture as a whole - should join in to.
I guess it would be much easier to have such a discussion face to face, and I'll cheerfully bring this up at our ESE meeting or when I meet some of you personally. For now, if you think you have something to say, please join the E-Mail discussion. I think it's important for all of us.
At any rate, please participate in the little poll I've created for this:
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 Thomas Hallgren
Sent: Friday, November 14, 2008 11:02 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Galileo Must-do's

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@xxxxxxxxxxx

Back to the top