[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-planning-council] A suggested topic forPlanningCouncil Discussion
|
Hi Team,
A different approach.
Can someone identify which one(s) of the current Ganymede must-dos are so
taxing that a project cannot accomplish them and risk being booted off the
train?
http://wiki.eclipse.org/index.php/Ganymede_Simultaneous_Release is the
list, all of which look pretty straight forward to me, with the exception
of (1.) and that being what level of testing a project needs to do with
other projects.
I think I missed what the controversy was.
Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / Modeling Tools
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>, <mike.milinkovich@xxxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|11/01/2007 05:03 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|RE: [eclipse.org-planning-council] A suggested topic forPlanningCouncil Discussion |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Ahhh! Can open...worms everywhere!!
- I don't think anyone should download the entire train release. They
should only download what they need based on their developer role. As
Doug S points out, EPP is a great step in that direction. I have no
desire to use the update manager to get the projects I want. We
shouldn't even support it, IMO. It's not maintained anymore.
- I very much want role-based testing of those downloads. However, I
need staff to do that when it's off cycle with my commercial release.
If this is strategic to the EMO/Board, then pony up. The board must
vote on staffing coordinated testing for Ganymede and member companies
must then present their test plans for everyone else to see and judge.
Having the EMO wish it doesn't make it so. Without commitment from each
member company, there will be no "trickle down" staffing to do extra
cross-project testing. That is the reality.
- The Foundation should support as many projects on the train as are
capable of being on the train. Ed's comments on scalability spot on.
If we're going to grow as a community, we have to be able to scale in
build coordination and CQ processing. Otherwise, forget all that
meritocracy crap and just declare that some projects are better and more
important than others.
Doug G
> -----Original Message-----
> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of
> Ed Merks
> Sent: Thursday, November 01, 2007 4:51 PM
> To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-planning-council
> Cc: eclipse.org-planning-council-bounces@xxxxxxxxxxx; 'eclipse.org-
> planning-council'
> Subject: RE: [eclipse.org-planning-council] A suggested topic
> forPlanningCouncil Discussion
>
> 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
