RE: release process for our plugins

["Gav..." <ga...@16degrees.com.au>]

> -----Original Message-----
> From: Tim Williams [mailto:williamstw@gmail.com]
> Sent: Friday, 28 May 2010 12:20 AM
> To: dev@forrest.apache.org
> Subject: Re: release process for our plugins
> 
> On Thu, May 27, 2010 at 5:16 AM, David Crossley <cr...@apache.org>
> wrote:
> > We do have a process sorted out for releasing of Forrest core.
> > [1] How to release Forrest
> > http://forrest.apache.org/procedures/release/How_to_release.html
> >
> > I reckon that it meets the ASF requirements. Please see
> > this email where i have before tried to ensure that we do:
> > [2] http://markmail.org/message/kwecoaue7p4qcy2v
> > To: forrest-dev
> > Re: Clarification on the release requirements
> >
> > Unfortunately the links are broken in that display,
> > so i tracked them down again.
> >
> > Here are a couple of places where Roy set out some
> > principles/policy/reasons-for-doing-stuff ...
> > [3] http://markmail.org/message/3odlybipss4wnczl
> > [4] http://markmail.org/message/njray5dbazwcdcts
> >
> > I reckon that it would be worth our while to review
> > that discussion.
> >
> > There is other background material at
> > [5] http://www.apache.org/dev/#releases
> > [6] http://www.apache.org/dev/release.html
> >
> > With those principles in mind, we need to attend to our
> > release process for our plugins.
> >
> > We don't actually yet have a process.
> >
> > Do "find in page" for "plugin" at [1] to see the steps.
> > You will reach a point where our doc says fixme
> > and refers to a draft document at
> > [7] $FORREST_HOME/plugins/RELEASE_PROCESS.txt
> > There are some other notes at
> > [8] http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
> >
> > We do have tools for doing "deploy" of plugins, i.e.
> > putting an updated version on the server.
> >
> > As described in [6] Releases FAQ,
> > "
> > What Is A Release?
> > Releases are, by definition, anything that is published beyond the
> group that owns it. In our case, that means any publication outside the
> group of people on the product dev list. If the general public is being
> instructed to download a package, then that package has been released.
> Each PMC must obey the ASF requirements on approving any release. How
> you label the package is a secondary issue, described below.
> > "
> >
> > It should be easy. For each plugin, the proposer puts a package
> > at their apache.org space. We each download, install, review,
> > and then vote. Then use the "release" Ant target rather than
> > the "deploy" target.
> >
> > However, we have another issue.
> >
> > We have been providing that software via our website.
> > If i understand correctly then we should be doing
> > that from w.a.o/dist/forrest/
> >
> > See some discussion at
> > https://issues.apache.org/jira/browse/FOR-1068
> >
> > Perhaps we should at least solve the "release process" issue now,
> > and leave the deployment issue until post 0.9 release.
> 
> The "release process" issue?  relative to plugins I assume?  The draft
> release doc in the plugins directory suggests that its possible to
> release plugins independent of the core but couldn't we, for now, just
> as well continue to do what we do and release the plugins with the
> core?  In other words, it seems to me we're meeting Roy's intent
> fairly well by releasing the whole bundle together - formal process,
> signed, etc.
> 
> I guess, what I'm wondering is... can we punt on plugin releases, move
> dispatcher to /plugins and just vote on the whole bundle as normal?
> Or, do you see something that needs addressing now, before a 0.9
> release?  Sorry, you were probably hoping for answers not questions:)

To me, a plugin means an add-on, in addition to, extra. However some of our
'plugins' are in fact required if Forrest is to be useful. Anyway,

The plugins (not whiteboard plugins) I think as you say, we could bundle
this
time around, it also shows that the plugin versions we bundle are guaranteed
to work with that Forrest release.

If this was somewhere else, where folks create plugins and work on them
alone
and maintain them alone independent of Forrest, then it would be easier, but
we
don't and it seems every plugin we have has to be maintained by forrest devs
in addition to the core in order to get a release out. That seems wrong to
me,
it gets harder each time as we accumulate more plugins. So that means I 
guess I'd rather plugins be done separately of a core Forrest release in the
future - if a plugin doesn't keep up, so be it I guess until someone wants
to take on maintaining it.

For this time, to get a release done quickly, I'm ok with doing what we have
always
done, as long as meets with guidelines.

Gav...

> 
> --tim