Re: [cross-project-issues-dev] Bjorn "Knuckles" the Ganymede Enforcer as

[David M Williams <david_williams@xxxxxxxxxx>]

I'd vote +1 to have STP not be part
of Ganymede. 

I hate to sound negative, but  we
are long past the point of "rectifying" the issues. 

Part of purpose of Ganymede (and part
of the good reputation of Eclipse) is being predictable, and being involved
in the whole process, all along .... not to just "get it done by the
last possible date". 
So, I think we should have to courage
to clearly standup for these other ideals ... as uncomfortable as it makes
us to "be the bad guys". 

I recall 2 things from the planning
meetings where we discussed this last year: 

1) we said that if it came to it, we
would make the decision based on costs/benefits to Ganymede ... and so
far, I haven't heard anyone say "we really need it to have a complete
Ganymede solution" (the idea was that, as Ed was fond of repeatedly
saying "there's no way you are going to vote out EMF"  [To
which Bjorn repeatedly reminded him "it is for that reason that there
was no way that EMF would not live up to expectations". ] But the
idea was that there would be trade-off between what was needed, and what
the "costs" would be (for example, i.e. leaving out EMF would
also mean leaving out WTP, etc., ... pretty expensive trade-off so it's
have to be a huge transgression). So, is there any concrete need to Ganymede
to leave STP in? I'm sure they would ship/release shortly after, they've
already gained the added benefit of accelerated IP process, etc., so would
assume that it would not impact the adopters of STP. (And if so .. that's
a whole separate issue). So, besides "being nice guys" and letting
STP stay, what is the business case? 

2) the second memory I have from that
meeting is of Mike saying "there is no way the Planning Council will
have the courage to vote someone out ... so it should be an EMO decision".
So ... are we proving him correct? 

Lastly, I vote +1 since this sort of
"last minute" stuff causes stress to all of us (including STP)
so what's so important to put up with that stress!? 

I personally have no stack in this issue
(well, except for the stress, and I do think it's important to adhere to
our higher Eclipse principles .. which STP hasn't). ... that is, I do not
use or build on STP ... in which case I might feel differently. 

But, I am also concerned about precedent
... if we can not make this decision in what to me is such an obvious case,
then Mike's right, we never will, and we may have to give up pretending
like we have agreed to rules, and go back to everyone doing what ever they
want. (which to me wouldn't be that bad .. I like doing my own thing :)
 ... but, I think it would be extremely bad for Eclipse).

From:	Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
To:	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, "eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
Date:	06/11/2008 12:37 PM
Subject:	[cross-project-issues-dev] Bjorn "Knuckles" the Ganymede Enforcer        asks a question about STP...

---

Ganymedians,
Given that:
1.        STP
has bad data in their feature files: https://bugs.eclipse.org/bugs/show_bug.cgi?id=236640
2.        STP
doesn't yet sign or pack their jars (information from today's release review
call) 
1.        See
http://wiki.eclipse.org/Ganymede#Must_Do
items 13, 14
It almost seems like, that STP does not qualify under
http://wiki.eclipse.org/Ganymede#Must_Do
item 2 "have a mature build process". We're 12 days from the
'final released bits' date and 2 days from the 'final build date' and STP
doesn't have a good build that conforms to the must dos and "plays
well with others".

Are we going to vote them off the island?
- Bjorn

P.S. I really regret being the "heavy" here because I know that
Oisin and the STP team are nice people, they are well intentioned, they
are trying hard, but the facts are what the facts are.
-- 
[end of message] _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev