|
Wayne,
On 12/03/14 14:51, Wayne Beaton wrote:
According to the EDP, a release requires a review. Reviews run for
a week, which means that there isn't enough time to do a release
before EclipseCon. I will, however, do what I can to help you get
what you need assembled for a release during EclipseCon. More on
this below...
--
Maven Central is a wonderful service and we support Eclipse
projects putting their artefacts there.
From an intellectual property point of view, Eclipse projects
should be consuming artefacts from the Eclipse downloads server as
part of their build.
AIUI Vert.x is an Eclipse project and we consume artifacts from
Maven Central as part of our build. Is this wrong? All the
dependencies have been IP checked so I don't see why this is an
issue.
This
doesn't impact Vert.x directly, but does have an impact on any
potential Eclipse project consumers. The logic behind this is that
we don't have control over those bits. They could change. Further,
there is some risk that alternative versions of compatible (but
not IP cleared) artefacts could be consumed.
The bottom line is that the IP Policy does not support consuming
artefacts from Maven Central. If there is will, we can
collectively make a case to change this. The RT PMC is an obvious
group to lead this sort of charge.
I think that my original response reasonably described the why. If
there are specific points that need to be addressed, I'm open to
the conversation.
There is no current requirement to sign anything.
--
Characterizing the process as taking weeks is not accurate. There
is, however, some investment of time required.
We need to do a release review. Before we can start the review,
you need to create some review documentation and get approval for
it from your PMC. In addition, you need to assemble your IP Log
and submit it to the IP Team for review.
The process is outlined here:
https://wiki.eclipse.org/Development_Resources/HOWTO/Release_Cycle
You have created a rudimentary plan for the 2.1 release already
[1]. While I might prefer that you use themes in the plan, your
use of the delivery field is reasonable. The next step is to
provide review information. Minimally, I need to see an "elevator
pitch" in the description for the release: how would you describe
this release in 15 seconds?
Well.. this is the thing. The way we do releases is we try to do a
release every 4-6 weeks. There are no "special themes" for releases.
It just contains the next lot of stuff that is on the TODO list,
which can be seen in Bugzilla. Some weeks we might two releases in a
week.
The only way we can continue that model right now in the Eclipse
process is to call each of those releases a "milestone" so we can
fly under the radar, but to me a milestone release is really no
different to a "proper" release.
All
of the other fields are optional, it's the PMC's call to determine
how much is enough (I'm inclined to encourage the RT PMC to look
specifically for a description of any security issues). I do like
to see a check mark next to the "API Certification" field, and a
link to a new and noteworthy document (if such a document exists).
You can use the IP Log generator [2] to create and submit the IP
Log. Please give it a once-over to make sure that nothing obvious
is missing (e.g. a contribution). If there's an error, please let
me know. FWIW, I recently upgraded our services to support
projects running on GitHub. I believe that I've tested it pretty
thoroughly (using Vert.x in particular). All you need to do then,
is log in and click "Submit".
If I can have PMC-approved release documentation in place by
mid-day tomorrow, I'll schedule a special review period to get
this done by Wednesday next week.
Short version:
* Copy your release bits to the download server
* Update the project metadata [3] to include a link to the
download.
* Change the release date to March 19/2014.
* Provide an "elevator pitch" description in the release document
[1]; and check the "API Certification" check box on the review
page.
* If you already have such a thing, provide a link to the new and
noteworthy document on the review page.
* Provide any other optional information that you think may be
valuable for the PMC or community.
* Send a link to the release document to the PMC and ask for
approval.
* Send a note to emo@xxxxxxxxxxx
requesting the release review be scheduled along with a link to
the release document
* Open the IP Log generator[2]. Log-in if you need to. Click
"Submit"
We'll take it from there.
I think that I just described 20 minutes.
HTH,
Wayne
[1] https://projects.eclipse.org/projects/rt.vertx/releases/2.1.0/plan
[2] http://www.eclipse.org/projects/ip_log.php?id=rt.vertx
[3] https://projects.eclipse.org/projects/rt.vertx
On 03/12/2014 09:58 AM, Mike
Milinkovich wrote:
On 12/03/2014 9:38 AM, Tim Fox
wrote:
Any
unnecessary process is a big deal to me.
"Unnecessary" is purely a matter of perspective. There are
actually very good reasons for every single thing we do at
Eclipse. Literally. We question every single rule and process we
have regularly. They are not necessarily optimized for any
particular project, and we spend far more time thinking about
ease of consumption into commercial products than most. But
there are no rules which cannot be rationally explained.
I could be wrong, but I'm pretty sure we have no rules against
projects putting stuff on Maven Central. We only have
rules against projects consuming stuff from Maven
Central. By all means publish your stuff on Maven Central and
bintray in addition to eclipse.org.
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|
