Hello. Hopefully I'm not beating a completely dead horse here, but since some of the proponents of this "bump revision with each iteration" scheme are very vocal, I thought I could be very vocal too. I will (hopefully) not beat this horse again in the near future.
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. 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? It is my belief that stealing them from the opportunity of preparing changelog entries in equal conditions is not right. Now let examine the other arguments, in increasing order of importance: * sponsor convenience: undoubtedly, it's easier to manage files with different names than different files named the same. I've never had any problems, though (I just do `rm -rf old; mkdir old; mv * old` prior to downloading the next iteration), and neither do many other sponsors. And I can't see how that is more inconvenient than having to always pass -v when sponsoring packages. And you can get different file names without adding a newly created changelog version each time. I've said it in the past, and I'll repeat it again: if you really care about different file names, ask your sponsorees to work like this; first iteration: package (1.2-3~mentors1) unstable; urgency=low * Foo. * Bar. * Baz. package (1.2-2) unstable; urgency=low * This is the previous uploaded version. Second iteration: package (1.2-3~mentors2) unstable; urgency=low * Foo. * Bar. * Baz, taking into account the corner case Moo. (Thanks, Boris Sponsor.) * Quux. package (1.2-2) unstable; urgency=low * This is the previous uploaded version. --- And so on. And the sponsor always s/~mentorsX// in the changelog prior to uploading. * 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.) * 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. So, I get that we have developers that really fancy this scheme. Okay, we have more worrysome differences within Debian. 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. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org I promise you. Once I enter into an exclusive relationship, I sleep with very few people. -- Denny Crane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org