Happy new year Thomas! Skipping release team for this mail as I want to check one thing with you. You write that we will not maintain the -6 version in sid. Do that mean that all the work I did for this package (to move out the plugin files to respective package will be in vain?
Or is folsom release based on -6 version? Just checking. Based on your answer I will simply upload a -7 version that will be more or less identical to the version I was thinking of uploading to testing-proposed-updates. // Ola On Mon, Dec 31, 2012 at 03:32:34AM +0800, Thomas Goirand wrote: > 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 > -- --- Inguza Technology AB --- MSc in Information Technology ---- / o...@inguza.com Annebergsslingan 37 \ | o...@debian.org 654 65 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- -- 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/20130108195114.ga15...@inguza.net
