[Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
dr at jones.dk
Sun Sep 20 01:24:23 UTC 2009
Hi David - and everyone else,
[please don't cross-post: respond only to OLPC list as requested]
On Sat, Sep 19, 2009 at 06:49:00PM -0500, David Farning wrote:
>I tried them out briefly in a VM this morning, worked great.
Wauw, you are quick! Good to hear that that at least initial tests work.
I do expect bugs to be discovered still, as so far I have only tested
the packages myself on my own laptop...
>I don't understand the debian work flow. I see that you are carrying
>.82, .84, and .85. Will you continue to carry all of them going
The current packages was hard work to do, as they implement a tight
multi-track packaging scheme that I have never before tried out:
Each git tracks one upstream subproject, with branches for each upstream
branch, branches for each Debian packaging overlay, and a branch for
"binary diffs" to recreate each registered upstream released tarball.
Branch "upstream" tracks head of upstream development.
Branch "upstream-0.84" tracks upstream mainainance of older branch.
Branch "master" is head of Debian packaging development.
Branch "master-0.84" tracks Debian maintainance of older branch.
Branch "pristine-tar" contains binary diffs for tarball recreation.
Branches "upstream" and "master" is branched off as "upstream-0.86" and
"master-0.86" when needed to make room for a new round of development
The plan is to maintain a) newest upstream branch and b) newest stable
branch and possibly c) additional older stable releases.
A) and b) is sometimes one and the same, and c) depends on interest them
both upstream, in the Alioth OLPC team and among users. So the end
result might at some times be a single maintained branch, or it may be
In other words, the plan is to track at least head of development and
head of stable. And to leave a trail behind of all stable releases for
others to spawn off from if they so choose.
>Do you have a recommended work flow for basing downstream packages on
There are several ways to derive from the Debian packages:
a) Create a fork of the Gits at Alioth
b) Rebuild/repackage source packages released for Debian
I strongly recommend to *not* fork the Gits but instead help work on
getting packages released for Debian and then grab the resulting source
packages and derive from there - or even better: try hard to not need to
repackage at all, but stay close enough to Debian that binary packages
can be used directly.
I recommend this not only to work as much as possible together (which
should be enough reason in itself) but also because I fear that forks on
the Git level makes it more difficult to "give back" without
complicating too much. The Git structure is pretty complex already,
*without* anyone pouring in commits from sideports, backports,
forwardports or whatever!
That said, it _is_ possible to juggle with Git but it is *not* for
beginners. And please do not expect me to help out - I already run the
OLPC team as a one-man show so I have absolutely no interest in spending
additional time in *not* gaining more manpower to that team.
>I got my mind wrapped around git-buildpackage last night. I cloned your
>work and tried build some of them on GnewSense.
>It there a prefered method for setting the upstream for third and
>lower generation packages? The best I could come up with is:
>1. git.sl.org -> upstream
No. "upstream" is a mixture of Sugarlabs Git and Sugarlabs tarball
releases merged in.
>2. manually sync /debian from git.debian.org to git.gnewsense.org
>3. do final work in git.gnewsense.org
Is Alioth such a cruel place to work together? Is it me - am I awful to
work with? Why do you ask for my advice on how to most effectively
avoid working together with me?!?
Do whatever you want. But my advice is to *develop* the packaging
unified at Alioth, and only (optionally!) fork the resulting source
packages when released for Debian.
My advice to less adventurous folks than David here is to help package
more activities before diving into the Glucose parts. And with that I
mean "first class activities", i.e. activities written in
arch-independent Python without exotic non-Sugar dependencies.
Calculate is a marvellous example of a "first class activity": It stays
backwards compatible with 0.82, by carefully wrapping newer funky
features and preserve fallbacks. When you (upstream) wants to keep it
simple for users by shooting yourself in the foot with that too simple
versioning system, there is really only one sane solution: Keep the
activities backwards compatible!
Hope you will engage more than just fork off,
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the Debian-olpc-devel