[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Galileo Must-do's
|
Title: Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Galileo Must-do's
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
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:
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.
Doug.
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":
http://ahuntereclipse.blogspot.com/2008/11/i-just-dont-have-any-capabilities.html
and
further comments should go on https://bugs.eclipse.org/bugs/show_bug.cgi?id=252807
Cheers...
Anthony
--
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
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
_______________________________________________
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.
