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

[Heiko Stübner]

Am Sonntag 14 März 2010 schrieb 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:


> 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.
the fso guys release tarballs very infrequently. Often a new vala version is 
released shortly after which breaks the compilation of the fso code most of 
the time. Often a fix for something "critical" follows an official release. Also 
I don't think upstream considers releases as stable, as the next commit after 
a release is often a fix for something "critical" :-)


> 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.
but with this scheme it's possible to simply cut "upstream-git" and 
"libfsoresource" and place the new official code in upstream when the code 
martures enough sometime in the [not so near] future. 


> 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.
But most of the time we need more than one git snapshot between official 
releases. Take libfsobasics for example. The last official release was 
2009-12-17. Since then we had 3 snapshot releases to get new things working 
and we don't know when upstream will make another release and how long they 
will compile with the vala in Debian main. 

With the current approach new developers can see directly on which upstream 
commit a release is based without reading another document describing a giant 
patch.

So I think this handling of giant patches for code that won't settle down [and 
has usable official releases] in the near future is overly convoluted. Where is 
the gain apart from esthetic thoughts.


Heiko