[Release-wranglers] Preliminary To do list for release.

[Mike A. Harris]

On Mon, 16 Feb 2004, Jim Gettys wrote:

>Keith and I spent some time this morning putting together a
>preliminary list of things to do to get a release out the door.
>Comments?  What have we missed?  It has been a while since either
>of us wrangled a release out the door.
>
>Cycle until release: start as soon as possible
>==============================================
>
>generate Tarballs
>update jhbuild with any additional packages added
>Go through bugzilla, fix bugs.
>iterate until done.
>
>
>JHBuild
>-------
>Keith claims jhbuild can do either tarballs or cvs. We need to
>      do both. I've personally only used it for CVS builds.
>update jhbuild package for new stuff
>jhbuild tarball build configuration
>update jhbuild wiki page.
>
>setup regular IRC/calls of wranglers
>status reports
>
>Complete font work or decide to punt for this release
>	What is drop dead day?

Font work would be very nice and solve various problems.  I'd put 
this on the 'should' list rather than the 'must' list though.


>Decide patch strategy
>       strawman: adopt XF86 ddx and drivers from RC2 as is
>       Concentrate on dix and libraries patches
>
>Do patch work. Nakee has list of patches annotated at:  
>	http://www.cs.huji.ac.il/~elylevy/patchs
>	Needs annotation with exactly what files are touched by
>	each patch.

The more of us that go through these, the better IMHO.  Once the 
CVS repositories are ready for patch inclusion, I suggest we 
organize a "patch review" day, which is good time for everyone 
to agree to sit in IRC all day and discuss patches, and 
ACK/NACK them based on technical and other grounds.

How does that sound?


>Imake work *must* be done
>      2 options.
>      autoconf vs. version from tree.  Not clear what is best to do yet.
>
>tinderbox server OSDL has offered: 
>	ACTION ITEM: Keithp to call bluff of Tim Witham 
>tinderbox clients
>	  ccache: triggered by checkin or continuous.
>	One client build on fd.o possibly with ccache.

ccache is great for speeding up builds, but I have concerns about 
using it for generation of end user shippable binaries or for 
mass rebuild testing, as there are cases in which it can 
influenece the binaries produced.  They may be rarer 
circumstances, but having the real compiler tested is IMHO 
superior, unless a given architecture is very very slow, and/or a 
very limited resource.  It's also possible however that both 
types of builds could be done, perhaps using ccache most of the 
time, but having weekly builds that are full.  Just a 
thought/opinion.


> >Clients decision
>	autotool vs. imake
>	tentative: go with autotool of order 10 packages.
>	see: http://www.freedesktop.org/Software/ProposedAppsPackages
>	please review and make appropriate changes.
>	Questions: grouping, if any, of twm, xdm, xterm?
>             developer's package?
>
>Testsuite needs to be run.

Yep, running VSW5 needs to be set up too.  Rik Faith has some 
scripts that could help with this I think.


>Autotool XF86 ddx. Daniel is starting.
>	 Priority order: Linux, bsd, solaris, other as people do them
>		only Linux is showstopper for initial release.

Agreed as per confcall.


>Check after RC2 for patches we can apply prior to license change.
>Some patches aren't likely to be under XF86 license.

Yep, many are bugzilla contributions for example.  Anything which 
isn't 100% known, we should make every effort to track down the 
author, or to have one person pseudocode it and another 
reimplement.


>Would be nice to be able to build RPM's and Debs automatically. Far from
>clear we can do so initially: generating spec files files, etc,
>is work.

"good" rpm packages need a manual human being maintaining them.  
I'll be making rpms for Red Hat of course, and wherever possible 
I will be making it distribution agnostic.  The packages that go 
into our own stuff though are likely to have some Red Hat 
specifics present.  I believe that it is superior to share where 
possible, but often I find that rpm spec files that try to work 
on every single rpm based distribution, tend to not integrate 
well on any distribution.  I would prefer to start out with a 
generic spec, but if one can't be kept both sane, clean, and 
integrate well with all rpm based distributions in a nice manner, 
then multiple specs should be kept and maintained by the 
respective distribution maintainers.  Again, just a first thought 
on that.


>distcheck all packages, preferably passing in all modules if possible
>
>Per package work
>    Need list of packages, to keep track of this work.
>-----------
>AUTHOR's file in all packages
>ChangeLog file in all packages
>COPYING file in all packages
>INSTALL file in all packages
>README file in all packages.
>TODO file in all packages.
>
>Tag packages for release
>
>Generate the tarballs
>
>Generate rpm's and debs (in principle).
>
>Release notes for whole release
>
>Acknowledgments for all who have contributed, to XF86 in particular
>for the drivers.  I have some of this together from work I did
>for xlibs a week or two ago.

Also the DRI project, individual driver maintainers and large 
contributors whose names can be tracked down or brought to our 
attention, etc.

>build from tarballs.
>
>Verify functional bits. - sanity check X, client apps.

VSW5 would go here also I believe.

>iterate until done.
>
>Send release announcement.
>
>Drink beer.

Canadian beer.  ;o)


>Immediately set up for a dot release within a month or two
>after initial release.

Sounds like a fantastic idea.  ;o)


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat