Hi dear Debian Meego Maintainers,
I just sent the attached mail to meego-{dev,packagi...@meego.com to (hopefully)
help them change their DVCS management.I intended to CC our list, but messed up. :-( Anyway, the followup probably belongs there. Cheers, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com
--- Begin Message ---Hi all, ==== Introduction ==== I'm Didier Raboud, aka OdyX and I'm part of the Debian pkg-meego group [0], which intends to package the software for which MeeGo is upstream for the Debian distrbution. This proposal is the result of my initial investigation to find the best packaging workflow for us and has risen a high interest when it was discussed over IRC #meego-deval last week. My goal with this proposal is to help the people creating the software at MeeGo adopt sane guidelines with regards to packaging files. ==== The problem ==== A pretty common packaging workflow is to enhance "upstream tarballs" by adding to them some distribution-specific files (*.spec files for rpm-based distributions; debian/ directories for deb-based distributions, etc.). Nowadays, with (D)VCSes, it becomes more and more common to use VCS tags as "upstream source", avoiding (almost) completely the tarball. Currently, some repositories used for the developement of MeeGo software contain packaging information (for example: libmeegotouch contains a debian/ repository and a *.spec file). This is a problem for multiple reasons: i) it bundles "upstream" developement with "packaging-specific" developement and makes the upstream software distribution-specific (in that case Maemo/Meego specific); ii) it forces other distributors (Debian is an example among those) to either patch or remove those files from the VCS snapshots and/or from the release tarballs; iii) it forbids the distributors from using the upstream VCS as source for their packages. ==== The proposal === The idea is to simply use a separate branch on the upstream repositories which would contain the packaging information. Then each distributor could either use that separate branch directly, fork from it, create his own, etc. freely, while still using the upstream VCS as source for the packages, hence keeping the developement flows close. (As a side point, which was mentioned during the IRC discussion; we have no intention to "wipe out" the complete actual debian/ directory: we will very certainly start from it. But the fact is that Debian and MeeGo have different policies [not judging them here] and we might need to have diverging packagings.) ==== Concretely ==== Here is a temptative demonstration on how it is possible to "migrate" to such a repository layout and how it gets used afterwards. == Initialisation - Migration == $ # Fetching my libmeegotouch cloned repository $ git clone g...@gitorious.org:~odyx/meegotouch/odyx-libmeegotouch.git libmeegotouch $ cd libmeegotouch; $ # Backup'ing debian/ (do that with all non-upstream files) $ cp -r debian/ debian-backup/ $ # Removing the debian/ directory (ditto) $ git rm -r debian/ ; git commit -m "Removing packaging-specific files" $ # Creating the "packaging branch" (which contains upstream+packaging) $ git checkout -b packaging $ # Re-add the packaging files (ditto again) $ mv debian-backup debian $ git add debian/; git commit -m "Adding back packaging-specific files" == Working == Now let's try to do an update to the core and do a package release along with it: $ # (…) Do some changes, git add them $ git commit -m"Smart commit message" $ # Release the upstream part $ git tag 1.2.3.4 # (or make that upstream/1.2.3.4, as is preferred) $ # Checkout the packaging repository to do the needed packaging changes $ git checkout packaging $ git merge master # Update the "upstream" part of the packaging repository. $ dch -i # (… Prepare debian changelog entry) $ # Commit the packaging-specific changes $ git commit debian/ -m "Packaging fixes for 1.2.3.4 and releasing 1.2.3.4-1"; $ # Releasing the packaging $ git tag 1.2.3.4-1; # (or make that debian/1.2.3.4-1 or meego/1.2.3.4-1, …) And done… ===== Conclusion ===== I would very much welcome a separation of the "upstream developement" (with proper 1.2.3.4 releases) and the "meego packaging developement" (with 1.2.3.4-1 releases) in separate branches: this would really ease our developement flow, as much as clarify yours. Of course I am open to discussion [1] and I am ready to work towards that goal by preparing the packaging repositories (together with merge requests), etc. Just ask. Thanks in advance for answers and a constructive discussion. Best regards from rainy Switzerland, OdyX [0] https://alioth.debian.org/projects/pkg-meego/ [1] stating it explicitely never hurts… -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com
signature.asc
Description: This is a digitally signed message part._______________________________________________ MeeGo-packaging mailing list meego-packag...@meego.com http://lists.meego.com/listinfo/meego-packaging
--- End Message ---
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pkg-meego-maintainers mailing list Pkg-meego-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-meego-maintainers
