On Sun, Mar 14, 2010 at 09:36:17PM +0100, Heiko Stübner wrote:
Am Sonntag 14 März 2010 20:49:47 schrieb Jonas Smedegaard:one possible download location would be http://downloads.freesmartphone.org/sources, which was linked to from the freesmartphone.org startpage. And it seems they built a new one that is missing this link. Also libfsoresource is a subdirectory of the cornucopia upstream git repository.Sorry, I do not understand.I tried reading the debian/copyright file to find the upstream source but that only points to http://www.freesmartphone.org - some fumbling around and guessing lead me to http://git.freesmartphone.org/ but there I see no libfsoresource which is a) a problem for me to understand right now and b) unacceptable for Debian.So I should elaborate a bit more in the copyright files.
Yes, please do that.If I understand correctly then you need not write a lot of explanation (I will probably strip most of it anyway when soon rewriting using draft DEP5 format), but just a) change http URL to actual tarball download page, and b) add git URL + comment in paranthesis mentioning the subdir used).
Please elaborate more on the correlation between Upstream Git and Debian packaging Git - both what has been done and also what was the intend of doing what was done. Perhaps if I understand both I can suggest a structure which is both convenient for your needs and elegant for other Debian developers to grasp (I have had some experience in keeping upstream and Debian Gits in sync at the Sugar project(s)).As the fso releases are far between we use git snapshot as base for the debian packages at the moment. The individual projects only exists as subdirectories [no git submodules] in the cornucopia repository.So the individual subdirectories are spearated to new branches. I.e. ./libfsoresource in the master branch becomes ./ in the libfsoresource branch This branch in between is simply a means to keep this separation and the following changes also separate.
I think I understand now. ...but do not like it:For upstream source not yet releasing anything as tarballs it makes sense to release a "homegrown" snapshot of their VCS code. But as soon as upstream release a tarball, I find it better that we base our releases on that, and if we want to then follow upstream development HEAD then we isolate and include a patch. That way it possible to see in a standardized way how "dirty" our source is compared to what upstream consider latest stable code.
I fail to see a problem in renaming the branches. Only if a single Git repository is used for both upstream work and Debian packaging would that be needed as I see it - and I strongly recommend against that. Unless I missed something special to this particular project, Git have no problem renaming brnaches across clones and still keep things in sync - like this:Upstream Git Debian Git ------------ ---------- master upstream-dist -> upstream pristine-tar master
ok I think I understand now. Implementing it something like this should
work:
Upstream Git Debian Git
------------ ----------
master -> upstream-git [name may vary]
-> libfsoresource
-> upstream
-> pristine-tar
-> master
right?
Ahem, not quite: The arrow indicates to me a branch that is transfered directly. So (if I understand you correctly) more like this:
Upstream Git Debian Git
------------ ----------
master -> upstream-git [name may vary]
libfsoresource
upstream
pristine-tar
master
...but read above how I dislike the way you want to repackage upstream
source.
If latest upstream tarball release is 0.1.0.0, then instead of releasing 0.1.0.0+git20100221-1 (with upstream released code and upstream development code merged together), I would want to release 0.1.0.0-1 and mention in our changelog that our -1 consists of a (possibly huge) patch to sync against upstream development as of this or that date.
[By the way, how does the renaming of git branches work? For another project I did a search for it but didn't find anything]
On your local harddisk: git branch -m <oldbrach> <newbranch> Then at Alioth: rm -rf <repo> mkdir <repo> cd <repo> git --bare init --shared echo "$DESCRIPTION" >description chmod a+x hooks/post-update Then on your local harddisk: git push --all; git push tags..and finally announce to the list that everyone need to throw away (or move aside) their old clone and clone again from scratch.
If following the upstream/pristine-tar/master branch naming scheme then you can in that email tell people to clone using the following command:
gbp-clone git.debian.org:/git/pkg-fso/<repo> :-) Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-fso-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint
