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 _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
