[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion
|
Scott,
Actually, this thread started out as David William's question about the
enforcement policy of the train's must do's; check the archive. ;-)
I did try to inject Mike's concerns about usability from weeks gone by into
the discussion because I think it's important to avoid, as Mike says, just
giving up because it's a hard problem. But that wasn't the original point
in the conversation.
I agree with Doug Gaff. It's not sufficient for the board or the EMO just
to hand down edicts and expect they will get done because they'll be
enforced with an iron fist (nor am I suggesting that this is what the board
or EMO are doing, just that if they did, it wouldn't work). I suspect
someone is reading this note and thinking, Ed, you're being passive
aggressive again. :-P Maybe I'd better quit before I've annoyed
everyone...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Scott Lewis
<slewis@composent
.com> To
Sent by: "eclipse.org-planning-council"
eclipse.org-plann <eclipse.org-planning-council@eclip
ing-council-bounc se.org>
es@xxxxxxxxxxx cc
Subject
11/01/2007 05:14 Re: [eclipse.org-planning-council]
PM A suggested topic for
PlanningCouncil Discussion
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
Although I agree with Ed about his process observations, I want to comment
that I thought this discussion started out with the Board desire to
*improve* the quality of the release train for an integrated end-user
experience. I didn't think this was intended to become a referendum on
the release train projects individually (as I believe the dev
process/reviews, etc are designed to provide such guarantees...as John
points out), but rather how we were all going to get to the jointly-desired
result: a high quality end-user experience for the release train.
Scott
Ed Merks wrote:
Mike,
I didn't suggest giving up. But I am suggesting that I will not
personally be on a quality police force. I would be much happier
with a
growing release train of ever improving quality. If we want to start
kicking off the train cars we thing are crap, I believe this process
will
break down, especially considering that folks downstream from crappy
cars
will drop of by transitivity...
I'm also not sure that 50 small projects are any different form 25
projects
of 1/2 the size, so I think this focus on the number of projects is
misguided. All that matters is quality not quantity and there are
lots of
things we could do to improve the quality. And it's not just the
code we
ship that affects perceptions. For example, some projects might
consider
paying more attention to their newsgroups...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
"Mike
Milinkovich"
<mike.milinkovich
To
@eclipse.org>
"'eclipse.org-planning-council'"
Sent by:
<eclipse.org-planning-council@eclip
eclipse.org-plann se.org>
ing-council-bounc
cc
es@xxxxxxxxxxx
Subject
RE:
[eclipse.org-planning-council]
11/01/2007 04:24 A suggested topic for
PM PlanningCouncil Discussion
Please respond to
mike.milinkovich@
eclipse.org;
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
I do not buy the argument that since you cannot measure quality
objectively
you should just give up. And yes, some mature projects could fall
below
this
hypothetical bar.
But as far as I'm concerned shipping a smaller, higher quality
release
train
would be just dandy.
-----Original Message-----
From: Ed Merks [mailto:merks@xxxxxxxxxx]
Sent: Thursday, November 01, 2007 4:06 PM
To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-planning-council
Cc: 'eclipse.org-planning-council';
eclipse.org-planning-council-
bounces@xxxxxxxxxxx
Subject: RE: [eclipse.org-planning-council] A suggested topic
for
PlanningCouncil Discussion
Mike,
We don't have a bar for measuring quality objectively so that
makes
setting
a bar for that extremely difficult. How could we measure this
and
wouldn't
some mature projects fall below this bar?
I also don't think it's reasonable to assume that incubating
things
have
low quality nor to assume they have CQs that we must cut back
on;
mature
projects seem to generate an awful lot of CQs all on their own.
I very much share your sense of concern about quality but I see
no
solution
for policing it. Peer pressure is the only viable solution
I've heard
so
far. Given resource from the foundation itself, e.g.,for
testing or
usability analysis, I'm sure a lot more could be accomplished,
but if
that
resource is already streched just by the IP load, that doesn't
seem a
viable alternative either. I think we're all ears for
solutions...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
"Mike
Milinkovich"
<mike.milinkovich
To
@eclipse.org>
"'eclipse.org-planning-council'"
Sent by: <eclipse.org-planning-
council@eclip
eclipse.org-plann se.org>
ing-council-bounc
cc
es@xxxxxxxxxxx
Subject
RE:
[eclipse.org-planning-
council]
11/01/2007 03:55 A suggested topic for
PM PlanningCouncil
Discussion
Please respond to
mike.milinkovich@
eclipse.org;
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
Doug, Doug, Ed, et al,
What you are suggesting is an even lower bar than what we have
had in
the
past. At least on paper, if not in practice.
The problem with this approach is it means that the release
trains just
get
bigger and bigger and with no incremental improvement in the
overall
quality of what?s coming from Eclipse. Shipping a big bag of
stuff that
doesn?t work together is not going to help us build a
reputation for
quality. It will destroy it. And once you have destroyed a
reputation
for
quality, it can take a generation (e.g. ~20 years) to get it
back, if
ever.
As a purely practical matter, I honestly doubt that the Eclipse
Foundation
as the IP resources to review and approve all the CQs to ship
30
projects
on the same day. So if you guys don?t come up with some rules
that
raise
the bar and limit who has the process maturity and quality to
get in,
don?t
get mad at me for making rude and arbitrary decisions J
I completely understand that what you?re recommending is the
simplest
and
easiest approach. But IMHO (a) it?s the wrong thing to do for
the
Eclipse
community and (b) it is unlikely to work in practice.
Mike Milinkovich
Office: +1.613.224.9461 x228
Mobile: +1.613.220.3223
mike.milinkovich@xxxxxxxxxxx
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On
Behalf Of
Gaff, Doug
Sent: Thursday, November 01, 2007 2:32 PM
To: eclipse.org-planning-council
Subject: RE: [eclipse.org-planning-council] A suggested topic
for
PlanningCouncil Discussion
All,
As far as I?m concerned, the only reason to kick a project off
the
train is
if they consistently fail to build and update their site at
each
milestone.
Simply put, the ejection is because ?Project X keeps holding up
the
release.? Furthermore, I think it should come to a vote by all
of the
projects on the train to kick a single project off.
Everything else should be a strongly encouraged optional
requirement,
and
we should use public humiliation to police those requirements,
e.g. ?I
noticed that Project Y is not optimizing their jars, shame on
you.
Please
fix it.? Clearly there are technical must do?s that physically
put a
project on the train, and they should be stated as such.
Bottom line, I think we should err on the side of inclusion,
and leave
it
up the projects to prove that they can or can?t keep up with
the
milestone
schedule. If they can?t keep up, then their processes aren?t
mature
enough.
Doug G
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On
Behalf Of
Scott Lewis
Sent: Wednesday, October 31, 2007 5:17 PM
To: eclipse.org-planning-council
Subject: Re: [eclipse.org-planning-council] A suggested topic
for
PlanningCouncil Discussion
Hi Bjorn,
Bjorn Freeman-Benson wrote:
Doug, (and everyone)
I agree - if there are no people or people hours, there will be
no
code, no
matter how much the Board wishes for it to happen. One could
argue (I
have
argued) that the Board controls the people hours, so if they
want to
define
a requirement, they should supply the resources, but somehow
that
logical
situation doesn't always come true.
Do you really think it would poison the community if there were
a two-
level
train?
I think it would poison the community to have a two-level
train. I
think
we would quickly see different requirements and EMO treatment
(and
member
company support) for the 'corporate-run' projects relative to
all the
other
projects...those led by smaller companies and/or independents.
Seems
to me
this would eventually lead to inequities that many committers
would
consider unacceptable for a merit-and-value-based community.
A "meet all the requirements" level (the gold medal) and a
"simultaneously
release" level (the silver medal)? Maybe if the packages and
the main
update site contained the gold seal projects, but that the
silver
projects
were also (if there was time to review the IP) available at the
same
time?
It seems to me like this sort of classification would be
inherently
detrimental to 'silver medal' projects and differential to
'gold medal'
projects. That is, it may say nothing about their usefulness,
and/or
value
to be labeled as 'silver', but just the labeling by the
membership and
foundation will lead to end-user biases...with lower adoption,
tougher
distribution, etc., etc.
It does seem to me that if the Board wants to mandate that the
projects
have to do more/other in terms of integration/testing, etc for
the
release
train...and that the EMO should/must police/enforce the new
rules...that
there should be some recognition that this implies some support
from
the
membership to do the work involved. There are many ways that I
can
think
of to do this (contributing integration testing resources,
allowing
existing committers to work on related projects, etc., etc).
Unfunded
mandates don't really work IMHO...either for the committer
community or
for
the EMO.
Scott
- Bjorn
Doug Schaefer wrote:
As for requirements, other than holding up the IP process I?m
not sure
what
stick the EMO has to enforce projects meet the requirements. If
projects
don?t have the resources or the mandate from the employers of
the
resources
to do the work, it doesn?t happen. And if you kick projects off
the
train
because of that, that could poison the community. The best
stick still
is
influencing and that involves good communication channels open
between
the
requirers and requirees, and, of course, a reasonable set of
requirements.
--
[end of message]
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
