LFS Milestones

DJ Lucas dj at linuxfromscratch.org
Mon Oct 6 22:07:01 PDT 2008


Bruce Dubbs wrote:
> DJ Lucas wrote:
>   
>> Bruce Dubbs wrote:
>>     
>>> I have added a new milestone, 6.4, for the current effort.
>>>       
>
>   
>> Yeah, actually. 6.4 sounds good to me.
>>     
>
> OK, I have fleshed out the description of 6.4 and 7.0.
>
> http://wiki.linuxfromscratch.org/lfs/roadmap
>
> I've set a tentative target date of 6.4 as November 1 with the limited goal of
> updating all packages to latest stable releases.
>   
> For 7.0, the tentative target date is March 31, 2009 with the goals:
>
>    * Add x86_64 64-bit instructions
>       o Still to be decided if a pure 64-bit or mixed 64/32-bit system should be
>         targeted
>    * Add introduction to Linux Standards Base
>    * Update packages to latest stable releases
>   
Cool.
>> Errata shouldn't sit around for 2 or 3 months, it should be addressed by
>> a new micro release in the release branch if the changes are not too
>> invasive. Take for instance the Perl-5.8.8 security patch. Micro package
>> revisions can also take place here.
>>     
>
> That seems reasonable.    It
> would not be hard to branch a 6.3.1 from 6.3 and commit changes to that as
> appropriate.   I'm not sure what the release procedures should be.  
Probably just use tags at that point since it is only in maintenance mode.
> Do we do a 
> -rc1, etc for a minor errata change?  I am thinking that would be overkill. 
I agree.
>  I 
> suppose that a message that the branch is ready to the -dev list would be enough 
> to decide if it's ready and then go through the normal process of building the 
> book in the various formats, updating the web site, and making the announcement 
> would be appropriate.
>
>   
Include something to the effect of it being a bugfix release or point 
release and that changes are only for security fixes or other minor errata.
> As an aside, how do we handle the change log?  Do we leave in all the changes 
> form 6.2 to 6.3 and add the changes for the point release to the top, or do we 
> just put in the changes made in the point release.
>
>   
We currently have a "What's new since the last release" page.  The first 
line on that page says "Below is a list of package updates since the 
last release of the book."

How about addin an {H2} for each version?  I haven't looked at LFS 
sources to see exactly how that would work yet.

Since it is only a point bugfix release, the changelog should still 
include the changelog from the previous release IMO.
>
>   
Added the PM to future for now so that people see it there.
> There is nothing stopping an editor from branching for experimental purposes 
> like Jeremy did with his pure 64-bit version.   It doesn't have to be done at 
> the head of the -dev version.
>   
That depends on it's intended target for inclusion, but most likely, 
this will be trunk to minimize the amount of merge issues when it comes 
back for inclusion.  I can't think of an example where it would be 
appropriate to branch from next release target, but who knows.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.




More information about the lfs-dev mailing list