[Pkg-haproxy-maintainers] Backports

[Apollon Oikonomopoulos]

Hi!

On 22:55 Sat 02 May     , Vincent Bernat wrote:
> Some news:
> 
>  - 1.5.12-1 has been uploaded to unstable.
>  - 1.5.8-3~bpo70+1 has been uploaded.
>  - I wanted to upload 1.5.8-3~bpo60+1 but I don't remember how to upload
>    to squeeze-backports-sloppy. I have asked on the mailing
>    list. Currently, we have 1.4.25-1~bpo60+1 which is not in any later
>    distribution.
>  - 1.5.12 has also been uploaded to Lucid/Precise PPA.

Great news, thanks!

> 
> I have updated the website haproxy.debian.net to accomodate the
> possibility to propose several solutions: one "stable" solution, one
> "latest" solution. For Debian, there is currently nothing but for
> Ubuntu, if you select Trusty and HAProxy 1.5, you get the possibility to
> get the "stable" version (from backports) or the "latest" version (from
> the PPA).
> 
> I would like to do the same thing for Debian, mainly for people wanting
> the latest version to not get bad publicity for Debian being late. So, I
> will setup the appropriate repositories to mimic Ubuntu PPA shortly.

Well, if we keep uploading the latest version to unstable, then 5 days 
later we can (normally) upload to wheezy-backports. I see a point in 
reducing the 5-day wait, but there are two caveats:

  - these 5 days are a minimum testing period for the package.  
    haproxy.debian.net OTOH will not have such a staging period and if 
    people point their production systems there, they will lose that 
    minimum testing period.
  - we must make sure wheezy-backports will still get the attention it 
    deserves and not fall behind.

> Now, the git repository is a bit a mess with many branches. There are
> branch with a version suffix and branch without. Ubuntu branches are all
> PPA. Absence of the suffix usually means HAProxy 1.4. I don't want to
> get things messier for all those unofficial builds. So, now, I will not
> use branches, except for non-backports stuff. For example, when I want to
> upload to Ubuntu Precise, I will do:
> 
>  git checkout debian/1.5.11-1ppa1_precise
>  git merge debian/1.5.12-1
>  dch ...
>  gbp buildpackage --git-tag

This will save you a branch at the cost of having to manually figure out 
each time what your previous backport/ppa release was and branch from 
there. I would be more inclined to just get rid of the old 1.4 branches 
to clear the confusion and leave the rest as-is.

> The tags will be stay because they are not confusing, but no branch. Dunno
> if I should delete the branches on alioth to make it easier to work with
> the "official" branch. This would leave:
> 
>  - master
>  - experimental
>  - upstream
>  - upstream-1.5
>  - upstream-1.6 (soon)
>  - pristine-tar
> 
> I could keep branches for official builds, but what would be the naming?
> jessie for jessie/jessie-proposed-updates/jessie-security and
> jessie-backports for backports?

As branches have directory semantics, I think the following scheme would 
probably work:

 - debian/jessie for anything that makes it to jessie
 - debian-backports/jessie, debian-backports/wheezy etc  (or 
   debian/jessie-backports, debian/wheezy-backports) for backports
 - ppa/precise, ppa/lucid etc for PPA material

> What is your stance on this?
> 
>  1. Keeping only the branches above.
>  2. Keeping the branches above + jessie + jessie-backports (can't do
>     that for wheezy).
>  3. Keep all the current branches.
>  4. Don't care.
> 
> I am for 1. I can live with 2.

I really don't mind having many branches, as long as they make sense. To 
this I agree that at least the 1.5 branches are currently causing 
confusion and should be made primary (let's stay just with the tags for 
the 1.4 releases).

One last thing, since we're discussing git: what would you think about 
switching to upstream git + single-debian-patch instead of tarballs and 
d/patches? I know it makes the .dsc more difficult to handle directly, 
but it makes maintenance and cherry-picking from upstream much easier.  
Also, I wonder if we should give git-dpm a try.

Cheers,
Apollon