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.
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.
> 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.
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.
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'.
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.
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.
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.
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.
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.
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.
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.
--yaacov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
