Rich,
Cool, I liked both your answers. :-)
Note that Marcelo is not directly working on EMF anymore, so is part
time at best. Kenn has not been actively committing either. I'm
hoping Dave will be a more active committer once the EMF book is
finished---order you copy now in time for December availability---but I
can't plan for IBM's resource. Nick helps with releng, thank goodness,
or we'd be beyond hope. So while it may sound like I'm simply a drama
queen (and while that may even be true!) the CVS records are there for
all to see and speak for themselves.
Cheers,
Ed
Richard Gronback wrote:
And just to clarify another point... The
Galileo participation requirements are not carved in stone. We have a
Planning Council call on December 3rd, which is before the M4 deadline
for participation. Therefore, I’d encourage everyone to communicate
with their respective PMCs their thoughts on the requirements so that
they can in turn be discussed on that call.
Thanks,
Rich
On 11/14/08 8:13 AM, "Richard Gronback" <richard.gronback@xxxxxxxxxxx>
wrote:
I have little doubt that EMF will remain on
the train, like it or not Ed. EMF has more than a single committer,
and there are too many that depend upon it for you not to suddenly find
others willing to contribute. Heck, I’ll write your N&N for you,
if it helps.
- Rich
On 11/14/08 7:59 AM, "Ed Merks" <ed.merks@xxxxxxxxx> wrote:
Guys,
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.
Regards,
Ed
Richard Gronback wrote:
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:
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.
_______________________________________________
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
_______________________________________________
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.
|
