Bug#727085: Now we don't depend on the weird libevent patch
On Tue, Dec 31, 2013 at 3:45 AM, Faidon Liambotis <paravoid@debian.org> wrote:
> On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote:
> Two weeks is probably too often for Debian but time-based releases in
> general (rather than "important bugfix") are fairly common. I think the
> original idea of accumulating multiple sprints into one "community"
> release is a great path forward. The proposal for 8-week releases sounds
> just fine to me.
I meant there's no force on FB to do "community" releases. Two weeks
releases is a bit fast, right. On the other hand as I see the releases
get QA care. Upload bigger changes (8 weeks time) may be worse as they
may contain more backward incompatible changes. Also the maintainer
can decide how s/he uploads those releases. Maybe those will go to
experimental and say, every month after one more week test time the
package would be uploaded to Sid. Then users can get the fast moving
package in experimental with the more tested, monthly updates in Sid.
Maybe just follow upstream changelog and upload new releases when s/he
thinks so (new feature, bugfix needed for Debian - but maybe just
backport that fix), etc.
> Some upstreams tend to release some
> "LTS" releases for such uses, potentially labeling one of their
> incremental releases as LTS. This isn't a prerequisite, but it's good to
> actually have some longer stable/security management in mind when
> planning your release schedule.
+1 on LTS releases; like Ubuntu does with its distribution.
> Well, noone really forced you to ITP this :) You definitely seem to have
> your hands full, there's no need for you to take on more than you're
> able to handle. If you're too busy, I can just takeover this ITP, just
> say so.
I realize my lines sound worse than I wanted to. Yes, it's a bit hard
now, but my second work is project based and I expect to finish it in
a month or two. Some of my packages are team or co-maintained. I work
48 hours + a normal day because we had too many free days left for
December. It's me who let others go on holiday and take off their free
days. We are a group of eight persons, but due to the reason
mentioned, today only two of us are working. Tomorrow only me, but
from the 2nd of January everyone will be back on track.
Even today I've time to make a tea and drink it passionate or answer
my mails. Last but not least I've a half-baken package already.
>> 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):
>
> Which section of the policy mandates that? I'd be very suprised if the
> existing PHP policy covers alternative interpeters.
To match _generic_ package names. It doesn't have any part about
interpeter. Also as Paul noted, the package should be named HHVM now.
The php-hhvm package name comes to my mind or just hhvm.
> The last two lines are incorrect considering the new FastCGI mode of
> operation, which AIUI will be the only one actually offered by the
> package, as the embedded standalone webserver requires patches to
> libevent.
Sure, I've mentioned it was the _previous_ package description.
>> 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.
>
> Ubuntu automatically syncs from Debian, there's no need for Ubuntu
> maintainers to do anything.
As I heard, it's semi-automatic. They have their transitions when
they don't sync everything and changes over Debian packaging that
needs manual adjustments. Also my package delaboratory is not in
Ubuntu for an unknown reason to me. It doesn't have any RC bug, not a
big or unsupportable one, built on all archs, etc.
Laszlo/GCS
Reply to: