We should check with Wayne. (via CC) As
far as I know, nothing more is needed ... but, I do not know Wayne's end
of the process ... and if something else do or wait on from his point of
(And thanks in advance, Wayne).
Etienne Studer <etienne@xxxxxxxxxx> To:
Tools PMC mailing list
09/10/2015 05:16 AM Subject:
[Request] Graduation from Incubation to Maturity of
Buildship Sent by:
The review period of the Buildship graduation has come
to an end yesterday, Sep 9th. I’m not aware of any objections or comments
besides your +1. Does it mean that Buildship has graduated? If so, what
are the remaining steps to make this official (and to remove the incubation
logo from the project homepage)?
I don't see these so much like "passing a test in graduate school,
and you have to prove and defend your ability to graduate", but more
as a way to take a step back, discuss things with your team, and document
where your project is and how it's operating, brag about your project ...
and write things you and your team can take pride in ... and, then the
process will be disappointingly anticlimactic ... and be over before you
Hope that helps. (And, others might have better advice than me ... that
is just the way I would approach it).
I'm ok with this. I am not sure of the formal mechanism ... normally it
is part of a "release review (record)", but since you have just
done 'service' since your 1.0.0 version, I am not sure if that's required.
(Probably not, I'm sure Wayne will say, if so).
What is the next step to officially leave incubation? (and to get rid of
the incubation logo on the Buildship home page?)
= = = =
A minor thing ... some of your "project links" I think could
be improved. For example, If someone searches for buildship, or gradle,
Projects page, you end up
on this page:
And, of course should link to some download page ... even if it's just
wiki instructions and URLs on how to install from p2 repo and perhaps link
to your active build pages too. Though, many projects have several options
... releases, milestones, and nightly builds, if nothing else.
And the links on https://projects.eclipse.org/projects/tools.buildship could use similar TLC (actually, I think they come from the same "metadata"
that you provide. (And, sorry, I am not sure, right off, where you enter it ... it used to
be the "Portal", but I think Wayne has (or, is?) providing a
new way to edit that data.
Another point to clarify: In your project description, you say "Buildship
1.0 is targeted towards Gradle users. Later versions will target Gradle
build masters." Keep in mind I am pretty naive, but I thought Gradle
was all about "building" so I am not sure what the difference
is between "Gradle users" and "Gradle build masters".
I wonder if you intend to say something else ... and if you could say it
differently, so that even I would understand what you mean?
Lastly, some high level advice. It seems a lot of your focus so far, is
interacting with "the Gradle community". That's good, especially
for "us", Eclipse, since it makes Eclipse (more) attractive to
Gradle users. But, I hope as your project matures, you interact more with
"the Eclipse community" and increase their awareness and possibly
their use of Gradle. It seems that would be advantageous to "you".
(And, I think good for Eclipse too, since it is a form of diversity,
We are doing this, I’d say, or at least we are trying to. We are in close
touch with several experienced people from the Eclipse world and integrate
their feedback to ensure that we can give developer companies out there
a Buildship that is really useful and practical to them. We are also trying
to speak about Buildship at conferences as much as we can (EclipseCon NA,
France, Europe). Some of the people in the Eclipse community have also
started to give presentations on Buildship. We will continue our efforts
= = = =
Congratulations on reaching this point in your project, and best of luck
as you continue to grow and evolve.
The Buildship project has become part of the Eclipse Mars release train.
We are part of the aggregation build since last week, and we have requested
inclusion in the Java package and the Eclipse Committers package (answer
pending). We have gone through a review process with Buildship 1.0, released
in July with Eclipse Mars in the new Marketplace.
We will release Buildship 1.0.3 in time for SR-1 with various fixes to
the 1.0 release.
Today, we want to request to graduate out of incubation into maturity in
time for Mars SR-1. We have read the documents and believe we are ready.
Some details below:
1) Working and demonstrable code base with extensible frameworks and exemplary
The current focus of Buildship is to be a tool for Eclipse users. This
resolves the biggest pain point: having a solid tool to work with Gradle
from within Eclipse. The framework aspect will be covered once we have
a better understanding what (if anything) third parties actually want to
build on top of Buildship.
2) Active communities
We have an active user community. All communication between the Buildship
project and the community takes place at the Gradle Forum for Buildship
This is the most natural place for Gradle users to ask any Gradle-related
questions, including questions about Buildship (which sometimes turn out
to be Gradle core questions). Many issues (fixes/enhancements) are reported
in the Gradle Forum for Buildship, and we actively handle them - many issues
being fixed within a short period of time.
We have a multi-organization community. We have an active relationship
with various companies/entities; amongst them are Vogella, RedHat, Itemis,
and some others. We receive PRs from them that fix bugs and provide new
functionality. We also get constant feedback from developers from the community
through BugZilla and through the Forum.
3) The project is operating fully in the open using open source rules of
The source code is hosted publicly on GitHub. Discussions take place in
the Gradle Forum for Buildship which is open to everyone. Issues are tracked
BugZilla which is public. Daily snapshots of master are published as public
update sites on eclipse.org.
All stories we intend to work on at some point in time are described in
GitHub. We respond to all community input quite fast as a sign of appreciation.
We highly value input from the community.
4) The project team members have learned the ropes and logistics of being
an Eclipse project
We have gotten excellent and very close mentorship from the beginning on
from Wayne Beaton and Markus Knauer (thanks!). We adhere to the process
to the best of our knowledge and feel comfortable with the process. We
actively promote Buildship at conferences, either Eclipse-related events
or Gradle-related events.
We get a lot of very positive feedback for Buildship through various channels.
Being out of incubation is the next step. Thanks for looking into it.