[Openstack-devel] Bug#685251: Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack

Thomas Goirand zigo at debian.org
Sun Dec 30 19:32:34 UTC 2012


On 12/29/2012 09:22 PM, Ola Lundqvist wrote:
>> * I don't think there's the need to use testing-proposed-updates.
>> Uploading to SID will be just fine, as anyway, we haven't uploaded
>> anything newer in SID which would pose a problem, and that we use
>> Experimental for Folsom. (in other words: nothing prevents uploading to
>> SID, and when we upload there it's in the hope it migrates to testing)
> 
> No that won't work because the changes in -6 should remain.

We will *not* maintain -6 in SID. It will go away and will be replaced
by the Folsom packaging as soon as Wheezy is released. So why would you
keep it in SID?

> And no I do not want to first upload a -7 version and than a new
> -8 with the changes in -6 because then I have to have a very complicated
> replaces rules in the control file which we really should avoid.

Ah, that makes sense!!! :)

But I don't think this cuts it. The changes will be necessary in Folsom
anyway, because we should provide an upgrade path in SID. So we're
doomed to the replaces+breaks it here. Note that we already have a
Replaces: in the alioth for the Folsom release Quantum which I plan to
upload soon. Should I add a Breaks: too? (I think so)

> Same answer as above. I have followed the instructions in
> http://www.debian.org/doc/manuals/developers-reference/pkgs.html chapter
> 5.13.3.
> 
> "Version numbers are usually selected by adding the codename of the testing
>  distribution and a running number, like 1.2squeeze1 for the first upload
>  through testing-proposed-updates of package version 1.2."
> 
> This is just as valid for testing uploads as for stable uploads.

Yeah, I wasn't debating this, I was questioning the relevance of using
t-p-u instead of SID.

>> * Our Git already contains entries for -6 and -7. Please use that,
>> modifying the candidate version -7, and do not get out of sync with our
>> Git please, otherwise it's going to be a nightmare!
> 
> The -7 version is what I have used to backport from. I have taken your
> changes and re-done them for testing only.

Then you should create a debian/wheezy branch in the Git! I was planning
on doing that just right after the release of wheezy for all of our
packages, but it will be needed now for Quantum if you want the package
to have a Wheezy and a SID branch now. As much as I can see, Alioth
doesn't have a debian/wheezy branch, does it?

>> Also, this issue has been pending for 6 months! I do appreciate that you
>> finally decide to work on it, even that late. But I continue to refuse
>> to take the responsibility for it. The main mistake, IMO, was to leave
>> the issue as-is, doing nothing to fix it. So you and Loic should really
>> take the responsibility for the upload, and make sure it's in a correct
>> shape *in time* for the release. I surely would feel bad if Quantum had
>> to be removed from Wheezy. Please don't leave this pending again.
> 
> I do not want to start a flamewar

It wasn't my intention. I just wanted to highlight that this needs to be
fixed soon. I do hope you don't take it personally.

> First of all it is 3.5 months (not 6)

My count started on the 2012-07-06, when Quantum -6 was uploaded by Loic
in SID. After such an upload, action should have been taken to have the
package unblock (or that upload should have been made in experimental).

> secondly I have asked about your
> opintion on this matter without response and that explains more than 2 months.

Well, the problem is that I might agree with the changes, *BUT*, I'm not
a member of the release team, and therefore, I don't have any decision
power. Also, I didn't really understand what was done at the time, and I
probably still don't get why everything all of the code isn't stored in
the python-* package. The only reason why I've been asking you, was to
provide information to the release team for an unblock. But now I see
that discussing it with me didn't help. :(

I'm sorry that it seems you've been waiting on me. (As a rule, if I
don't answer within 5 days, consider that either I don't know what to
answer, or that your mail is stuck on my huge mail queue and that I had
no time to answer. In which case, either send me another mail, or try to
deal without my answer.)

Again, I'm not trying to put the blame on you, just trying to push you
to solve the current problem. Thanks again for working on it.

Thomas



More information about the Openstack-devel mailing list