On 06/26/2012 08:25 PM, Bruce Dubbs wrote:
> Ken Moffat wrote:
>> On Tue, Jun 26, 2012 at 04:02:05PM -0500, Bruce Dubbs wrote:
>>> The only caveat is to consider the release plan. Right now, I'd
>>> like to release a coordinated LFS/BLFS on 1 September. That means a
>>> package freeze and an -rc1 for both about 1 August or slightly over one
>>> month from now.
>>>
>> Someone might also want to think about some of the items at the
>> bottom of longindex.html, Some of what is in section g ('Others')
>> is reasonable, some doesn't necessarily belong there. Not sure if
>> everything in the preceding Bootscripts section belongs there -
>> maybe it all does! Certainly the subsequent 'L' and 'O' headings
>> look as if their contents are in the wrong places. Indexing is
>> easily broken ;)
> Yes, the index entries are tedious, especially for a new package with
> lots of items. That's one reason I think a whole month is needed. Even
> that may not be enough.
>
I'm afraid a month probably won't be enough time. It has been several
years since a BLFS release. I'm not even sure what year that was now,
but it has been overwritten by years of only basic proof reading by
people perusing the commit logs and the instruction authors themselves.
The entire book needs to be reviewed for spelling, grammar, and
consistency, which is a painful job that few of us will _want_ to do. In
addition to a spell checker and manual reading (out loud), a decent
screen reader works wonders for finding transposed words and odd phrases
(and it gives those of us without disabilities a good reason to test at
least part of the accessibility stack).
> There's a lot of things that could be done at that time like moving
> packages to different sections, reviewing especially the Preface and the
> first three chapters which have a lot of text, etc.
>> If I'm around and not doing anything else after the package freeze,
>> you could ping me - I suspect most editors don't really care about
>> longindex. I tend to use it a lot, and have just been looking at
>> it for some things I plan to (re)propose shortly.
>>
>> Beyond that, are we supposed to start tagging packages for 7.2 once
>> the freeze starts ? If so, what happens if anything in LFS has to
>> be revised during the -rc ?
> If we freeze LFS, then I think we can mark BLFS with an entity like
> &lfs_72_checked; and have it display -rc1 while we are in freeze and
> then at release just change the definition.
Actually, the original plan was to make it empty at release if we are
going for a matching release version. I don't know if this holds true
today. Also, in the old days (it was sooo long ago), we had waited for
LFS final, then freeze. BLFS would lag behind LFS by at least a couple
of months for final commits and cleanup. I don't know if we should
follow the old way, but figured I'd throw it out there.
> I suspect that packages that must be changed during freeze would only be
> due to bugs or security issues, not enhancements. Generally, if a
> package is major.minor.patch and only the patch level changes, updating
> does not affect other packages.
Personally, I'd suggest branching at package freeze time, and back
porting changes from head. I realize that is extra work for whoever the
RM is, but the one thing I really do not like to see is somebody sitting
on a big commit for a month or better because of a package freeze for
release. That is really frustrating from a peon's POV! We seem to have a
pretty good editorial team now, maybe a little rough around the edges,
but for the most part we are tolerable of each other and work pretty
well together. I'd like to see some of the (not so) new additions stick
around for a while. :-)
> One thing to note is that my release proposal is just that, a proposal.
> I'd like to get some agreement this is the right thing to do and the
> approach is reasonable.
>
See minor points above.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
