On Wednesday 21 January 2009 00:46:22 Martin Meredith wrote: > On Tue, Jan 20, 2009 at 11:09:17PM +0100, Adeodato Simó wrote: > > * Martin Meredith [Tue, 20 Jan 2009 22:05:11 +0000]: > > > > Hey Martin, > > > > > On Mon, Jan 19, 2009 at 02:29:10PM +0100, Adeodato Simó wrote: > > > > * 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.) > > > > > > That actually sounds like an interesting project. Something I might > > > start hacking on. > > > > Uhm, what needs hacking, exactly? The sponsoree just says "Repo for the > > package is at $URL", no? Or do you mean some kind of integration with > > mentors.debian.net? > > Tools to make things easier to grab stuff from $repo :) etc etc... and a > good workflow documentation... maybe some other stuff :D Well, the tools are already there I believe, it is the possible difference in the workflows which might cause some dissensions. Yes, there might be spurious revisions during sponsorship, but there is also a sponsoree overhead which should be taken into account. For instance, I almost always hesitate to ask sponsoree to upload large tarballs to mentors (my inet connectivity might be untra cheap, but I coundn't be certain of theirs easily). Thus if sponsoree uses a VCS (as suggested by Dato and also several times in the past), it would be nice to try to do it his/her way if that could save them some hassle, and let them spend their resourses on actually improving the package. A possible example, though the package is real and you can test these yourself: Grab the package from sid and put it in sid/ for firther comparisons $ apt-get source gxemul Grab sponsoree's work $ debcheckout gxemul gxemul-0.4.7 cp orig.tar.gz from sid/ * yes, I know of pristine-tar, but there is no way for it to preserve the timestamps inside the tarball, i.e. hashsums will not much with these on the upstream site, unless I'm awfully mistaken) * if that is a new upstream version, unless the sponsoree has provided get-orig-source target, you grab that from upstream site. cd gxemul-0.4.7 git-branch master git-checkout master (later git-buildpackage will insist on working on master) * review the repo changelog and files; fix stuff if any, mail diffs to the sponsoree, git-pull, discuss, etc, until done. This could go via -mentors mailing list in order to acquire some more peer review. * of course the, spurious revisions are gone now (possibly forgotten -v also;-), and sponsoree uploads their possibly *small* changes only once; no tarballs uploaded by them at all, it is the sponsor's work to get the tarball anyway. git-buildpackage [options] (yes, there is also a --git-pristine-tar option;-) Compare with debdiff or whatever the result with the package from sid/ directory. Install, test, whatever ... Upload, and let the sponsoree knows about that (though they would receive a mail from the Debian queue daemon anyway) so they could tag their work. P.S. Yes, this workflow surely could be better; I don't insist on it being streamlined to perfection. And, yes, I also know of gitpkg and topgit ;-) -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
Attachment:
signature.asc
Description: This is a digitally signed message part.