Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #7820 > unrolled thread

How to maintain multiple branches (sid/bpo/exp etc)?

Back to article view | Back to linux.debian.maint.python

Contents

  How to maintain multiple branches (sid/bpo/exp etc)? Sandro Tosi <morph@debian.org> - 2015-11-02 23:00 +0100
    Re: How to maintain multiple branches (sid/bpo/exp etc)? Barry Warsaw <barry@debian.org> - 2015-11-02 23:00 +0100
      Re: How to maintain multiple branches (sid/bpo/exp etc)? Sandro Tosi <morph@debian.org> - 2015-11-03 00:10 +0100
        Re: How to maintain multiple branches (sid/bpo/exp etc)? Barry Warsaw <barry@debian.org> - 2015-11-03 00:50 +0100
          Re: How to maintain multiple branches (sid/bpo/exp etc)? Sandro Tosi <morph@debian.org> - 2015-11-03 01:10 +0100
            Re: How to maintain multiple branches (sid/bpo/exp etc)? Barry Warsaw <barry@debian.org> - 2015-11-03 01:30 +0100
    Re: How to maintain multiple branches (sid/bpo/exp etc)? Raphael Hertzog <hertzog@debian.org> - 2015-11-03 09:50 +0100
      Re: How to maintain multiple branches (sid/bpo/exp etc)? Barry Warsaw <barry@debian.org> - 2015-11-03 16:30 +0100

#7820 — How to maintain multiple branches (sid/bpo/exp etc)?

hello,
with the new DPMT repo layout and tools, what is the right way to
maintain multiple active branches for our packages? things like:

1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2
2. unstable at v1, experimental at v2

all of them active, so in the 2. case there should be a way to keep
updating v1 and v2 releases (and so unstable and exp) as the come.

Thanks for your help,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[toc] | [next] | [standalone]

#7821

On Nov 02, 2015, at 09:51 PM, Sandro Tosi wrote:

>with the new DPMT repo layout and tools, what is the right way to
>maintain multiple active branches for our packages? things like:
>
>1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2
>2. unstable at v1, experimental at v2
>
>all of them active, so in the 2. case there should be a way to keep
>updating v1 and v2 releases (and so unstable and exp) as the come.

I'm kind of doing something like this for python-pip.  I'm (slowly) working on
updating the whole stack to the latest upstream, but I'm also maintaining
1.5.6.  I just created a release-1.5.6 branch and switch to that when I'm
doing stable maintenance, then switch back to master when I'm working on the
new upstream.

I have an upstream-release-1.5.6 and of course when I `git-dpm c-p` on the
release-1.5.6 branch, I end up in a patched-release-1.5.6 branch.  Really, I
don't do much special other than switch to the relevant branch; all other
workflows seem to continue to do the right thing.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7822

> I'm kind of doing something like this for python-pip.  I'm (slowly) working on
> updating the whole stack to the latest upstream, but I'm also maintaining
> 1.5.6.  I just created a release-1.5.6 branch and switch to that when I'm
> doing stable maintenance, then switch back to master when I'm working on the
> new upstream.
>
> I have an upstream-release-1.5.6 and of course when I `git-dpm c-p` on the
> release-1.5.6 branch, I end up in a patched-release-1.5.6 branch.  Really, I
> don't do much special other than switch to the relevant branch; all other
> workflows seem to continue to do the right thing.

I dont think I follow your description: looking at the debian repo,
stable has 1.5.6-5 while testing and unstable has 1.5.6-7; looking at
the git repo (as of
http://anonscm.debian.org/cgit/python-modules/packages/python-pip.git)
all the branches are from 5 months ago except for master which is 3
weeks old. so how do you make it work?

is that release-1.5.6 for update to debian stable? just by looking at
the repo, can someone tell that release-1.5.6 is for jessie and not
for wheezy and not even for experimental (if we consider master to
always target unstable) or even for unstable itself, as it contains
1.5.6-7? that seems a bit confusing (hopefully I  didnt understand)

say I have v1.0 packaged in master for unstable, and want to package
v2.0 for experimental: should I created a release-2.0 (and a relative
upstream-release-2.0 (what are the commands to obtain it, btw?)) and
then doing the exp packaging there? how do I manage when I want to
upload v2.0 to unstable? merge release-2.0 to master,
upstream-release-2.0 to upstream? what if then I want to backport a
previous revision of 1.0 to jessie?

they might seem rare situations, but I face them everyday doing
backports for work and wanting to upload them to debian as well.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[toc] | [prev] | [next] | [standalone]

#7824

On Nov 02, 2015, at 11:07 PM, Sandro Tosi wrote:

>I dont think I follow your description: looking at the debian repo, stable
>has 1.5.6-5 while testing and unstable has 1.5.6-7; looking at the git repo
>(as of http://anonscm.debian.org/cgit/python-modules/packages/python-pip.git)
>all the branches are from 5 months ago except for master which is 3 weeks
>old. so how do you make it work?

So I'll preface this by saying I suck.  I should really adopt the DEP-14
conventions so it's less confusing *and* document this in d/README.source.
release-1.5.6 is for uploads to unstable and the last push three months ago on
that branch was for 1.5.6-7.  master is for what will be the new upstream
whenever I get more time to work on it.  release-1.5.6 branch is at least
correct:

http://anonscm.debian.org/cgit/python-modules/packages/python-pip.git/tree/debian/changelog?h=release-1.5.6

So it's not completely analogous to your case; I just wanted to point out that
you can have whatever branches you want for other releases, and git-dpm should
continue to Just Work.

>say I have v1.0 packaged in master for unstable, and want to package
>v2.0 for experimental: should I created a release-2.0 (and a relative
>upstream-release-2.0 (what are the commands to obtain it, btw?)) and
>then doing the exp packaging there? how do I manage when I want to
>upload v2.0 to unstable? merge release-2.0 to master,
>upstream-release-2.0 to upstream? what if then I want to backport a
>previous revision of 1.0 to jessie?
>
>they might seem rare situations, but I face them everyday doing
>backports for work and wanting to upload them to debian as well.

Raphael can probably say more about this, and advocate for DEP-14, which in
your case probably makes more sense than I have:

http://dep.debian.net/deps/dep14/

It's probably worth some experimentation to see if DEP-14 is the right
approach for you, and how that might inform updates to DPMT policy at some
point.  Just remember to document it in README.source. ;)

trying-to-be-less-unhelpful-ly y'rs,
-Barry

[toc] | [prev] | [next] | [standalone]

#7825

> Raphael can probably say more about this, and advocate for DEP-14, which in
> your case probably makes more sense than I have:
>
> http://dep.debian.net/deps/dep14/
>
> It's probably worth some experimentation to see if DEP-14 is the right
> approach for you, and how that might inform updates to DPMT policy at some
> point.  Just remember to document it in README.source. ;)

yeah I think DEP-14 is the right approach here, but it has 2 drawbacks:

1. I have a simple package, which I keep maintaining with the usual
'master' and 'upstream' branches, but then the testing freeze will
come and I want to start uploading to experimental, at that point I
need to change the layout of the repo (annoying, but I am the
maintainer, I can do that I guess)

2. what if I am not the package maintainer tough? I cannot enforce a
new layout to that repo. take this real-life example sqlalchemy: I
asked Piotr for a jessie backport of 1.0.8, he agreed I can go ahead,
I have a package ready and I dont know how to commit it to the repo.
what should I do at this point?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[toc] | [prev] | [next] | [standalone]

#7826

On Nov 03, 2015, at 12:03 AM, Sandro Tosi wrote:

>1. I have a simple package, which I keep maintaining with the usual
>'master' and 'upstream' branches, but then the testing freeze will
>come and I want to start uploading to experimental, at that point I
>need to change the layout of the repo (annoying, but I am the
>maintainer, I can do that I guess)

If you don't think you'll need to upload to unstable during the freeze, then I
think it's probably okay to put experimental changes on master.  I did this
during the last freeze and it worked out okay.  I guess it's a bit of a gamble
though.

>2. what if I am not the package maintainer tough? I cannot enforce a
>new layout to that repo. take this real-life example sqlalchemy: I
>asked Piotr for a jessie backport of 1.0.8, he agreed I can go ahead,
>I have a package ready and I dont know how to commit it to the repo.
>what should I do at this point?

I guess the maintainer has to give you permission to rename the branches, or
at least to add a debian/jessie branch for the backport.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#7828

Hi Sandro,

On Mon, 02 Nov 2015, Sandro Tosi wrote:
> hello,
> with the new DPMT repo layout and tools, what is the right way to
> maintain multiple active branches for our packages? things like:
> 
> 1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2
> 2. unstable at v1, experimental at v2
> 
> all of them active, so in the 2. case there should be a way to keep
> updating v1 and v2 releases (and so unstable and exp) as the come.

Have a look at what we did for python-django and check out its
README.source to learn how to configure git-dpm to match the various
upstream branches and the corresponding Debian packaging branches.

I experienced yesterday how to merge a branch into another branch
(merging experimental with 1.8 into unstable that had 1.7)
and the least I can say is that it was not flawless... I already
reported the issue here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667

So I did a plain "git merge" and did the following to clean up:
- resolved all conflicts by picking the merged side (including
  debian/.git-dpm)
- ran git-dpm status and reverted changes that did not conflict during the
  merge but that were not part of the upstream changes (they are probably
  left-over from debian patches since those are now applied in the
  packaging branch)
- manually cleaned up debian/patches

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#7829

On Nov 03, 2015, at 09:49 AM, Raphael Hertzog wrote:

>I experienced yesterday how to merge a branch into another branch (merging
>experimental with 1.8 into unstable that had 1.7) and the least I can say is
>that it was not flawless... I already reported the issue here:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667

I could be misremembering, but I think bzr-buildpackage (UDD?) will unapply
the patches before it tries to merge in a new version.  It's very handy to
have the patch-applied branch to work on directly for daily packaging tasks,
but I do think when merging branches you have to do that on the *unpatched*
tree.

Cheers,
-Barry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web