<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 6, 2013 at 2:47 PM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com" target="_blank">mpm@selenic.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, 2013-08-06 at 14:15 -0500, Steve Borho wrote:<br>

><br>
><br>
><br>
> On Tue, Aug 6, 2013 at 2:01 PM, Augie Fackler <<a href="mailto:raf@durin42.com">raf@durin42.com</a>> wrote:<br>
>         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<br>
>         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<br>
>         charge of that,<br>
>         > that's done unofficially by volunteers". I think we've<br>
>         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<br>
>         automated<br>
>         > nightly builds for testing and bug reporting and discovering<br>
>         packaging<br>
>         > problems before release dates.<br>
>         ><br>
>         > The job of packagers would thus shift from "(manually?)<br>
>         building and<br>
>         > uploading binaries" to "making sure the committed build<br>
>         rules are<br>
>         > correct and up-to-date".<br>
>         ><br>
>         > I think this also needs to be inclusive of builds for<br>
>         packaging systems<br>
>         > (Debian, Ubuntu, RHEL, Centos, Solaris, Pypi, etc.). These<br>
>         actually<br>
>         > suffer from more or less the same problems even though the<br>
>         distribution<br>
>         > model is different. So we should be building nightlies and<br>
>         release<br>
>         > builds for these systems and be more directly responsible<br>
>         for quality<br>
>         > and timeliness here as well.<br>
><br>
><br>
>         This honestly sounds like a great improvement, given how stale<br>
>         the<br>
>         packages for Ubuntu tend to be, and how some packagers took it<br>
>         upon<br>
>         themselves in the past to enable all the extensions.<br>
><br>
><br>
><br>
><br>
> On the Windows side, everything is automated except for two steps:<br>
><br>
> 1 - signing packages requires a passphrase to be entered<br>
> 2 - uploading is currently manually done through BB's clunky web<br>
> interface<br>
><br>
><br>
> If we had an SCP or FTP URL to upload to, and a sane policy for<br>
> deleting old nightlies after a short while, it could be automated.<br>
<br>
</div></div>Well, you already have SCP access, no?<br></blockquote><div><br></div><div>Yep, it's just a question of whether you want nightlies in the same location as releases, or in a different folder that was size-managed.</div>
<div> </div><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">
In addition to having a fully automated process that builds releases and<br>
nightlies, I think its also important to get to the build script into<br>
the tree so that people who need to build their own copies for various<br>
reasons (need bugfix, need custom deployment, St. Louis trampled by<br>
kaiju) can do so.</blockquote><div><br></div><div>So.. building windows frozen packages is fairly convoluted (especially for thg but the simple hg MSI is no cakewalk) and has a boatload of prereqs to be installed.</div><div>
<br></div><div>There is a subrepo like main repository:</div><div><br></div><div><a href="https://bitbucket.org/tortoisehg/thg-build">https://bitbucket.org/tortoisehg/thg-build</a><br></div><div><br></div><div>It clones all of the prereq repositories.  The key three being hg, thg, and winbuild (the rest are extensions bundled with thg)</div>
<div><br></div><div><a href="https://bitbucket.org/tortoisehg/thg-winbuild/wiki/Home">https://bitbucket.org/tortoisehg/thg-winbuild/overview</a><br></div><div><br></div><div>See the README for that repo for all the hack-tacular parts that go into building the installer.</div>
<div> <br></div><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="im">
> #1 could be dealt with if the person signing the package didn't mind<br>
> storing their passphrase on disk somewhere.<br>
<br>
</div>I think we can worry about that at a later stage, shouldn't treat as<br>
blocking.</blockquote><div><br></div><div>There's 3-4 people who build these things themselves, but it's a non-trivial setup to say the least.</div></div><div><br></div>-- <br>Steve Borho
</div></div>