Things we ought to do to improve our packaging

Matt Mackall mpm at selenic.com
Tue Aug 6 13:53:34 CDT 2013


[this discussion needs to be cross-posted]

We've got a few long-standing problems with our current packaging:

- lag official release
- not automated
- not reproduceable by third parties
- not signed
- lack nightly builds
- notable missing platforms (RHEL)
- not uniform in configuration

Our attitude to date has been "well, we're not really in charge of that,
that's done unofficially by volunteers". I think we've reached a point
where this needs to start changing. 

In an ideal world, a release would work like this:

- I tag the release
- I push it
- Automated builders kick off on a bunch of VMs or hosts
- Builders run stock makefile targets or scripts in tarball
- Packages get signed
- Packages get uploaded to one or more locations, including
mercurial.selenic.com
- Download links get updated

Importantly, this same process would also be used to produce automated
nightly builds for testing and bug reporting and discovering packaging
problems before release dates.

The job of packagers would thus shift from "(manually?) building and
uploading binaries" to "making sure the committed build rules are
correct and up-to-date".

I think this also needs to be inclusive of builds for packaging systems
(Debian, Ubuntu, RHEL, Centos, Solaris, Pypi, etc.). These actually
suffer from more or less the same problems even though the distribution
model is different. So we should be building nightlies and release
builds for these systems and be more directly responsible for quality
and timeliness here as well.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list