Anthony,
It's great that the platform is exemplary and that it serves well the
needs of those investing the most resource in it as well as the other
communities.
Another question is who defines the train? There's never a final
question! When something functions by virtue of mutual voluntary
cooperation, it needs be defined, and agreed upon, by the
participants. It's good to listen to all the voices so as not to
alienate any segment of the community.
Reading the fine print, it's clear that the capabilities should be in a
separate plugin/feature. I'm not sure if the platform putting it all
in the SDK conforms to that rule. In fact, when the SDK is installed
is probably the time when the capabilities are the least likely to be
needed. I.e., if I install the Eclispe SDK it seems to follow that
I'll be using Java development. Why install JDT if I don't want Java
development.
In principle I think the capabilities rule has the right intent, but
the road to hell is paved with those. Oh well, I suppose bad
intentions would get us there even faster...
Cheers,
Ed
Anthony Hunter wrote:
Hi Team,
We all realize that each and every one of these "Galileo Must-do's" are
things the Eclipse platform team already does. They already have a new
and noteworthy posted as a link on the welcome page when you start
Eclipse. They provide an example set of capabilities that commercial
vendors, big and small, can made use of as a tool to build their
product. They already have documentation of how RTL languages are
handled. They fully support accessibility. The platform can be
translated to N different languages.
"The Eclipse Top Level Project (the “Eclipse Project”) is an open
source software development project dedicated to providing a robust,
full-featured, commercial-quality, and freely available industry
platform for the development of highly integrated tools."
So I guess the final question is whether we are all on the same train
or not?
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GEF / GMF / Modeling Tools
Phone: 613-270-4613
 Richard
Gronback ---11/14/2008 10:43:01 AM---Feel free to interpret ³should do²
as ³nice to have² in this case. We decided 2 categories were suf
Feel free to interpret “should do” as “nice to
have” in this case. We decided 2 categories were sufficient, must and
should. If it’s not a P1 == must-do item, then simply close that bug as
WONTFIX with what you have below.
- Rich
On 11/14/08 10:36 AM, "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Hi Richard,
If I'm not mistaken, the Release Review process just asks me to report
about the state of non-code aspects in my project. It doesn't ask me to
"design and test for bidi" like one of the "Should have" requirements
reads.
I'm fully OK with externalizing Strings into Message bundles since I
see it makes sense, it's good citicenship and, most of all, is not much
effort. But "designing and testing for bidi" is on a completely
different page. It's an enormous effort, it requires experience, it's
hard to get the test environments, I'd even say that it requires people
who are native speakers of an RTL language. I wonder how I'm assumed to
accomplish this in the scope of my project.
I'm not at all against BIDI. I've had some bug reports related to it
and tried to help, but without external assistence (by the reporter) or
patches provided I'm totally lost. I don't have the expertise for
helping here in the slightest way. Proper BIDI support, in my opinion,
requires an experienced test and development center. A member who needs
BIDI support should set that up and provide BIDI testing, bug
reporting, knowledge transfer and assistence for all the projects. Without that, the requirement is
totally moot in my opinion. It shouldn't be labelled "should have" but
"nice to have" IMO.
I think we've had similar discussions before with respect to
integration testing. At one level there comes the point where it goes
beyond individual project's scope and capabilities, and the Foundation
should strongly think about employing people who do it on behalf of the
projects if they want progress in that area.
Cheers,
--
Martin Oberhuber, Senior
Member of Technical Staff, Wind
River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Richard Gronback
Sent: Friday, November 14, 2008 1:49 PM
To: eclipse.org-planning-council; Cross
project issues
Subject: Re:
[eclipse.org-planning-council] 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: http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews
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.
Best,
Rich
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:
http://www.doodle.com/64gndycncpksufx9 <http://www.doodle.com/64gndycncpksufx9>
Cheers,
--
Martin Oberhuber, Senior
Member of Technical Staff, Wind
River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
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
Cc: eclipse.org-planning-council
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.
Regards,
Thomas Hallgren
Schaefer, Doug wrote:
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
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.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
