multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On 02/03/2011 08:21 PM, OXullo Intersecans wrote:
> On 02/feb/2011, at 20.59, Chase Douglas wrote:
> 
>> * Overall, I'd suggest moving to bzr and hosting on launchpad. It's
>> certainly your choice where you host things, but I think you would find
>> launchpad helpful for handling source code and bugs. Launchpad can even
>> do the import from your svn repo for you :).
> 
> Is there a practical way to leave the upstream codebase on libavg.de svn server (so we can keep the current workflow) and use launchpad just for packaging purposes?

Sure. In fact, there are many ways to go about this:

1. Continue what you are doing with the source code, and push package
branches to launchpad
2. As Mark mentioned, you can import your code into launchpad+bzr now
and play around. This doesn't affect your svn repo at all. LP will just
pull updates to synchronize with your svn repo every day or so. If you
find that you like bzr, you can switch to it. Instructions available at
https://help.launchpad.net/Code/Imports.

Separate from the source code management, if you like LP bug handling
you can use it just for bugs. You can use it just for answers too. It's
all very pluggable. I'd be happy to help you out with all this if you need.

And just to be clear, there is no requirement that you integrated with
LP in any way, even for packaging. We think it's a great tool, but it's
your decision how to manage your project.

P.S.: I moved from assembla.com to LP for one of my pet projects
(mymote). I requested a bzr import from the assembla svn repo, and
everything has gone smoothly since!

>> * I see you added a man page to your packaging, probably at the prodding
>> of lintian :). I suggest moving the man page into your source tree
>> itself and then installing the man page from there instead. That way
>> other distros have access to the man page too.
> 
> Indeed it was only a choice dictated by lintian warnings. I suppose that, at least for the games, it would be more practical to get rid of the manpages.

Although I see your point, I don't see anything wrong with having a man
page either. If you ever want to add cmd line options (say for
debugging), a man page can be very useful.

>> * As you make revisions to the package, I suggest following what I've
>> done here:
> [..]
>> --- Loop over 4 and 5 as many times as necessary
>>  4. Make another change
>>  5. Run 'dch' to add a new changelog entry
>> ---
> 
> clear. I will follow this procedure for the other games as well, keeping in mind the changes you made.
> May I apply this procedure to python-libavg (the library all the games depend on) as well?

Sure! Let me know if you need any help.

>> When you are ready to push to a ppa, append ~ppa# (1,2,3,4, etc.) to the
>> package version (but don't commit this to the source code repository).
> 
> You mean to my branch of your bzr repo or to the upstream one?
> Sorry if it's a dumb question, my confusion comes from the ppa-versioned changelog entry that I found on your bzr repo.

Sorry for the confusion. You shouldn't have any debian packaging stuff
in your upstream source code repo. So I'm referring only to your
packaging branch here. When you upload to a ppa, you should append ~ppa#
to the debian version, but this change shouldn't be committed anywhere.
For example, if you check out our utouch-team ppa's you'll see all the
packages are appended with ~utouch#. However, if you look at the code
for all our packaging branches (like
lp:~utouch-team/utouch-grail/packaging), you'll find that we never
commit this version appendage to the branch.

This is because the ~ppa# scheme is only useful for ppas as you test
packages out before pushing to Ubuntu proper. The packaging branch
should represent what is pushed to Ubuntu only (and/or Debian).

>> When you are ready to push to the Ubuntu archive, create a release:
>>  1. Run 'dch -r'
>>  2. Run 'debcommit -r' (this will commit and tag the repository)
> 
> And then open bugs for new packages, upload to REVU?

This isn't my area of expertise, so I'll refer you to
https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. You'll want to go
through the MOTU route, since Debian won't have the multitouch bits you
need.

Thanks!

-- Chase