head	1.1;
branch	1.1.1;
access;
symbols
	import-20090318:1.1.1.4
	import-20081205:1.1.1.4
	rel-8-1-2-sv:1.1.1.4
	import-20080404:1.1.1.4
	import-20071105:1.1.1.4
	import-20070116:1.1.1.3
	import-20061124:1.1.1.3
	rel-6-2-2-sv:1.1.1.2
	rel-6-2-1-sv:1.1.1.2
	import-20060615:1.1.1.2
	import-20060530:1.1.1.2
	import-20060516:1.1.1.2
	import-20060421:1.1.1.2
	import-20060406:1.1.1.2
	import-29mar06:1.1.1.2
	import-14mar06:1.1.1.2
	import-13mar06:1.1.1.2
	fixed-post-import-14feb06:1.1.1.2
	import-14feb06:1.1.1.2
	fixed-post-import-6feb06:1.1.1.2
	import-6feb06:1.1.1.2
	import-6sep05:1.1.1.1
	freescale:1.1.1;
locks; strict;
comment	@# @;


1.1
date	2005.09.06.10.08.01;	author seh;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2005.09.06.10.08.01;	author seh;	state Exp;
branches;
next	1.1.1.2;

1.1.1.2
date	2006.02.06.14.19.56;	author seh;	state Exp;
branches;
next	1.1.1.3;

1.1.1.3
date	2006.11.27.11.19.19;	author seh;	state Exp;
branches;
next	1.1.1.4;

1.1.1.4
date	2007.11.06.15.44.45;	author seh;	state Exp;
branches;
next	;
commitid	AdKoH3Xx8FxdUwEs;


desc
@@


1.1
log
@Initial revision
@
text
@%TOPICTITLE%
---

%TOC%

---+ Introduction

This page gives a brief overview of how to make an LTIB binary BSP release.
The specific example shown (for clarity) is for the mpc7448taiga, you
should make substitutions for your own new platform as appropriate.


---+ Summary of strategy

   * Remove any development config options and non-default packages
   * Force re-build the image
   * Make sure your boots and runs normally on the target
   * Save your work
   * Run a release cycle
   * Test your iso (if you have made an binary release)
   * Make a maintenance branch in CVS
  

---+ Planning

---++ Mandatory requirements

   * Make sure you don't release (or put anything in the GPP) that is
   legally restricted.  Remember to check things like web pages for
   copyrights etc.

   * No files in the GPP should be overwritten.  If you want to modify a
   file, you need to rename it and change the reference to it.

   * Always do a --dry-run first when rsyncing to the GPP in Austin (make
   sure only the files you recognise are going to get copied there).


---++ Guidelines

These don't have to be followed, but I think are helpful.

    * The release tag name could be rel-mpc7448taiga-5-3-1-rc1
    The logic for this is as follows:
       * rel (for release)
       * mpc7448taiga (board name)
       * 5-3-1 (2005, Q3, 1st release in this quarter)
       * rc1 (release candidate 1, you may need some iterations)

   * You should branch CVS after a new release, this will help with
   maintenance.  Only stabilisation of the release should be done on the
   branch.  In this example, the branch name would be: branch-mpc7448taiga-5-3-1


---+ Execution details

---++ Remove any development config options and non-default packages

   * Configure LTIB to the default state you want to adopt for the release.
   Make sure you turn of any  development configuration options (such as
   CONFIG_PKG_KERNEL_WANT_CF)

<verbatim>
./ltib -m config
</verbatim>


---++ Force re-build the image

   * Make sure you force re-build at least all packages that are
   turned on by the default configuration.

<verbatim>
./ltib -f
</verbatim>

---++ Make sure your image boots and runs normally on the target

Before you even contemplate making a BSP as a release, you should be
boot the image on board  and run without any problems.


---++ Save your work

---+++ Save your config files

You need to save any updated or new configuration files so that they
will get captured in CVS.  Here is an example:

<verbatim>
cp config/platform/mpc7448taiga/.config config/platform/mpc7448taiga/defconfig
cp config/platform/mpc7448taiga/linux_2.6.11_mpc7448_taiga_def.config.dev config/platform/mpc7448taiga/linux_2.6.11_mpc7448_taiga_def.config
</verbatim>


---+++ Check-in additions and changes to CVS

Assuming you have a read/write cvs account for ltib, in this example
we would do the following:

<verbatim>
cd ~/ltib
cvs add config/platform/mpc7448taiga
cvs add config/platform/mpc7448taiga/*
cvs add dist/lfs-5.1/u-boot/u-boot-fsl-mpc7448.spec
cvs add dist/lfs-5.1/kernel/kernel-2.6.11-mpc7448.spec
cvs commit
</verbatim>


---+++ Update the GPP

You now need to upload your sources/patches to the GPP, an example is shown
below, you may need to adjust the source/destination settings
according to your settings in your .ltibrc file:

*NOTE* the trailing '/' in /var/tmp/pkgs/ is needed!

   * Do a dry run, and correct if any unwanted files appear in the list
   of files to transfer
<verbatim>
rsync --dry-run -e ssh -av --ignore-existing /var/tmp/pkgs/ 10.82.193.3:/var/tmp/ltib_www/gpp 
</verbatim>

   * After correcting if necessary, run the actual rsync.
<verbatim>
rsync -e ssh -av --ignore-existing /var/tmp/pkgs/ 10.82.193.3:/var/tmp/ltib_www/gpp 
</verbatim>


---++ Run a release cycle

LTIB supports making a binary iso release.  The default action of
running this is:

   * LTIB source is checked to make sure it is in sync with CVS
   * CVS is tagged with the release name (a default with timestamp is provided)
   * config files are checked to make sure they are saved
   * The LTIB sources are copied to a staging area
   * All referenced sources in the GPP are copied to the staging area
   * A RELEASE_INFO file is created and put in the staging area
   * An iso image of the staging area is made.
  
Here is an example:

<verbatim>
./ltib -m release
Please enter the cvs tag name for this release, or
if you just type enter, the timestamp rel-mpc7448taiga-1122556078 will be used

rel-mpc7448taiga-5-3-1-rc1
</verbatim>
  
The above command created the iso image "ltib-mpc7448taiga-20050728.iso"


---++ Test your iso image

You should copy your iso image to another machine and mount it and test it:

   * as root:
<verbatim>
mount ltib-mpc7448taiga-20050728.iso /mnt/cdrom -o loop
</verbatim>

   * as a normal user
<verbatim>
/mnt/cdrom/install
</verbatim>

By default, LTIB will get install in the dirctory 'ltib' in the current
working directory.

   * as a normal user, build and install
<verbatim>
cd ltib
./ltib
</verbatim>


---++ Make a maintenance branch in CVS for this release

If the test of the iso image was okay, you should now make a
branch in CVS.  All further minor releases should be
made on this branch.  The branch name should be the same as
the release tag name with 'rel' replaced with 'branch', the
'rc1' should also be dropped.  Here is a continuation of our example:

<verbatim>
cvs rtag -b -r rel-mpc7448taiga-5-3-1-rc1 branch-mpc7448taiga-5-3-1 ltib
</verbatim>

This say make a branch rooted at the tag 'rel-mpc7448taiga-5-3-1-rc1',
the name of the branch is 'branch-mpc7448taiga-5-3-1'.

---+++ Update your working copy of LTIB for this board to use the branch

If want to work further on maintenance updates to this release, you
need to use this branch.  To do this, updated your working copy
to use the head of this branch:

<verbatim>
cvs up -r branch-mpc7448taiga-5-3-1
</verbatim>


----

-- Main.StuartHughes - %SERVERTIME%
@


1.1.1.1
log
@Import from fsl 6sep05
@
text
@@


1.1.1.2
log
@Import from fsl 6feb06
@
text
@a11 16
If instead you just want to mark a release in cvs, but not make an iso image, 
you should skip the sections:

   * *Run a release cycle*
   * *Test your iso image*

Instead, the following actions should be taken:

   * Tag cvs with some meaninful name, for instance:
   <verbatim>$ cvs tag -c rel-mpc7448taiga-5-3-1-rc1</verbatim>

If this is a release that will be sent to external parties, cvs should be
branced as described below in the section

   * *Make a maintenance branch in CVS for this release* 

d111 5
a115 1
---+++ Update the PPP
d117 12
a128 3
You now need to upload your sources/patches to the PPP.  To do this
point your browser at:
 http://auslxpb02.mtwk.freescale.net/ltib-cgi/ppp_upload.cgi
a129 1
And upload each file not already in the PPP/GPP.
@


1.1.1.3
log
@Import from fsl 20061124
@
text
@a3 11
<verbatim>
Copyright  Freescale Semiconductor, Inc. 2004-2005. All rights reserved.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.  A copy of the license is included in the file doc/COPYING
</verbatim>


d12 1
a12 1
If instead you just want to mark a release in CVS, but not make an iso image, 
d20 1
a20 1
   * Tag CVS with some meaninful name, for instance:
d23 4
a26 2
If this is a release that will be sent to external parties, CVS should have
already been branched as described [[#MakingBranch][below]]
a30 10
---++ If this is a brand new BSP

   * Identify an existing BSP that is close to the new one you want to create
   * Copy it's *config/platform/TARGET* to *config/platform/NEW_TARGET*
   * Edit and modify your copied *main.lkc* as appropriate

---++ Common steps (new or updating existing BSPs)

   * Develop your BSP to the point where it roughly works and you'd like
   to stabilise (e.g. you no longer want changes from the mainline CVS)
a31 4
   * Make a branch in CVS.  This will protect you from mainline changes

---++ Common steps that cycle

d35 1
a35 1
   * Run a release cycle (making sure you build and tag from CVS)
d37 1
a37 7
   * Re-work any problems found in the release
   * Repeat these "Common steps" until you are happy that you have something
   that can be released to people outside the test group.  Conventionally
   test releases will be: -rc1, -rc2,...-rcn.  Once you have something
   to release you can drop the -rcn in the tag name
   * To release this iso outside, make sure you have source/patch approval and
   license sign off.
a38 20
---++ Post release steps

   * Merge back from your branch to the mainline.  This is essential if
   you ever want to make a new (non-maintenance) release.  This is because
   new (non-maintenace) releases will be branched from the CVS trunk and
   so that trunk needs to contain all the changes you made on the branch.

---++ Maintenance releases/updates

Imagine you have made your iso release and people have found bugs and
you want to fix them and possibly issue a new "maintenance release iso".
Here's what you should do:

   * Working on the branch you released from (not the CVS trunk!!!). Make
   your changes and bug fixes.
   * If you want to make an iso image, follow the "common steps" section.
   If not, make sure tag the CVS branch to identify this maintenance release.
   * When you are done, you must merge from your branch all the changes
   from the last merge up until the tip of the branch.
   
d44 1
a44 2
   * If this is a public release, make sure you don't include any
   sources or patches that are
d48 1
a48 1
   * No files in the PPP/GPP can be overwritten.  If you want to modify a
d51 4
d57 1
a57 1
These don't have to be followed, but I think are helpful and good practice.
d59 10
a68 11
   * The release tag name could be rel-mpc7448taiga-5-3-1-rc1
   The logic for this is as follows:
      * rel (for release)
      * mpc7448taiga (target name)
      * 5-3-1 (2005, Q3, 1st release in this quarter)
      * rc1 (release candidate 1, you may need some iterations)

   * You should have branched CVS before you started the release process,
   this will help with maintenance.  Only stabilisation of the release
   should be done on the branch.  In this example, the branch name would
   be, branch-mpc7448taiga-5-3-1
a72 52
---++ If this is a new BSP

   * Identify an existing BSP that is close to the new one you want to create
   * Copy it's *config/platform/TARGET* to *config/platform/NEW_TARGET*
   * Edit and modify your copied *main.lkc* as appropriate
   * Upload any new sources/patches to the PPP (you can use ./ltib -m dltest
   to identify them).
   * Save your work, for example:
<verbatim>
$ cvs add config/platform/mpc7448taiga
$ cvs add config/platform/mpc7448taiga/*
$ cvs add dist/lfs-5.1/u-boot/u-boot-fsl-mpc7448.spec
$ cvs add dist/lfs-5.1/kernel/kernel-2.6.11-mpc7448.spec
$ cvs commit
</verbatim>
   * continue to work on your BSP until it basically works.


#MakingBranch
---++ Make a maintenance branch in CVS for this release

Once you have your BSP basically working and you want to be protected
from new development updates on the CVS trunk you should make a
branch in CVS.  All further minor releases should be
made on this branch.  The branch name should be the same as
the release tag name with 'rel' replaced with 'branch', the
'rc1' should also be dropped.  Here is an example:

<verbatim>
#### make sure you are up to date and commit all your work so far
$ cvs up -dP
$ cvs commit
#### tag the trunk in cvs
$ cvs rtag mpc7448taiga-5-3-1-bp ltib
#### make the branch using your tag as the point to branch
$ cvs rtag -b -r mpc7448taiga-5-3-1-bp branch-mpc7448taiga-5-3-1 ltib
</verbatim>

This say make a branch rooted at the tag 'mpc7448taiga-5-3-1-bp',
the name of the branch is 'branch-mpc7448taiga-5-3-1'.

---+++ Update your working copy of LTIB for this board to use the branch

If want to work further on maintenance updates to this release, you
need to use this branch.  To do this, updated your working copy
to use the head of this branch:

<verbatim>
cvs up -r branch-mpc7448taiga-5-3-1
</verbatim>


d96 2
a97 2
boot the image on board  and run without any problems.  Ideally
do some more thorough testing.
d107 2
a108 2
$ cp config/platform/mpc7448taiga/.config config/platform/mpc7448taiga/defconfig
$ cp config/platform/mpc7448taiga/linux_2.6.11_mpc7448_taiga_def.config.dev config/platform/mpc7448taiga/linux_2.6.11_mpc7448_taiga_def.config
a110 1
---+++ Upload any new sources/patches to the PPP
d112 1
a112 3
You now need to upload your sources/patches to the PPP.  To do this
point your browser at:
http://www.bitshrine.org/cgi-bin/gpp_upload.cgi
d114 2
a115 3
And upload each file not already in the PPP.

---+++ Check-in additions and changes to CVS
d118 6
a123 1
$ cvs commit
d126 9
d185 1
a185 1
---++ Final release and post release merge
d187 5
a191 2
Once you have been through -rc1, -rc2, -rcn and have a good release that
you want to publish more widely.
d193 16
a208 2
   * Release it and drop the -rc extension to the tag name
   * Merge back from your branch into cvs
@


1.1.1.4
log
@Import from fsl 20071105
@
text
@d212 1
a212 1
You now need to upload your sources/patches to the GPP.  To do this
d216 1
a216 1
And upload each file not already in the GPP.
@


