Build streams; preparing for 8.2 release.

[Dennis Gilmore]

On Thursday 12 June 2008, Chris Ball wrote:
> Hi,
>
> At the IRC software meeting yesterday we discussed creating some new
> build streams in preparation for our August "8.2" release.  These
> streams were proposed:
>
> * Unstable/Joyride:  This will move immediately (well, within a day or
>   two) to be a copy of the "olpc-3" stream, which is a build stream
>   preparing for a switch to Fedora 9, instead of the current Fedora 7.
>
>   The Joyride release process will continue to be followed here.  There
>   is still a lot of work to be done on the F9-based build:  it will be
>   broken for a while as the kinks are worked out.  Please help!
>
> * Testing:  This will also be a copy of olpc-3, but with a different
>   release process.  Changes will be moved from unstable into testing
>   upon negotiation with the release engineer, Michael Stone.  This
>   build stream will be used by our QA team and community to assess
>   the readiness of features for the 8.2 release.
>
> * Stable: Stable builds are specified by their release name (e.g. 8.1.1,
>   8.2), and the procedure for packages moving from Testing into Stable
>   releases involves the Unscheduled Release Process:
>     http://wiki.laptop.org/go/Unscheduled_software_release_process
>
> Anyone familiar with Debian's build naming will see intentional
> similarities here.
As i have said previously and repeatedly been ignored (like most of what i 
say).  this process will not work.  period.  It cant be made to work in the 
same fashion as Debian  because its not Debian.  everyone needs to quit 
trying to fit square pegs into round holes.  


things more than likely will never be able to move from testing into stable  
in the proposed format.   why?   because Testing is based on F-9 and uses the 
F-9 toolchain and dependencies.  and stable is based on F-7 which uses 
completely different toolchain and dependencies.  We need finer grained 
control over things.


We need to follow the fedora process here if we want things to work.  

Throw away what you know about debian's process.  right now it counts for 
squat.

Each stable tree need to have its own updates and updates-testing tree. which 
means once we create a stable branch we no longer build to it   instead we 
build to a updates-testing-candidate tag we them move a package to 
updates-testing   
after testing we move to updates 

we can then do stable releases based on base + updates  

So we now have dist-olpc3  its a development tree   things are automatically 
added to that tree as built.  
when we release a stable build on dist-olpc3  we freeze that tag forever.  

potential updates will then get build against dist-olpc3 and 
dist-olpc3-updates.  

they will land in dist-olpc3-updates-candidate
developer will request that they get pushed to dist-olpc3-testing  a which 
point rpms will be signed and pushed to a yum repository where they can be 
tested.  once they have proved themselves in testing.  we can then push to 
dist-olpc3-updates.


This means that we will sign all the rpms we push for stable trees.  we will 
need to have a popper master mirror that can be mirrored out.   development 
tree rpms will be unsigned.

we can then maintain multiple stable trees.  if we need to maintain two stable 
trees off of one fedora release then we can branch things and have a 
dist-olpc3-1 for instance  


I want to reiterate that OLPC  needs to work with fedora.  We are based on 
Fedora  and continue to cause ourselves unneeded pain by not working with 
fedora.

If someone is looking for a good way to contribute to OLPC then please get 
involved in packaging for Fedora.  we have many things that need to be put 
into fedora.    including 

olpcrd
etoys
pyabiword
rainbow
olpcupdate
olpccontents
bootanim
bootfw
fonts-thai-ttf
olpc-library-core
olpc-library-common
olpc-licenses
squeak-vm
olpc-logos
libabiword 
libabiword-plugins
GConf2-dbus
hulahop

Some of the require other packages not in fedora.  some of which olpc has 
forked.  we also need to ensure we do our work upstream.  doing things 
upstream means that 1) We help everybody  not just ourselves 2) that the 
maintainence burden is smaller


Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080612/f2f2c154/attachment.sig>