| Thanks, David. I have followed your advice and prepared the graduation review:
Regards, Etienne
> What is the next
step to officially leave incubation?
I did check the EDP, at
https://eclipse.org/projects/dev_process/development_process.php
and it does say
"The incubation phase
ends with a graduation review ... "
So, I think the easiest thing to do
is to do a "release record" for your 1.0.3 release, and there
clearly document it is a graduation review, and document all the "reasons
why you should graduate", such as those outlined in
https://wiki.eclipse.org/Development_Resources/HOWTO/Incubation_Phase
and especially this section:
https://wiki.eclipse.org/Development_Resources/HOWTO/Incubation_Phase#Graduating_from_Incubation
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 know it.
Hope that helps. (And, others might
have better advice than me ... that is just the way I would approach it).
Thanks,
From:
Etienne Studer <etienne@xxxxxxxxxx>
To:
Tools PMC mailing list
<tools-pmc@xxxxxxxxxxx>,
Date:
08/20/2015 05:02 PM
Subject:
Re: [tools-pmc]
[Request] Graduation from Incubation to Maturity of
Buildship
Sent by:
tools-pmc-bounces@xxxxxxxxxxx
Thanks, David. Your positive vote is highly appreciated.
And so is your feedback. See some comments/questions inline.
On 14.08.2015, at 08:51, David M Williams <david_williams@xxxxxxxxxx>
wrote:
+1
Great!
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,
on Eclipse
Projects page, you end up
on this page:
https://projects.eclipse.org/search/projects/buildship
And, there you can see "website", "code" and "downloads"
icons.
Both your "website" and "code" icons link to the code.
I suspect you want your "website" to point to
https://projects.eclipse.org/projects/tools.buildship
or, at least
https://github.com/eclipse/buildship/blob/master/README.md
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.
Thanks for the suggestions. I have created an issue for
this to ensure we tackle this in time for Mars 1.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=475534
= = = =
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?
I’ve updated the descriptions. I hope it makes it easier
to understand the difference between a build user and a build master.
https://projects.eclipse.org/projects/tools.buildship/releases/1.0/review
= == =
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,
IMHO).
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 on this.
= = = =
Congratulations on reaching this point in your project, and best of luck
as you continue to grow and evolve.
Thank you. We are excited.
Etienne
From: Etienne
Studer <etienne@xxxxxxxxxx>
To: Tools
PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date: 08/10/2015
11:34 AM
Subject: [tools-pmc]
[Request] Graduation from Incubation to Maturity of
Buildship
Sent by: tools-pmc-bounces@xxxxxxxxxxx
Hello
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
tools
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
(https://discuss.gradle.org/c/help-discuss/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
engagement
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
in eclipse.org’s
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.
Kind regards, Etienne, Buildship project lead_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc |
