Re: [jetty-dev] Project meta data is out of date for rt.jetty

[Simone Bordet <simone.bordet@xxxxxxxxx>]

Hi,

On Fri, Jun 5, 2009 at 16:09, Jesse McConnell<jesse.mcconnell@xxxxxxxxx> wrote:
> We are going to have to start distinguishing between eclipse releases
> and or normal jetty community releases as they will not necessarily be
> 1 to 1 going forward...  We have technically not had an eclipse
> release yet as we have not had the release review yet. :)
>
> We have the Graduation review (which is also our first release review)
> on June 24th coming up and from that point forward we are going to
> have to be a little more select in what is getting termed an eclipse
> release and what is a normal jetty community release.  Our community
> releases can be released on our terms, but the eclipse releases have
> to go through a release review and then we are also going to have to
> have those jars signed and sealed by the standard eclipse processes
> (which I started to work out a few weeks back but haven't completed).
>
> I think as a project we should strive for a one to one eclipse release
> to community release relationship but I don't think we should hold it
> as a requirement for us.  The community releases are super easy to
> perform, whereas there is a heavier process involved with an official
> eclipse release.  Release review scheduling, docuware, update sites,
> renamed bundles, signed and sealed jars, things that are not easily
> managed with a maven plugin. :)
>
> This is something we are going to have to decide though.. Do we:
>
> A) perform our normal community release as we traditionally have done
> and then tack on the eclipse release process on the end of it if we
> are happy with outside eclipse community feedback (effectively
> isolating the eclipse community from some issues that might prompt us
> to make a subsequent community release)
>
> B) schedule our eclipse release reviews appropriately (2 weeks lead
> time, docuware updated, yadda yadda yadda) and prepare the entire
> release goop at once, mvn artifacts, update sites, bundles (signed and
> sealed mvn artifacts repackaged into p2 update site -
> http://wiki.eclipse.org/Jetty/Project/UpdateSite) and all of that jazz
> at the same time?
>
> I know it sounds bad to term it eclipse release and community release
> as eclipse is part of our community, but the incredibly varied types
> of artifacts we are having to produce here is overwhelming and complex
> so some distinction is required in my mind.
>
> * mvn artifacts - which are by and far the easiest to produce
> * jetty distribution bundle (.tgz, zip, etc) - easy to produce with assseblies
> * p2 update site - not difficult but very manual, take mvn artifacts,
> condition them (sign and seal with eclipse process), copy them around
> into eclipse instance, load eclipse, update the site project,
> regenerate update site, zip it, copy to download site, unpack
> * hightide - distribution bundling the jetty artifacts we can't have
> located anywhere near eclipse for IP reasons
> * deb, rpm - not sure current status of these atm, dyu was working on them

I think would be fair to have the SNAPSHOT, alpha, beta and RC
releases as "community releases" done via the usual maven means, but I
think will be better to have official releases done via the Eclipse
review.
P2 update done in sync with official release, hightide can go
independently, debs and rpms can go with the official release.

Cheers,

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz