Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Buildship to join Mars

As a representative of the RT PMC, I'll vote '0'. However, as someone who has seen his fair share of early (dare I say rushed) releases, and independent review would be welcome. The reputation of Eclipse has suffered in the past because of early releases. It doesn't matter how stable p2 was after 3.4, a lot of people hate p2. Eclipse and Maven integration "doesn't work" despite the fact that m2e has gone through several iterations and is pretty good now. And everyone knows that 4x stream is "slower, buggier, worse" than 3.8 -- no matter how much work goes into 4.x.

A 1.0 doesn't need to be 'complete' and certainly doesn't need to be perfect, but a lot of users will judge our Gradle support with this release. Are we confident that the project will meet the expectations of those users?

Cheers,
Ian


On Fri, Apr 10, 2015 at 7:49 AM, Chris Aniszczyk <caniszczyk@xxxxxxxxx> wrote:
+1, I totally get Markus' sentiments, but what Doug says it's true

Having Buildship be part of the release train now will help the Eclipse community in the long run.

On Fri, Apr 10, 2015 at 9:10 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
I think Buildship has the best mentoring that any project has ever had getting onto the train. Comparing with past problems isn’t probably fair to everyone working so hard on this.

+1 for getting them on the train and into the Java EPP.

Doug.

From: Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
Reply-To: Eclipse Planning Council private list <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Friday, April 10, 2015 at 9:55 AM
To: Eclipse Planning Council private list <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-planning-council] Buildship to join Mars

Wayne,

Gallia est omnis divisa in partes tres. That being said: My own personality is divided here into three parts, too.

As a mentor of the Buildship project, I'd simply say... yes, certainly, they should be in.

But if I'm switching my role to a Planning Council member, or to an EPP lead, I come to a completely different judgement. Very different. We've seen so many projects in the past that had problems with all the little things that are important for being part of the Simultaneous Release. You are implying that all the Simultaneous Release Requirements are easy to comply with, and that was (too) many times my own thinking, but experience tells us another story. They are harder to meet than we think, especially for new and inexperienced projects, and there are good reasons why mature projects define their feature freeze and API freeze for earlier milestones in order to have more time to stabilise. On the one hand we have projects working on their ramp-down plan... on the other hand we have new projects that are thinking about joining for the first time... this doesn't feel right to me.
Keep in mind, we are talking here about a project joining late that didn't have an existing codebase (nor userbase) some months ago. This kind of risk feels far too high to me.

I think it is not only fair, it is even a good idea to ask for the judgement of some independent Gradle experts. I see this more as a replacement of missing community feedback, definitively not an offence like in your mail.

Speaking of community: From a community point of view I'd appreciate to have Gradle support. But even then I prefer to have a stable 1.0 release at a later time, maybe together with Mars SR1, instead of a 0.x release that has been pushed into the June release.

So what are the alternatives? How would it feel to open the door with Mars SR1 for them? That would give them some time to build up a community of early adopters, people who are really willing to help finding the first serious bugs, building a community of more developers that get in touch with the code base.

Other ideas for alternatives that we can discuss with them?

So far I'm not convinced that this push is the direction that we (as a community) should go (which is my polite way of writing -1).

Thanks,
Markus




On 10 April 2015 at 15:26, Ed Merks <ed.merks@xxxxxxxxx> wrote:
+1


On 10/04/2015 3:04 PM, Wayne Beaton wrote:
I agree that this is rushed. This is an example where doing the right thing is more important than following the rules. In terms of perception in the community, the benefits outweigh the risks (IMHO).

Again, it's not fair to require that Gradle support be something that "users need and want". We do not make that requirement of any other participating project in any other context.

The big thing that we're missing is assurances that Buildship plays well with others. At least theoretically, other participating projects provide this by participating in the milestones.

It seems to me that a reasonable added criterion would be for us to have those assurances that Buildship is stable and doesn't cause problems in other plug-ins.

So, I'll extend the criteria:

* Conformance with the EDP;
* Conformance with the rules for participation in the Simultaneous release; and
* Confirmation that Buildship installs and works without unintended side effects in all of the Mars M6 packages.

Does this make it better?

FWIW, I reviewed Buildship for conformance to the Mars participation rules. They need to sign their JARs and tool their update site for mirrors, but are otherwise in conformance, AFAICT. They're addressing those issues.

Wayne

On 07/04/15 08:18 AM, Daniel Megert wrote:
Hi Wayne

I agree with Doug that this looks a bit rushed. As already mentioned in the call, I would roll this out via Marketplace with the option to join SR1. However, I will +1 your proposal if we hear from various Gradle users that this is the tooling they need and want, and that it works well for them.

Dani



From:        Wayne Beaton <wayne@xxxxxxxxxxx>
To:        eclipse.org-planning-council@xxxxxxxxxxx
Date:        04.04.2015 20:15
Subject:        [eclipse.org-planning-council] Buildship to join Mars
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx




Greetings Planning Council.

As I stated on the call, I believe that Buildship conforms to the EDP and--pending completion of the IP due-diligence process--is ready to do a proper release from Eclipse.

I have some further work to do to confirm that Buildship meets with the simultaneous release participation requirements.

On this Wednesday's call, we had discussed getting some independent Gradle experts to sign-off on the quality of the project. After some reflection, it occurred to me that we do not make this requirement of any other participant and so I consider it unfair to impose this requirement on Buildship. I would like to remove this from any acceptance criteria.

The EMO considers the inclusion of Gradle tools important for this release. I've discussed why we think this is important at length, but am more than happy to provide more background if necessary. The quality of this new Gradle support is very important, so we're going to take the unprecedented step of connecting with Gradle experts from the community to ensure that the contribution is of the necessary quality. But, again, I don't feel that this is a reasonable criterion for acceptance of the project as part of Mars.

As we discussed, there are two levels of acceptance here. First, we need the Planning Council to allow Buildship to join the simultaneous release. Once on board, I will work with the package maintainers to determine if they will include Buildship in their package definitions or not. There is another further decision to make regarding whether or not it is included in the "Eclipse Projects" Market that we discussed for the Eclipse Marketplace.

With this in mind, I respectfully request that the Planning Council set the following as the acceptance criteria for bringing Buildship into the simultaneous release:

* Conformance with the EDP; and
* Conformance with the rules for participation in the Simultaneous release.

I trust that the Planning Council will accept my assertion that these criteria have been met after I've done my review.

If anybody would like to propose additional acceptance criteria, please do so ASAP.

Since time is tight, I will ask that we start the vote immediately using our standard voting rules. Please respond on this thread with +1, 0, or -1 by EOB on Friday, April 10/2015.

Thanks,

Wayne

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

[attachment "eclipsecon-100x100-roundgoing.png" deleted by Daniel Megert/Zurich/IBM] _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
EclipseCon
            France 2015


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



--

###
EclipseSource Group
Telefon: +49 721 664733-0 (GMT +2)
Telefax: +49 721 66473329

http://eclipsesource.com


Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



--
Cheers,

Chris Aniszczyk
http://aniszczyk.org
+1 512 961 6719

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Back to the top