hmm...
On Jul 27, 2010, at 6:06, Yaacov-Yoseph Weiss <yywe...@cs.huji.ac.il>
wrote:
> O.k. I'll jump in and risk the consequences...
>
> On Tue, Jul 27, 2010 at 7:01 AM, Jeremy Huntwork
> <jhuntw...@lightcubesolutions.com> wrote:
>> It's interesting what logs will show.
>>
>> For instance, the access logs for community.linuxfromscratch.org
>> show 117 unique
>> IP addresses viewing the site yesterday, and 76 unique IPs today.
>> Combine the two
>> lists and there are a total of 167 unique IPs. Even taking into
>> account robots and
>> individuals viewing the site from multiple locations, that's still
>> a lot of readers who were
>> curious enough about it to go have a look.
>>
>
> Just wondering, how many people are signed up to this email list? This
> might give a
> better indication of how interested the (potential) community is.
>
> How many are on the support list? On the {b,c,a}lfs lists?
>
> I'm risking insulting people, but it seems to me that the alfs, clfs,
> hlfs, and livecd
> projects are basically dead. From a previous discussion here, I got
> the impression
> the people use their own scripts to automate lfs.
No offense to those people, but it seems that way to me as well. Maybe
there should be a way to update them all at the same time (version
wise, i mean)
For LiveCD, if ALFS is forgiving enough, I might be able to help. But
no guarantees on that.
ALFS doesn't work for me sometimes because there's something broken in
BLFS that it would fail right away and there would be no way possible
to resume. I would have to restart all over.
>
> lfs itself is in a sense stable, since most of the changes from
> version to version are
> just updating packages or textual typos.
>
> blfs support seems to be active, though development seems erratic at
> best.
>
Gah, it probably takes a long time to find all the updates... It'd be
nice if we had software that could find updates and alert blfs-dev.
There used to be a LFScript project that kept tabs, and we contributed
to places like cblfs. But it died, and we split up.
>> And yet, we have very few people writing in to express their opinion.
>> So it appears that either they don't really care,
>
> Most of the changes discussed are in administration and development,
> which
> really don't concern most users, for reasons I'll discuss below.
>
> The new site looks more modern, while staying lightweight.
>
> There are a few issues regarding content and layout.
>
> 1. There is no way to get back to the home page
> ('http://community.linuxfromscratch.org/')
> from any of the other pages.
Heh, same as trac.
>
> 2. There is no way to move from project to project. (Well, actually
> there is through
> the tiny link to 'http://community.linuxfromscratch.org/projects'
> which I just noticed,
> which is next to a tiny link for #1 above.
>
See, that can be a problem.
> 3. The home page ('http://community.linuxfromscratch.org/') should
> have a list of
> projects. It should be possible to reach
> 'http://community.linuxfromscratch.org/projects/lfs'
> directly without it happening to be in the news or a latest project
> (which it isn't).
>
> 4. The "main" page should include the content of
> 'http://community.linuxfromscratch.org/projects/lfs/wiki/WikiStart'.
> If that makes the page to lfs-centric against blfs, put it at least
> in 'http://community.linuxfromscratch.org/projects/lfs'. Try guessing
> how to read the book when at
> 'http://community.linuxfromscratch.org/projects/lfs'.
Is it possible to make the project page like what redmine.org does?
The wiki tab?
>
> 5. I don't like the design of the main page of LFS holding news
> instead of content. The
> content of LFS is generally stable. It isn't a news site which needs
> to point people
> to the latest content. Even if yes, updates of several times a year
> will not bring
> people. First time visitors need the main content, and returning users
> usually need
> links to several of reading the book, downloading it, and editing
> (developing) it. The
> current page does not supply that. News might deserve a small box on
> the side of
> the page, not most of the center of the page.
>
> 6. I don't know if this makes development easier or not.
>
>> or they're holding back from speaking their mind because of some
>> expectation of what will
>> happen when they do.
>>
>
> That is definitely an issue, though I think this isn't really the
> best example,
> since trac/redmine really makes no difference to me, and I'm sure to
> almost
> all of the readers, except for the few actual developers.
>
>> I find that very interesting. And very unfortunate.
>
> However the question of why there are very few developers is a good
> question,
> which I'll try to answer partially.
>
> Getting involved in development of LFS should generally include
> several steps.
> I'll list them and try to comment on what keeps people back.
>
> 1. Finding out about LFS. I don't think there is a problem here.
> Typing into a google
> search any of "{build{,ing},compil{e,ing},} linux from" with the
> intention of completing
> "sources" will show "linux from scratch" both on the search bar and
> within the
> results.
Always did.
>
> 2. Building the first time, following the book. The book is (mostly)
> well written and
> clear. This step can be improved by looking at points people
> repeatedly ask about
> on the support list. Issues which come to mind are configuring the
> kernel and grub.
Aha, true. Wouldn't it be better if you had example files to show?
>
> 3. Building a second time, possibly with personal "touches". I suspect
> most people stop
> here because there is no convenient way to automate the process. Doing
> it by hand
> quickly becomes boring, alfs - when it works - doesn't make it easy to
> personalize
> the result, or to read the book again while installing the packages.
> The user usually
> isn't involved enough yet to work on writing scripts for this. Perhaps
> some package
> management system can be used (or designed) for this. I suspect most
> LFS users
> install LFS once for the experience, and then forget about it due to
> this.
Lfscript used to fix this :-/
>
> 4. Finding something to suggest fixing in the book/website. Since LFS
> is relatively
> stable, finding something "real" to fix is often difficult. Before
> entering development,
> people need to feel involved, and that their suggestions will be taken
> seriously. What
> people can (an do) offer are one of the following, usually with the
> following types of
> results:
>
> 4.a. There is issue xyz in service web/bug report/mail list which
> probably can be
> fixed by doing abc. A random user can't just update the server, or
> even look at
> the configuration in order to build a patch, but he can suggest an
> improvement.
> The response is usually how to (partially) get around the issue. For
> instance,
> When people reply to the mailing list digests and edit the subject,
> the reply
> is not threaded with the original mail in the archive. I noticed that,
> and suggested
> how it could be fixed, knowing perfectly well that the maintainers
> do not mind
> fiddling with system code (as this thread proves). The reply I got
> was basically
> that I can subscribe non-digest. (which happens to not help for past
> messages.)
> Even some discussion why I was wrong and it was not an issue or more
> difficult than I thought would have been welcome.
>
Really? The reply isn't threaded? I thought it was the whole time :-/
> 4.b. Grammar or clarity issues in the text. For some reason these
> usually end
> up as a flame war. My opinion on these clarity cases, is that if
> someone says
> it is unclear to them, they should be believed, and the other side
> should at
> least understand what can be unclear (possibly only for foreigners),
> even if
> they choose not to fix it.
>
> 4.c Ask why use package A and not package B. The response is usually
> that A
> works and to prove B is better. As the developers have automated
> systems, they
> can (assuming it isn't too often) check at least that it compiles
> and boots, and
> time how long it takes. Due to #3 above, this is much more difficult
> for the random
> new user to test it at all, let alone compare the 2 options.
>
> 4.d. Report update to a package. However, this doesn't really get
> anyone involved.
>
> 4.e. Suggest "major" design updates for the book. The response is
> usually that the
> book isn't intended for this, without leaving room for discussion.
LFS is fine as it is. It's for advanced users.
>
> Finally, what do I think should be done? First, LFS needs to choose
> its direction.
> LFS itself is stable, with updates containing mostly with package
> updates. At
> this stage, I believe LFS can allow itself to extend its reach (either
> within the book,
> or around it, but within the project itself) to integrate within it
> some of the dead
> surrounding projects.
>
> Doing this will allow room for active development, and may help
> bring in some
> new blood to the development team. Several suggestions, not all of
> which I agree
> with:
>
> 1. At the moment there is usually no reason not to use the
> development version.
> I suggest releasing a stable "package update" release regularly, say
> once a month.
> A major release will be released when a new feature is ready.
>
> 2. Include more automation options with LFS. Including making sure
> they
> work with the errata pages.
>
Having the errata be updated via svn commits could be handy.
> 3. Include package management options, both for moving packages from
> installation to installation, and for keeping track of installations.
>
> 4. Include several BLFS installation paths up to date.
>
> 4a. LFS host system. Will include the host system requirements for
> installing LFS.
>
> 5. Integrating livecd project into lfs. Should be 4a with a program
> which
> creates/burns cd images.
See above.
>
> --yaacov
>
Valid Points, but some things can stay the same.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
