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 forward?
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 releases.
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 several.
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 work.
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 DebianI 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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
