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

[Jonas Smedegaard]

Hi Sebastian (and others),

On Tue, Mar 16, 2010 at 12:52:54AM +0100, Sebastian Reichel wrote:
>Well to get more than two opinions I will inject mine - I think we 
>should work with newer git snapshots instead of working with patched 
>releases, too. Some of the packages do not even have a release yet.

Projects without a release at all are not really discussed here.

Here is in summary what I would like:

  * Package not-yet-released projects as handmade snapshot tarball
  * Package released-but-buggy projects as upstream tarball + 1 patch

I pointed to a more extreme example where I cherry-pick each individual 
commit that seems relevant to me.  That I do not want per default, 
but...


>Normally I prefer the way you mentioned Jonas, but in FSO's case I
>don't see the advantages. We will pull all changes anyway, since
>the changes in the libraries are instantly used in the daemons. The
>changes in the daemon are normally bug fixes or important features.
>Nobody wants to wait long for them.

...when development changes includes *other* stuff than "bug fixes or 
important features" it might make sense to change strategy, so we should 
carefuly look at what exactly we _add_ instead of treating it all as "it 
was added by upstream, not us".

Above you write that _normally_ we want it all - sure, but sometimes we 
don't.  I want us to not streamline the "normally" so much that we 
overlook the "sometimes".


>I don't see any reason to handle the changes from the last release to 
>the currently used snapshot in debian.

The last couple of years I developed some additions to CDBS which I did 
not include in main cdbs (because I wrongfully thought they were 
unwanted there, but that's another story).  When I started packaging 
Sugar the same way - stuffing in a bunch of local CDBS snippets - and 
later had a discussion with Ubuntu about them deriving from my packaging 
work instead of reinventing the wheel and package from scratch, the 
first response was that my diff was suspiciously big and probably 
wouldn't be accepted by the Ubuntu MOTUs.

Chain of command aside, my point here is that a very simple hint about 
packaging being "risky" is the size of its diff compared to upstream 
code.

My point here is that sure, what we put in the diff *is* upstream code, 
but it is code not intended by upstream for general consumption, and I 
believe we should make that clear by storing it at "our side of the 
fence".

I see no other arguments for using snapshots when tarballs exist, than 
pure convenience.  And I dare say that we can make patch generation 
quite conveniently - I even volunteer to do so if interested.

All I want here is that we (when possible) indicate the standard way 
(patching) when we bypass upstream choice of what is release ready.


>So questions:
>
>* I know it's very easy to do this with DebSrc 3.0, but what are the
>  advantages? Is there anything wrong about using newer git
>  checkouts? I don't see why this improves bug reporting.

It is easy even with dpkg format 1.0 too - using patchsys-quilt.mk.

It does not improve *reporting* bugs.

It improves ease of spotting what could affect a bug.  Like the simple 
"whoah, you carry a shitload of unofficial baggage around here" or the 
more clever "heeey, look at the patch tracker how it broke right after 
your shitload of unofficial baggage grew to include this tiny 
locally-shipped library".

Both of above quotes did not require knowledge on upstream VCS activity, 
so could be spotted by e.g. an enthousiastic user, by a member of the 
Debian security team, or even by a competing distribution or an outside 
university project examining reliability of code or somesuch.


>* What should we do with those stuff, which does not even have a
>  release yet? An empty package with everything as debian patch? O.o

A handmade shapshot tarball.  But no need to automate that IMO, as it 
should really only be a temporary hack - we should try convince upstream 
to do they initial tarball release!


>So far I'm on Heiko's side, even though this means doing dirty stuff
>with git (IMHO the subdir -> root is not very nice).


Good luck finding a Debian Developer / Maintainer / sponsor then.


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/20100316/a2f0dfe8/attachment.pgp>