[OPEN-ILS-DEV] Rethinking the release process: (was: Trac usage, EG Versions)

[Joe Atzberger]

I agree that time-based releases would be dependent on:

   - fuller coverage of automated tests,
   - a explicitly executable if not automated upgrade path,
   - and a more automated (basically easier) release process.

Defining categories and pairing people to them as default assignees is very
much in line with the questions I was asking about versions.

  * Patch management: I've seen a few contributed patches get sent to
> the list with little feedback from those of us with commit bits. Some
> other projects more formally track the status of patches to ensure that
> a given patch gets reviewed and that it is either accepted, rejected, or
> that feedback is given and that a revised patch has been requested -
> either via a wiki page, or via a regular list of patches sent to the
> development mailing list. Someone, or someones, could be responsible for
> tracking the disposition of all patches (and helping us ensure that we
> give feedback to would-be contributors in a timely fashion).
>

This is a good idea, but I'm not sure what the best (OSS) tools for the job
are.  Trac (or bugzilla) can stand in for a lot of that functionality, by
just having authors attach their patch to the bug or enhancement ticket that
prompted it.  That covers all the not too large, not too small patchsets and
allows for comments, feedback, revisions and instantaneous status.  However,
this usage would also argue for opening up trac so that anybody could add or
comment on a ticket.  It would have to be as open as the dev-list,
effectively.


> On another track, versioning, right now I think there are three or four
> active release branches:
>
> 1.2 - hopefully limited to just bugfixes (but, last I heard, there were
> still a lot of sites on 1.2)
> 1.4 - hopefully limited to just bugfixes (now that we have a usable
> release in 1.4.0.6, by all accounts)
> 1.6 - holding tank for a ton of new features, with acquisitions and
> serials and the event-driven infrastructure
> 2.0 currently aka trunk - holding tank for everything else in
> development
>

To me, filing the bugs I currently see in trunk against a hypothetical 2.0
version seems inaccurate and too specific.  If unfixed, a given bug would
also continue to affect 2.1, 2.2, etc.  Right now we only get a
single-selection in trac's dropdown, hence my request for a "trunk" listing
there.


> Also, perhaps we should just use increments of 1, rather
> than suggesting that an odd release number is considered unstable. We
> haven't pushed out an odd release since 1.1 (May 2007), so we're not
> really making use of this distinction.


Good point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20090914/ba11c81b/attachment.htm