Wayne,
We are more or less to release 2.1 and I'd like to get this out
before EclipseCon. Right now, it's more or less just red tape like
this which is bogging us down. We haven't had a single user
complain that downloads aren't signed or they aren't on the
Eclipse downloads - they really don't care.
I'd like to release 2.1 anyway, and deal with these remaining
process issues after the release. This is what we've been doing
successfully up until now *anyway* so I can't see that it really
makes any difference.
On 11/03/14 16:51, Wayne Beaton wrote:
Hi Tim.
This may change in the future (perhaps as we demonstrate success
with our existing social coding efforts). For the time being,
however, we consider hosting downloads on Eclipse hardware as an
important aspect of growing community.
Consistency in where our projects host downloads makes it easy and
predictable for consumers. Your existing consumers know where to
find things, but new people just finding the project (especially
those with familiarity with Eclipse already) will expect to find
them on our downloads server.
Vendor neutrality. We need to be able to pick up and continue if a
third-party provider disappears. Hosting on eclipse.org hardware
gives us options in tihs regard. Further, it gives other potential
distributors more freedom to distribute your code without having
to investigate (and potentially overcome) terms of use and
licensing concerns from the third-party vendor. IANAL, but with a
quick glance, there are some terms of use that may prevent (if
only because of their own internal legal department) some
organizations from being able to provide links to the software
hosted on Bintray.
Confidence. Adopters tend to have more confidence that bits from
eclipse.org are the "official" bits.
From a pragmatic point-of-view, as part of our release process, we
have some tools that review the bits. These tools expect to find
project downloads on our downloads server.
FWIW, we need to discuss signing official project builds. I'll
start this discussion in another thread.
HTH,
Wayne
On 03/10/2014 07:03 AM, Tim Fox
wrote:
Wayne - I am interested to know why
is it important that downloads are on download.eclipse.org?
A Vert.x user simply cares that they can get their download
easily - this is something we already have on bintray.
If the answer is "because all Eclipse projects must do this"
is the answer, I wouldn't consider that a good answer. Process
for the sake of process is no good for anyone.
On 26/02/14 15:30, Wayne Beaton wrote:
Put your projects downloads on download.eclipse.org. We can
help you sort out how to do that if you need assistance.
They can be distributed via bintray as well.
Wayne
On 02/26/2014 04:29 AM, Tim Fox
wrote:
On 18/02/14 21:38, Wayne Beaton
wrote:
The IP Log generator update is complete.
http://www.eclipse.org/projects/ip_log.php?id=rt.vertx
More information is here:
https://wiki.eclipse.org/Development_Resources/Automatic_IP_Log
The other thing that we need to see before we can approve
the IP Log is actual downloads from the project. At
present, the Vert.x downloads area is empty.
Wayne, we currently use bintray for downloads - how do you
suggest we proceeed here?
Wayne
On 02/18/2014 01:45 PM, Wayne
Beaton wrote:
Hi Tim.
The plan is one bookend of the release cycle [1]. The
plan (at least a rudimentary "this is sort of what we're
thinking that we'd like to do with the release" plan
should be in place at the beginning of release
development. The plan can evolve over time. It is a
means by which the community can prepare for and
participate in the release; it's a basis upon which
adopters can form their own release plans.
At the end of the release cycle, you need to complete
the review information. This is generally a
retrospective "this is what we did" sort of thing with
some focus on ensuring that necessary quality exists in
the code and that all aspects of open source development
have been observed (i.e. the open source rules of
engagement).
The review also serves as a checkpoint for the IP
process.
So... please do the following:
1) Change the date. It should be in the future. I'll be
running a review that concludes on March 5, and then on
March 19. You can pick these dates, or some date that
follows one of them (the review date can be a few days
ahead of the actual release date).
2) Provide review information on the "Review
Information" page
3) Submit the project's IP Log for review [2].
4) Get approval on the completed review information from
the PMC.
Once this is in place, I can schedule the review.
Note that I just noticed that the IP Log generator isn't
functioning for the GitHub-based Vert.x project. I have
a fix that I'll deploy shortly. I'll let you know.
HTH,
Wayne
[1] https://wiki.eclipse.org/Development_Resources/HOWTO/Release_Cycle
[2] http://www.eclipse.org/projects/ip_log.php?id=rt.vertx
On 02/17/2014 03:25 AM, Tim
Fox wrote:
Hell All,
I am new to this game, but would like to release
Vert.x 2.1.0 soon. I have created a release plan here:
https://projects.eclipse.org/projects/rt.vertx/releases/2.1.0/plan
Thanks
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
|