[Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!

[Jonas Smedegaard]

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

-- 
* 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
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090920/3745f6de/attachment.pgp