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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e096d2.3050...@debian.org
