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

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.). 
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 
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 
makes the upstream software distribution-specific (in that case Maemo/Meego 
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 
iii) it forbids the distributors from using the upstream VCS as source for 

==== 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 

==== 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 
$ 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 

$ # (…) Do some changes, git add them
$ git commit -m"Smart commit message"

$ # Release the upstream part
$ git tag # (or make that upstream/, 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 and releasing";

$ # Releasing the packaging
$ git tag; # (or make that debian/ or meego/, …)

And done…

===== Conclusion =====

I would very much welcome a separation of the "upstream developement" (with 
proper releases) and the "meego packaging developement" (with 
releases) in separate branches: this would really ease our developement flow, 
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, 


[0] https://alioth.debian.org/projects/pkg-meego/
[1] stating it explicitely never hurts…
Didier Raboud, proud Debian Maintainer (DM).
CH-1020 Renens

Attachment: signature.asc
Description: This is a digitally signed message part.

MeeGo-packaging mailing list

--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part.

Pkg-meego-maintainers mailing list

Reply via email to