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

Jonas Smedegaard dr at jones.dk
Mon Mar 15 21:57:14 UTC 2010


On Mon, Mar 15, 2010 at 09:41:42PM +0100, Heiko Stübner wrote:
>First, I did rename the branches of the libfsoresource git according to 
>the last mails as a test, so gbp-clone is happy now and you will need 
>to reclone it.

Great.

>I think current Freerunner-users that use Debian on it are somewhat 
>familiar and follow fso-developments. 

Debian "users" are many more than those directly using our software in 
their OpenMoko.  Ubuntu is a Debian "user", just to name one extreme.


>So it could be easier for them to see on in the current form what 
>commit a snapshot package was based on by simply looking at the history 
>which is also in our git and compare with upstreams git.

They find 0.1.0.0+git20100221-1 easier than 0.1.0.0-1+git20100221 you 
mean?

And that it is important to present it to them in that particular style?  
More important than the ability for better fitting into e.g. our patch 
tracker, which I imagine helps ease workload on our security team?


>> Yes, it is more work to prepare patches. On the other hand, later bug 
>> tracking can be helped when both yourself, downstream users and 
>> upstream developers can very clearly see not only the upstream 
>> internal reference number (i.e. the commit ID) of our snapshot but 
>> more details on changes between that and upstream latest release 
>> (which non-Debian users can be expected to base their user 
>> experiences on).
>For cornucopia bugtracking is at the moment mostly packaging a new 
>snapshot, as the code which contains the bugs is most of the time 
>already obsolete when the bug is discovered.

I was not talking about upstream tracking bugs of theirs, but of Debian 
tracking bugs of ours - and the ability to work most easily with *both* 
upstream, peer Debian developers and users (including derived distros).

Lazy upstream code handling is a bad excuse for our code handling being 
lazy too, IMO.


>we need the snapshots just to improve the user experience - or create 
>one at all.

I am in no way against including upstream code newer than their newest 
tarball release.  The discussion here is about how to redistribute, not 
if we should redistribute at all.  Please do not clutter the discussion.


>For example fso-frameworkd, fso-gpsd and fso-gsm0710muxd by other DDs 
>also use a similar packaging style (with master = upstream-git too) 
>where nobody complained about this since 2008 - so it seems not to be 
>completly wrong to me but more a matter of personal preference/opinion.

No doubt you can find packages in Debian maintained similar to your 
preferred style. I believe you do not violate any Debian Policy.

What I express is a packaging style that I feel comfortable with.  Which 
is quite relevant if I should take the responsibility of its inclusion 
in Debian.


Kind 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/20100315/8f402119/attachment-0001.pgp>


More information about the pkg-fso-maint mailing list