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

[Jonas Smedegaard]

On Mon, Mar 15, 2010 at 02:05:15PM +0100, Heiko Stübner wrote:
>
>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.

Yes, I understand that.  This is the reason we are discussing how to 
best track newer-than-released code at all :-)


>Also I don't think upstream considers releases as stable, as the next 
>commit after a release is often a fix for something "critical" :-)

That Is your claim.  I do not claim that you are wrong, but I want it as 
easy as possible to track how much our distributed code have derived 
from the officially released code base.


>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.

Yes, I do understand this.  We have an important role as distributors, 
which is to *distribute* code written by others.  When weget more 
enthusiastic and participate in the coding (which is to some extend what 
is happening when we cherry-pick code not yet approved for release by 
our upstreams) then we should IMO be *very* transparent about it.


>> 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.

No problem: Update the patch shipped with our -2 release.


>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.

I deliberately left out that detail to not confuse things.  I am happy 
that you notice and bring it up yourself.  Easy to handle: Instead of 
0.1.0.0-1 we release 0.1.0.0-1+git20100221.

And instead of 0.1.0.0-2 we release 0.1.0.0-2+git20100317, addressing 
your other concern above.


A counterarugment might be that such version numbers are not only ugly 
to look at but even trigger lintian warnings.  True, they are ugly 
because it *is* ugly what we do, and it triggers lintian warnings 
because it *is* easy to do it wrong (i.e. we need to then ensure 
ourselves when to include upstream tarballs with our uploads as 
dpkg-source no longer recognize the first of a series).  But they are 
only *warnings*, not errors.  It is not an error to use unusual version 
numbers like that TTBOMK.


>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.

This is not about esthetics but about transparency.  We bypass upstream 
judgement on what is ready for release (no matter how wrong they are and 
how qualified your proofs against their judgements), and our diversion 
should automagically show up at e.g. http://patch-tracker.debian.org/ 
which is the case when providing (proper DEP3 hinted) patches rather 
than hiding the dispute as "it all came from the upstream swamp".


  - 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/20100315/b9b44910/attachment.pgp>