On Mon, 19 Jan 2009 14:29:10 +0100 Adeodato Simó <d...@net.com.org.es> wrote:
> The (in my opinion) most important reason why we shouldn't ask for > bumping the debian version on each iteration to our sponsorees is a > peculiar one: it's classist, because (in my view of thins) sponsorees > should get to work as closely to as developers work as possible. How some developers work would appear to be very different to how others work, so the only way that can happen is if the maintainer's workflow is as close as the sponsor's workflow as possible. > Do you, as a developer, bump the debian revision each time you build a > package, are ready to upload it, and discover one final problem with it? > Do you, under that scenario, write in the changelog a new bullet point > "Oh, I botched the rules file writing `rm -rf $(CURDIR) /usr/lib`, fixed > now", or rather just fix it silently? Why should sponsored pepole not > get to do the same? My problem with that is that it wasn't the maintainer who spotted that error. If the maintainer finds the botched line, the maintainer fixes it locally - just as a DD can fix their own packages locally. I've made plenty of mistakes in my packages - it's all in the changelogs - but if I've made an upload then the package should have been good enough for an upload and if it contains a bug, I'll fix it with another upload. As far as a maintainer is concerned, mentors.debian.net is the final upload destination - it is only a sponsor who can take it from there to Debian. If the package turns out not to be good enough after upload to mentors, a maintainer I'm sponsoring fixes it in precisely the same way as I'd fix a botched upload to Debian - with a new version. The need for a new version is instructional - it helps maintainers improve their pre-upload check procedures by treating mentors.debian.net as if it was ftp-master.debian.org. I also use interim revisions because it means that maintainers don't have to change practice after becoming a DD - their workflow when being sponsored is the same as the workflow as a DD. > package (1.2-3~mentors1) unstable; urgency=low I've always said that I find that kind of thing incredibly ugly and I really don't think it is necessary for sponsors to go editing debian/changelog. That's the way I prefer to work. I prefer not to change anything in the package other than the actual products of building the package itself. All changes should be made by the maintainer - even trivial ones. After all, I can't fix a typo without making a new upload, why should a maintainer expect me to fix the typo in their uploaded package? (ftp-master won't do that for me and nor should I expect it.) > And so on. And the sponsor always s/~mentorsX// in the changelog > prior to uploading. I wouldn't do that for my own packages (I don't use UNRELEASED or similar). Maybe it's down to all the other repositories that I maintain - I'm always uploading interim releases to who knows where (local, in chroots, on private machines, across private networks, across public networks . . . ) and UNRELEASED or other mechanisms just get in the way of testing with the archive software at the other end. > * history: I haven't seen this argument fly be in (this and other > instances of) this discussion, but the answer is that the proper > place to record that you had an extra and fatal space in your rules > file is your VCS. (And FWIW, I think much of this discussion would > go away if sponsorship was VCS-based rather than dsc+diff.gz based.) Oh no, not the git bike-shed thread again. ;-) I only use VCS for debian/ when I also use VCS for the rest of the package - and in that case, it is always the same VCS and I really don't like the idea of putting all debian/ into VCS - especially not git. That's just me. > * uniformity of packages in the archive: this scheme not only > introduces classes of people as mentioned above, it also introduces > classes of packages. Suddenly, you systematically have in the > archive entries for uploads that were never done to Debian... marked > as having been uploaded to unstable! If you're going to do this, > please ensure they're properly signaled as UNRELEASED (or "mentors", > or whatever) as Piotr Ożarowski suggested. Umm, I described how I do this for emdebian-tools already - there are dozens of entries in the changelog that were not uploaded to Debian for reasons like testing migrations etc. I have a simple scheme - x.x.0 for Debian and x.x.x for interim releases, albeit with some exceptions. Those uploads were made to Emdebian and to a repository that is configured to be available to all users who have the package already installed from Debian. In a very real sense, those interim releases are in Debian, just not in the Debian archive - and they are certainly not "unreleased" because the code is installed and operating. The package auto-upgrades to the Emdebian version at runtime - until such time as the next Debian version can be uploaded. Versions 1.4.4 to 1.4.14 of emdebian-tools are/were available to Debian - just install 1.4.3 and you'll get 1.4.14 at the next apt-get update; apt-get upgrade - 1.4.15 when I release that later today/tomorrow. This way, the version in Emdebian is always as close as possible to current SVN for the package, no matter what is going on within Debian. It can't really be any other way - emdebian-tools is developing so quickly. Of the ~70 releases in the last 18months, only about 20 were actually made directly to Debian. The next release adds lots more binaries from the emdebian-tools source so will spend some time in NEW and just isn't worth doing during a release freeze. During the more rapid phases of development of apt-cross I did the same thing but that has calmed down recently. Once Lenny is released, apt-cross development could pick up again. > So, I get that we have developers that really fancy this scheme. Okay, > we have more worrysome differences within Debian. Very true. Let's leave it at that. > But it would be more > okay if these developers would reckon (in their daily doings) that many > (?) of us don't agree this should be, by any means, standard practice in > Debian, and that better alternatives exist. Alternatives, yes but I like my workflow so 'better' is always subjective. I'm sticking with interim revisions - everyone else can do what they want to do. I'm quite happy with it and there is no need for anyone else to adopt the method - unless they want me to sponsor their packages. I've never said that my requirements should be standard practice for anyone - they are just my requirements for sponsoring and I expect them to be followed by maintainers who want me to sponsor their packages. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpJfz7TWSOYr.pgp
Description: PGP signature
