[pkg-fso-maint] I need a DD to upload libfsoresource :-)

[Jonas Smedegaard]

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:
>> 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.
>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.
>
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20100314/a2cd789f/attachment.pgp>