Re: [Ltib] making ISO release (aka -m release)

[Stuart Hughes]

Hi Andrea,

please see inline.

On Tue, 2007-03-13 at 16:20 +0100, Andrea Galbusera wrote:
> Hi Stuart,
> thank you for reply. Lot of interesting suggestions in your answer.
> 
> On Thu, 2007-03-08 at 14:01 +0000, Stuart Hughes wrote:
> > Hi Andrea,
> > 
> > There are quite a few items to cover here, but to cut to the chase, you
> > can do what you want.
> > 
> > The longer answer is this:
> > 
> > * If you want to make a derivative BSP, then you should really start
> > from the external sources provided at bitshrine.org (via savannah).  The
> > reason for this is that in the "official" iso releases provided by
> > Freescale, there could be some components that require explicit end user
> > license agreement, or in some other way not be 100% re-distributable by
> > you.  For example, I don't think all of the documentation that is on the
> > iso images is freely distributable.
> 

If capturing as an iso is the most helpful, then you can do that subject
to the mentioned licensing issue.  This only applied if you started with
an iso image, all the LTIB stuff from bitshrine/savannah is open-source.

> Ok, I have to check for licenses, but what I want to do is not really
> redistribute the BSP to the world. I'd like to collect all the changes I
> made to sources/configs/filesystems against the Freescale BSP together
> with some docs and freeze them for future fix and/or enhancements by,
> maybe, one of my colleagues.
>
> > 
> > * I would recommend doing the whole thing using savannah CVS and the
> > GPP.  Unless you have something closed, this will offer you the simplest
> > ongoing maintenance effort.
> 
> Let me give you an example. I have a patch to the kernel (generated with
> -m patchmerge) that I use to enable a few more uarts my target have with
> respect to the mpc5200 target by Freescale. This is basically two or
> three lines of code in the platform initialization code. Would you post
> this to the GPP?
> 

If this configuration could be useful to someone, then yes why not.  The
only reason not to post to the GPP is if for some reason you don't want
those file being public. The GPP contains all sorts of things from
"official" patches to simple testing patches.

> > 
> > * If you don't want to do that and you intend to distribute your own
> > BSPs and maintain them, even if you don't want to publish some of the
> > content, you'd still be better of using the public CVS.  The ltib source
> > tree normally only has references to content, and you don't have to
> > upload those to the GPP.  The advantage this has is that you'll be able
> > to keep your BSP in sync with the master LTIB project.  What I'm
> > suggesting is that if you had CVS write permissions you can create and
> > maintain your own branch.  You'd then be able to make releases and tag
> > CVS.
> 
> Again, if I don't get it wrong, platform configs are included in ltib's
> sources. Would you suggest to get write permission to the CVS and commit
> platform configs for my custom hardware?
> 

If you like yes, you could get CVS write permission and GPP upload
permission.  Then you'd make a new platform for your hardware by doing a
copy of the closest current example.  Another user has already done this
(see the cobra5475 which was initially based off the mcf547x_8x).

> > 
> > * If you don't want to use the public CVS to make your BSP available,
> > I'd recommend that you create your own private LTIB CVS project and then
> > use the public CVS as the initial (and subsequent) vendor import.  That
> > way you have a means of keeping your private tree in sync with the
> > public one.  Also this will allow you to use the normal '-m release'
> > process that references CVS
> 
> This sounds like the most promising solution for me. Just wanted to try
> it now, but I can't checkout from CVS... I get errors from the site
> being unable to connect to the database. I'll try later and let you
> know.
> > 

Yes, I tried this morning had it seems like savannah.nongnu.org was
down.  I just tried and the site is up, but there are still problems.


> > * If you don't want to use CVS at all, you can still make a release, but
> > to do this you have to first generate a MANIFEST file that lists all the
> > files that need to go into the release, and then when you run -m
> > release, you need to use the special tag name: 'localdir'.  To generate
> > an initial MANIFEST file you need to have a CVS copy (e.g. savannah) and
> > run something like:
> > 
> > cvs status 2>/dev/null | perl -e ' 
> >     $_ =`cat CVS/Root`;
> >     ($cvsroot) = m,(/.*),;
> >     while(<>) {
> >         m#^\s+Repository revision:.*$cvsroot/(.*),v#o and print "$1\n";
> >     }
> > ' > MANIFEST
> > 
> > This file will need to be hand edited to add/remove unwanted files.
> 
> This also is something I discovered digging into the ./ltib source, but
> I didn't know how to create the MANIFEST file. I'll try this too, but
> the local CVS appears more promising.
> 

Yes, I think that is probably the way to go.  Bear in mind though if you
intend to sell/distribute your customer hardware, the public site may be
a convenient place to provide access to the BSP and updates.  

Which ever way you decide to do it, good luck and feel free to ask for
further advice.

Regards, Stuart