[Pkg-haproxy-maintainers] Backports

[Vincent Bernat]

 ❦  4 mai 2015 20:40 +0300, Apollon Oikonomopoulos <apoikos at debian.org> :

>> 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.

For the backports, I was speaking only for Squeeze/Wheezy (which have
now 1.5.8). For Jessie, I think the 5-day delay is OK too. I suppose
that you wanted to say "jessie-backports". We could also upload to
"wheezy-backports-sloppy" but in this case, we would have both
"wheezy-backports" and "wheezy-backports-sloppy".

>>  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.

That's also a solution. However, it means changing the HEAD of some
branch (instead of just deleting them). This will be quite confusing for
other people.

>> 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

We can do that too. Since, this would mean all new branches, that's
OK. However, for PPA, I have introduced them for Debian too. The current
matrix is the following:

      squeeze: { '1.4': 'hdn+',           '1.5': 'backports-sloppy-|hdn+' },
      wheezy:  { '1.4': 'hdn+',           '1.5': 'backports-|hdn+' },
      jessie:  { '1.4': 'hdn+',           '1.5': 'official-' },
      precise: { '1.4': 'official-|ppa+', '1.5': 'ppa+' },
      trusty:  { '1.4': 'official-|ppa+', '1.5': 'backports-|ppa+' }

hdn is PPA hosted on haproxy.debian.net (didn't know how to call
them). So I would add hdn/wheezy-backports and hdn/squeeze-backports
too.

>> 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).

We'll get something similar when 1.6 will be out for PPA branches. For
other branches, they should be OK as the history will be linear. So, I
propose to just not doing branches for PPA stuff. Or to put version
number in branches for PPA stuff as they will be always stick to one
major version.

> 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.

We can switch to upstream git, but "single-debian-patch"? For a user
getting the source package, I think this is more helpful to have several
commented patches instead of a big one.

As for the tool, I have never used git-dpm (or gbp-pq). Too lazy to
learn... :) But, yes, we can. No strong opinion here. I would prefer the
one from gbp for a nice integration but maybe it doesn't really matter.
-- 
Avoid multiple exits from loops.
            - The Elements of Programming Style (Kernighan & Plauger)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-haproxy-maintainers/attachments/20150504/4c5748c3/attachment.sig>