[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packaging xserver-xorg-video-openchrome



Hi Julien,

sorry for the delay.

On Mon, Aug 23, 2010 at 01:26:27 +0200, Julien Viard de Galbert wrote:

> Subject: packaging xserver-xorg-video-openchrome
> 
> Hi,
> 
> As you might know I'm adopting xserver-xorg-video-openchrome.
> I have a few questions:
> 
>  * about the debian/copyright file : 
>    Provided that I don't change much of the package, should I add myself
>    as copyright holder of the packaging ?

You can if you want to.

>    Also as others already have added changes to the git repos, should I
>    name each of the contributors or should I copyright it to the 'X
>    Strike Force' ?
> 
I don't think either of that is necessary.

>  * about debian/source/format : It's currently not present (so 1.0)
>    Is there any good reason not to switch to dpkg-source 3.0 (quilt)
>    format ? I'm wondering because as all X packages it uses xsfbs so it
>    already uses quilt. I tried and it worked! But there are currently no
>    patches in the series so I would not see any issue if there are some
>    between xsfbs and format 3.0. Moreover, I found only
>    xserver-xorg-input-evtouch to use format 3.0 (quilt), so if no other
>    packages uses it there might me a good reason that I'm not aware of.
> 
>    If it must stay on format 1.0, I still need the dependency on quilt
>    because of xsfbs but as said above there are no patches in the
>    series, so lintian complains about it, is this a problem ? (I believe
>    removing and adding the dependency to quilt when the series changes
>    is error prone, so I better leave it there.)
> 
I personally find 3.0 (quilt) to be a pain to use and it doesn't work
well with the way we often use git cherry-pick to apply changes from
upstream directly to the source instead of through quilt patches.  If
you find it makes your life better for openchrome, though, feel free to
use it.  If you stay on 1.0 then debian/source/format is not necessary.

Re: quilt I consider the warnings when the series file is empty as a
lintian bug, so I ignore those warnings.

>  * about the uploaders field, should I keep the previous maintainer in
>    the list (maybe I should ask him directly), according the wiki [1] I
>    think I should remove him (unless he finally sponsors me of course).
> 
You can probably remove Raphael from Uploaders.

> 1: on http://wiki.debian.org/XStrikeForce/Contrib
> |  This field must be limited to those who are actively maintaining the
> |  package, and must be pruned regularly to avoid having too many
> |  people. This is something we are currently failing at.
> 
>  * on git usage: As I suspect (after lurking on mentors@l.d.o) that my
>    package will not make it on the first attempt. Can I prepare the
>    package locally and only push to git.d.o once it's accepted (to avoid
>    leaving many trials in the history).
> 
The git history currently is a mess.  The existing package in the
archive is not on there, which is not a good situation.  If you manage
to improve that that would be quite welcome.  Otherwise just start from
what's there and hopefully after some time we can ignore the broken
state we're in now.  In the mean time, if you're not completely
confident you can push your changes to a different branch in the repo or
to a personal repo on alioth.debian.org:~/public_git/ and ask here or on
irc for comments.  When you think you're ready, push to the main branch,
ask for review, and if it's ok you can just s/UNRELEASED/unstable/ in
the changelog before the upload.

>  * on upload, should I use mentors.d.o or can I put the prepared package
>    somewhere else (on my website or any other place you suggest). I
>    guess mentors.d.o use the same kind of interface than the archive so
>    It might be a good exercise to start using dupload or dput.
> 
No need to upload a source package IMO, you can commit the tarball to
the git repo with pristine-tar and the sponsor can get the package from
there.

Cheers,
Julien

Attachment: signature.asc
Description: Digital signature


Reply to: