<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 6, 2013 at 2:01 PM, Augie Fackler <span dir="ltr"><<a href="mailto:raf@durin42.com" target="_blank">raf@durin42.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, Aug 06, 2013 at 01:53:34PM -0500, Matt Mackall wrote:<br>

> [this discussion needs to be cross-posted]<br>
><br>
> We've got a few long-standing problems with our current packaging:<br>
><br>
> - lag official release<br>
> - not automated<br>
> - not reproduceable by third parties<br>
> - not signed<br>
> - lack nightly builds<br>
> - notable missing platforms (RHEL)<br>
> - not uniform in configuration<br>
><br>
> Our attitude to date has been "well, we're not really in charge of that,<br>
> that's done unofficially by volunteers". I think we've reached a point<br>
> where this needs to start changing.<br>
><br>
> In an ideal world, a release would work like this:<br>
><br>
> - I tag the release<br>
> - I push it<br>
> - Automated builders kick off on a bunch of VMs or hosts<br>
> - Builders run stock makefile targets or scripts in tarball<br>
> - Packages get signed<br>
> - Packages get uploaded to one or more locations, including<br>
> <a href="http://mercurial.selenic.com" target="_blank">mercurial.selenic.com</a><br>
> - Download links get updated<br>
><br>
> Importantly, this same process would also be used to produce automated<br>
> nightly builds for testing and bug reporting and discovering packaging<br>
> problems before release dates.<br>
><br>
> The job of packagers would thus shift from "(manually?) building and<br>
> uploading binaries" to "making sure the committed build rules are<br>
> correct and up-to-date".<br>
><br>
> I think this also needs to be inclusive of builds for packaging systems<br>
> (Debian, Ubuntu, RHEL, Centos, Solaris, Pypi, etc.). These actually<br>
> suffer from more or less the same problems even though the distribution<br>
> model is different. So we should be building nightlies and release<br>
> builds for these systems and be more directly responsible for quality<br>
> and timeliness here as well.<br>
<br>
</div></div>This honestly sounds like a great improvement, given how stale the<br>
packages for Ubuntu tend to be, and how some packagers took it upon<br>
themselves in the past to enable all the extensions.<br>
<div class="im"><br></div></blockquote><div><br></div><div>On the Windows side, everything is automated except for two steps:<div><br></div><div>1 - signing packages requires a passphrase to be entered</div><div>2 - uploading is currently manually done through BB's clunky web interface</div>
<div><br></div><div>If we had an SCP or FTP URL to upload to, and a sane policy for deleting old nightlies after a short while, it could be automated.</div></div><div><br></div><div>#1 could be dealt with if the person signing the package didn't mind storing their passphrase on disk somewhere.</div>
<div><br></div><div>--</div><div>Steve Borho</div></div></div></div>