Introducing spurious revisions during sponsorship considered harmful (by some of us)

[Adeodato Simó <dato@net.com.org.es>]

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