Things we ought to do to improve our packaging

[Dan Villiom Podlaski Christiansen]

On 06/08/2013, at 21.01, Augie Fackler <raf at durin42.com> wrote:

> On Tue, Aug 06, 2013 at 01:53:34PM -0500, Matt Mackall wrote:
>> [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.
> 
> This honestly sounds like a great improvement, given how stale the
> packages for Ubuntu tend to be, and how some packagers took it upon
> themselves in the past to enable all the extensions.

They still enable the full mergetools.rc list, though. This would be fine if it only listed helpful GUI tools or reasonably user-friendly commands line tools. However, it also includes vimdiff, with its rather steep learning curve…

Perhaps it would make sense to remove or disable the most advanced/hard-to-use/user-unfriendly merge tools in the config? After all, people who know how to use vim or Emacs generally know how to read and edit config files…

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com