Neil Williams <codehelp@debian.org> (19/01/2009): > > 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 disagree. mentors.debian.net is somewhere you push your files to so that they get peer-reviewed (and possibly uploaded to the archive when possible). I don't recall using it before I became DD (and was asked to try an upload there to check whether it was working properly), and I've always pushed my package candidates to my alioth's public space. How is that different from publishing a package with a possible fix, asking e.g. porters to check whether it fixes an FTBFS? Then the porter gets back to you, yelling that the patch isn't applied because you forgot to add the target magic to debian/rules. Will you re-upload with an increased version number? Then, because you were really tired, it is reported that it was forgotten to add the patch to the series file. Reupload and increment again? And then the patch doesn't apply because a typo slipped in while tweaking the comment/header/whatever. Reupload and increment again? Now comes the time to upload it to ftp-master. You then have (free form, but you get the idea): | foo (bar-5): | | Fix baz patch. | | foo (bar-4): | | Add baz patch to the series file. | | foo (bar-3): | | Fix targets so that patches are (un)applied when relevant. | | foo (bar-2): | | Introduce baz patch to fix quux. Don't you think it's adding a *little* *bit* *too* *much* *noise* to the universe, increasing entropy and killing kittens for no added benefit? Ah, yes, the package was exposed to a set of 1-2 persons, and “uploaded” somewhere. > > * 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. I may be blind, but I don't see git mentioned anywhere. Also, why is storing debian-only relevant? AFAICT, a source package is a tarball plus a debian/ directory… Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature