← Back to team overview

openstack team mailing list archive

Re: Issues with Packaging and a Proposal

 

On 08/25/2011 01:59 AM, Monty Taylor wrote:
> This is one of the things we should discuss. I was talking about adding
> the packaging branches to the main repo - so master would be the actual
> VC used by the project devs. It would look like:
>   master - main development target
>   pristine-tarball - pristine-tarball diff information
>   upstream-* - packaging 'upstream branch'
>   debian-* - debian packaging branches

By all means, *please* avoid "master" as a branch name. Call it
bleeding-edge/unstable/testing/devel if you want, but simply not
"master". :)

What would be the use of "pristine-tarball" ? Prepare .tar.gz for
generic distributions, like RPMs or let's say Gentoo?

>> Unless I didn't understand what you mean by "one-off" (please elaborate
>> so that we avoid confusions), if backports are to be uploaded to
>> backports.debian.org, then we'd better take care that they are
>> maintained correctly. So having a branch for it sounds like a
>> requirement to me. I wouldn't take the responsibility to upload to
>> backports.d.o if we don't take it seriously. I'm already feeling quite
>> bad that I've left the current packages in the air without fixes, with
>> the build process totally broken... :(
> 
> Sorry - I should indicate here. (forgive me if I sound snarky) - I don't
> really personally care about backports.d.o - it's the backported library
> packages that go into the openstack repo I care about.
> 
> BUT - I may have been unclear here - I think there should definitely be
> a repo and it should match the standards above, I just don't think it
> needs to have a branch that's related to upstream VC.
> 
> Monty

In that case, we could maintain the upstream-*-backports and
debian-*-backports branch in Alioth. I believe maintaining a Git for
what we release in *.debian.org is always good (eg: backports.d.o or
just normal main). That's what is cool with the distributed part of Git:
it is easy to do that, and merge from one repo to another.

Thomas


Follow ups

References