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 patchI 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
signature.asc
Description: Digital signature
_______________________________________________ pkg-fso-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-fso-maint
