Re: [blfs-dev] Release Plan (Was: Separate Xorg packages)
On Thu, 28 Jun 2012 17:33:02 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: Striving for perfection is the enemy of good enough. I'm in the 'good enough' camp. I think that the BLFS book was originally much smaller than it is today - compare 5.0 in the archive. If it has to be nearer to perfect than I prefer, reading all the details will take a very long time. Meanwhile, the world marches on. The more a release is delayed by polishing the contents, the more it will be out of date, and the harder it will be to explain why anyone would want to read it instead of using the development book. Exactly. To me, a release of BLFS is of interest only as an entry in the archive that we can look back on. People should always be using the svn book as there will always be improvements. I think having some sort of package freeze is an inconvenience that will get in the way of the important day to day work of maintaining the book. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Release Plan (Was: Separate Xorg packages)
On Wed, Jun 27, 2012 at 10:31:01PM -0500, DJ Lucas wrote: 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). The last release (6.3) was in August 2008. It was for LFS-6.3 which had come out nearly a year before. I understand the idea of making it perfect, and I support improving access for those with visual impairment. I'm lucky - my disability doesn't prevent me using a keyboard and mouse, or reading a screen. BUT ... who here has the hardware for screen reading ? I recall that a previous request to add that to the old Live CD failed for want of anyone with the hardware who was able to contribute (google found that earlier this year when I was checking dependencies for one of the gnome-related a11y packages). OTOH, a few years ago I was involved with AmigOne linux : there was a late-2.4 kernel for that machine, with all sorts of weird and wonderful hacks, but kernel development was on 2.6. I did manage to get some patches for 2.6 together, but in the end my machine died (its shutdowns while compiling gcc turned out to be caused by the CPU overheating, and happened once too often). The other people there were fans of the amiga, for whom linux was an intermediate OS until OS4 or whatever it was called was ready. I became used to the phrase it will be ready when it's ready. When I left there, the Amiga OS was still described as nearly ready and the hardware was already obsolete. Striving for perfection is the enemy of good enough. I'm in the 'good enough' camp. 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 think that the BLFS book was originally much smaller than it is today - compare 5.0 in the archive. If it has to be nearer to perfect than I prefer, reading all the details will take a very long time. Meanwhile, the world marches on. The more a release is delayed by polishing the contents, the more it will be out of date, and the harder it will be to explain why anyone would want to read it instead of using the development book. 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. :-) For BLFS in its current form, I think branching is the wrong approach. If we have a *short* freeze, only essential changes will go in and there is a good chance that they will not break other packages. Branching is viable if somebody is going to commit to maintaining the branch for some time after its release, e.g. with updates and point releases to fix vulnerabilities. I don't see any enthusiasm for that. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Release Plan (Was: Separate Xorg packages)
On Tue, Jun 26, 2012 at 08:25:12PM -0500, Bruce Dubbs wrote: 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. With the exception of delaying for the Mesa/libdrm/etc issue, I'd love to see a matched release. So far, the knock-on effects from recent LFS changes have been limited, at least in what *I* have built, but some things will always be unknown (e.g. automake-1.12 : it impacted agg-2.5, possibly will impact anyone running autofoo on other old packages). If there is general agreement in BLFS, might be worth mentioning it on the other list ? Of course, it's always possible that a change from out of the blue in LFS will cause more problems - I remember make-3.82, I think it came quite late in the cycle for whichever version of LFS, and several BLFS packages were impacted. I really don't know for certain how much has not been tested recently. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Release Plan (Was: Separate Xorg packages)
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
[blfs-dev] Release Plan (Was: Separate Xorg packages)
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 ;)
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 ?
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Release Plan (Was: Separate Xorg packages)
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.
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.
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.
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.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
