Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-planning-council] Re: [cross-project-issues-dev] Bjorn "Knuckles" the Ganymede Enforcer asks a question about STP...


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


Back to the top