Hi David,
A couple of thoughts in response. First, I'll say thank you for
responding...I greatly appreciate your consistently stunning
personal effort on the simultaneous release, as well as your
willingness to hear/respond to what I'm saying.
On 2/8/2011 11:50 AM, David M Williams wrote:
Scott, and others,
<stuff deleted>
First, please use care with statements such as
"...given
the increasing requirements for SR participation". That is
simply
not true and gives the wrong, negative impression of the
Planning Council
and SR, if not Eclipse. IMHO. The requirements have hardly
changed
in effort required, since Ganymede, and while we could spend
pages debating
if they are a little easier or a little harder, there has been
basically
no change in many releases, and I do know of some things that
were changed
to make things easier, more flexible, or clearer ... all based
on feedback
from Project Leads and PC representatives. I could be missing
something
that has gotten harder for you, or some projects, but it was
certainly
not the intent to "raise the bar" ... though at times I wish
there was more ability and desire to do so. But, to say such
statements,
as "...given the increasing requirements for SR participation",
to me, is like spreading ugly rumors and giving the wrong
impression. IMHO.
Of course, you can say it if you really believe it, I'm just
asking to
use care and not say it as though it was an established,
agreed-to-by-all
fact or purposeful plan of the Planning Council.
I don't think conflicting opinion about whether requirements are
actually increasing or not makes much sense...as each project has
different experiences WRT the SR requirements. My main point is
that *given decreasing releng/other resources* (which I suspect many
if not all of us...large and small...are experiencing), the net
effect is that relatively more time/work has to be spent on
simultaneous release things (IP review, build issues, coordination
with other projects, etc). This is to the necessary *detriment* of
other things that a given project needs to do...like develop new
features, fix bugs, provide support, etc...to meet the consumer
community's needs.
In general, the Planning Council is trying to make
Eclipse
better via the yearly release. We do that by filtering the
information
and requirements up from all the projects through their
representatives,
and for uniformity, codify things most projects do anyway, or
require things
which any professional quality software would be expected to do.
That's
the goal.
I understand that's the goal.
The Planning Council has intentionally been set up
to
be hierarchical, that is, govern by representation. I wasn't
there when
the by-laws were written, and am sure there were a number of
reasons for
them being written the way they were ... but, the advantage of
that kind
of organization (that I like, that makes this effort feasible,
IMHO)
is that there are several layers of filters, filtering
priorities up to
the most important issues, within a top level project, or
strategic member,
and then the planning council actually has a chance of
discussing it and
making progress on it. The extreme alternative, a completely
flat organization,
where each and every one of the 50 projects might participate
would be
good for some things, but for the yearly release, it would just
mean the
loudest would "win" and we could not get meaningful discussion
between 50 people, and very little would happen simultaneously.
IMHO. Maybe
there are some improvements that could be made to the
organization's by-laws,
and if you did want to change that, then that would be a matter
to discuss
with your Committer Reps on the Board of Directors.
Yeah. Sadly, I'm not confident that anything would actually be done
about something like this (I say this as someone that was on the
Board of Directors for two years myself as a Committer Rep...so it's
not as if I've not engaged this process previously).
My main issue with the structure is that as things currently
work...IMHO there's way more hierarchy and far less representation.
At least from my chair.
I am sorry you don't feel represented. But you are.
Both
technically (as others have said), and in practice; small
projects are
always kept in mind. Many times during meetings representatives
say things
like "... we can't do that since it'd be too much burden on the
smaller
projects ...", Or, "... I've heard some people confused about
why this requirement is important to small projects, can we
explain it
better, or change it ...". I think you and your PMC (and
Planning
rep) need to communicate better ... if I may be blunt ... here
is
how I wrote it in the communication section of the requirements
document:
"Your representative to the Planning Council,
either from PMC or Strategic Member, must attend PC meetings
and represent
you there. Presumably, of course, after meeting or
communicating with you
and the other projects they represent, so they can fairly
bring forward
concerns and vote on issue that effect all projects, if
required. Put another
way, by committing to be in the Simultaneous Release, you
agree to abide
by all the Planning Council decisions and rules, so be sure
your representative
understands your project and your situation."
So ... be sure your representative understands your
project
and situation.
How is this to be done?...i.e. without effectively breaking my back
as a project lead?...i.e. spending all my time lobbying my various
representatives (pmcs and committer reps)...or becoming one myself
(which I've already done). So now I have to chose between spending
my time working on software (for the community), doing releng for
the SR, or lobbying representatives on the Board? My choice is
pretty clear there.
And, don't get me wrong, I am not saying its easy.
I am
very sympathetic to the difficulty of participating in the
Simultaneous
Release ... in releasing software in general. We would all like
it to be
easier and better.
Then I would humbly suggest that the planning council, the pmcs, the
Board, and the whole organization make easier and better (for the
projects and their consumers) a higher priority.
One problem is that the more projects
that get
involved, the harder it gets for everyone. That is one of the
driving motivations
for some of the requirements ... get things done early, use some
standard
formats, write things where people can find them, etc. Things
get harder
when more people and projects get involved ... that seems to be
a natural
law, or something ... and kind of hard to complain about success
... but
does lead to some measures that require more standard
procedures.
There is another, maybe larger, reason things might seem to be
getting
harder, year to year. Resources seem to often get constrained,
reduced,
or re-prioritized ... that too, is the nature of the software
business
...
I'm not sure I buy that constantly shrinking resources is the
'nature of software business'. It is obviously the nature of some
sw businesses....but the EF...and it's committers, contributors, and
consumers...are not themselves a software business.
but , I think it is the shrinking
resources that gives the perception
of "increasing requirements" ... the requirements have not
changed,
they have stayed about the same, but now there are less people
to do the
work, so it seems there is more to do.
I agree with this...so as stated above...even if the SR requirements
are not actually going up, the practical effect of continuously
lowering resources is that they appear to the ones doing the work
(us) to be going up.
Sometimes, the reduction is direct
and obvious; if a project has less committers, that is an
obvious source
of "more work" for everyone else. But, there is a more subtle
effect that goes on at Eclipse (if not all software projects);
reductions
in unrelated projects and staff have a way of effecting others.
There are
less people to answer questions, write examples, create wikis,
debug weird
build problems, a few more last minute regressions sneak in, a
few more
builds come in just a few hours late, and all these have ripple
effects
that multiply. (That is one reason for some of the "hard
deadlines"
in producing some of our milestones, etc. ... that is, to
minimize chances
to ripple). So, it is hard. I agree with that.
Thanks. My only additional comment is that if this trend really
matters to people...that care about this organization...then
something should actually be done...because being starved out of an
organization doesn't seem to me to be a natural consequence of doing
an quality open source project.
But I think mostly due to
things besides the requirements increasing. And we'll all
continue to try
and make it easier while also making Eclipse better.
So, for some concrete advice. If there are
specific
issues you or anyone think are "too hard", you can always open
a cross-project bug, for at least discussion, if not solution.
Such as
"signing jars at Eclipse is too hard to accomplish" or "Babel
participation should be fully automated", as fictitious
examples.
Or, if you have very high level, sort of philosophical issues
about Eclipse
(or the Planning Council) ... then a blog is probably best. But,
if you
want to get the Planning Council to change requirements for
participation,
then working through your Planning Council representative is the
most effective
way to do that.
My last comment is that the yearly simultaneous
release
is very deliberately meant to be voluntary. It is extra work. It
is not
for everyone. And those who join should do so with the goal of
making their
project and Eclipse better ... it'd be kind of sad if it was
just to "...
hit the lowest possible minimum bar, just because someone said
we had to".
And, honestly, I have sometimes thought some newer or smaller
projects
felt a little too much pressure to participate. I'm not sure why
they do.
I guess to prove they could do it? that they could not only
"graduate"
but graduate all the way into a Simultaneous Release? A tough
row to hoe.
But, there are, after all, many advantages to participating, so
hopefully
most find the added effort worthwhile. But just because a
project
is not in the yearly release in no way means it is a "bad
project"
or anything. Every project at Eclipse must always act according
to what's
best for its committers and adopters; and that is not always the
same for
all projects -- so I think you are asking the right questions;
whether
your project should participate. It is good not to be on
autopilot, and
just assume everyone always needs to be in the yearly release.
There are
pros and cons, and only you (and your committers and adopters)
can weigh
those costs and benefits.
Yes, of course I know it's voluntary. ECF is a mature project and
has been part of the simultaneous release for the past 4 years. I
would venture that we have more than the average consumers/community
for EF projects. Yes, the simultaneous release would be of benefit
to our community (which is why we've done it)...but here's what I'm
faced with: which is more benefit to the ECF community?
Finishing/testing/releasing the ECF impl of OSGi 4.2 Remote Service
Admin [1], or doing the simultaneous release tasks? Which serves my
community better/more? That's the judgment that I'm forced to make.
Just remember, the intent is to make the yearly
release
and Eclipse better. I look forward to your continued
participation in that
process.
I know that's the intent...I'm not questioning anyone's intent. But
looking at the bigger picture...what I put to everyone reading this
is: Is that what's happening?
Thanks David.
Scott
[1]
http://eclipseecf.blogspot.com/2011/01/ecf-35-supports-osgi-42-remote-services.html
|
