Bug#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 29, 2013 at 11:42 PM, Paul Tarjan <pt@fb.com> wrote:
> I won't stir the pot with any more legal discussion. That isn't my field
> and I'm just parroting what our legal department tells me anyways. I've
> articulated our position before, so I'll just wait until the legal issue
> is actually blocking our adoption. Ok?
This is correct.
> Since my last email, I put a bunch of effort into my packaging script. Now
> they are signed correctly, there is a main skeleton and then overrides for
> each version, and it updates the version files for me. Feel free to make
> pull requests or use this as a basis:
> https://github.com/hhvm/packaging/tree/master/hhvm/deb
Checked wheezy/ which is just wrong. It's a binary debian directory
and not a source one, I think 'Essential' is only used if its value is
'yes'. Standards-Version is missing, no long package description, ...
> Internally at FB we release a new version of HHVM every 2 weeks. We cut
> the branch on Monday and then do lots of rigorous testing and ship it 10
> days later on Thursday morning. I'd like to exactly mirror the internal
> releases since they are well tested instead of just arbitrarily cutting
> trunk. Many people voiced opinions that every 2 weeks was too fast for
> major open source releases so we agreed on mirroring every 4 releases (8
> weeks). How does that sound? It is easy to make it faster or slower by 2
> week increments if anyone has opinions.
My opinion for releases follows. Do one if there's an important
bugfix, new feature added, etc. In short, if there's a reason.
On the other hand, there's no problem with releasing every two weeks,
it's just not common. It matches with Debian standards, meaning that
normally ten days needed for unstable -> testing migration.
> Lastly, Laszlo, we should talk about how I can help with packaging.
Do you have a packager position there, at FB? :) At least ATM I've
two places to work for. At Debian I've more than a hundred packages
and twenty to do. Especially that I have to work more or less constant
from 31st 06:00 am to 2nd 04:20 pm. Will be hard, thus I'll start
again with HHVM next year. Now my previous package section for HHVM,
which I've named hiphop-php (to match the PHP policy of Debian, but
will re-check that):
-- cut --
Package: hiphop-php
Architecture: any
Depends: ${misc:Depends}
Description: HipHop VM for PHP
HipHop VM (HHVM) is a new open-source virtual machine designed for executing
programs written in PHP. HHVM uses a just-in-time compilation approach to
achieve superior performance while maintaining the flexibility that PHP
developers are accustomed to. HipHop VM (and before it HPHPc) has realized
> 5x increase in throughput for Facebook compared with Zend PHP 5.2.
HipHop is most commonly run as a standalone server, replacing both Apache
and modphp.
-- cut --
> I
> currently make a new branch for major versions and tags for each point
> release on our github repo. Do you want me to email you when I do this or
> can you subscribe to github easily?
I've a GitHub account, can follow your release cycle. Debian can
automatically track upstream releases even.
> Or should I setup a mailing list and
> always email that when I push?
That's up to you, several projects have an announce mailing list. I
don't need it strictly.
> I'll probably still have to keep packaging
> it for other distros since you're only going to do debian, right? Or is
> there an easy way for you to also do it in other debian-based distros
> (ubuntu, mint). Can you also do yum based distros or do you know what I
> should do for inclusion there?
I think packaging for Debian is a good step. Then Ubuntu maintainers
will pick it up and as I know, Mint based on Ubuntu, they will have it
as well. I've experience with Red Hat and Fedora packaging as well.
You may know that the transition is Fedora -> Red Hat from time to
time. I made one or two packages for CentOS in the past, but we'll see
that later.
I'm off for sleeping.
Laszlo/GCS
Reply to: