[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tools-pmc] Re: tools-pmc Digest, Vol 19, Issue 13
|
Bjorn,
Many rules is a relative term and for those of us who are poor at following
rules it will always seem like many. I've been around since 2002, so the
changes seem to have happened often, though over a long period of time.
Perhaps that's just my perception though. I've often thought I understood
the rules only to find that I didn't, or they weren't how I remembered
them. I.e., I could have sworn that incubating components didn't need
release reviews; but I was wrong. And yes, yearly changes are in my
opinion a lot. Most folks will really have no idea that the rules have
even changed since last they looked. In Eclipse itself, we generally don't
break APIs so client assumptions tends to remain intact, but rule changes
at Eclipse can easily break our assumptions. Keep in mind too, that
complexity is always in the eyes of the beholder. Complex things will seem
simple once you understand them. Keeping the guidelines simple would be
good, and I'd be happy to help review them. Let's talk off line how we
might work towards a simple summary with pointers into other more complete
documents; I'm not very good at writing such things. I think you're right
that we're all partly to blame, though I would argue it falls more on folks
like me who should be providing better leadership than on the EMO or folks
like you; I'm not sure this was the role of the Architecture Council, but
with the advent of mentors, it will certainly become so. This issue is a
good topic for discussion there...
I suspect you're right that perceived changes might not be rule changes so
much as changes in policy that affect how the rules are interpreted or
enforced. The first continuation review will likely surprise many
people...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
Bjorn
Freeman-Benson
<bjorn.freeman-be To
nson@xxxxxxxxxxx> tools-pmc@xxxxxxxxxxx, Bjorn
Sent by: Freeman-Benson
tools-pmc-bounces <bjorn.freeman-benson@xxxxxxxxxxx>
@eclipse.org cc
Subject
10/18/2007 01:59 [tools-pmc] Re: tools-pmc Digest,
PM Vol 19, Issue 13
Please respond to
Tools PMC mailing
list
<tools-pmc@eclips
e.org>
Ed,
Eclipse has a whole heck of a lot of rules
Actually, I don't think it has very many rules (committers must be voted
in, new projects must be announced to the community, IP must be cleared
before release, ...), so perhaps the problem is that we (we, the EMO, and
we, the PMCs, and we, the Architecture Council) have not done a good job of
explaining them to the committer community. I'd like to fix that, but how?
Perhaps I should re-write the development process guidelines again but this
time work on a simple one pager version? Based on your experience with EMF
and Modeling and all the sub-projects and the various Bjorn-as-a-policeman
issues you've dealt with, what would you suggest I put in that one-pager?
Could you suggest an outline?
that tend to change rather frequently.
I disagree. They change once a year when the Board approves a new version
of the rules. Seriously, look at the CVS history around the development
process documents and you'll see that they just don't change frequently
(unless you consider once a year frequently)...
However, you believe they do change often, so I'm guessing that what's
happening is that each time you find something that you didn't know, you
make the assumption that the rules have changed when in fact the rules have
been the same but that nobody noticed the incorrect situations before. So
what's really happening is that the EMO is becoming more efficient and thus
has more time to spend making sure the constraints that we (collectively,
the Board, including the committers) set are being followed.
- Bjorn
--
[end of message]_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
