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

[Sebastian Reichel]

On Mon, Mar 15, 2010 at 10:57:14PM +0100, Jonas Smedegaard wrote:
> 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.

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.

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. I don't see any reason to
handle the changes from the last release to the currently used
snapshot in debian.

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

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

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20100316/c88a8d86/attachment.pgp>