Yaacov,
Thanks for this, this is exactly the sort of discussion I was after...
On Jul 27, 2010, at 6:06 AM, Yaacov-Yoseph Weiss wrote:
> 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.
It's over 500 distinct email addresses.
> I'm risking insulting people, but it seems to me that the alfs, clfs,
> hlfs, and livecd
> projects are basically dead.
Indeed. And an email I sent last night to the livecd list with the intent of
measuring interest of resurrection met with a rather interesting reply that I
still have to respond to.
> Most of the changes discussed are in administration and development, which
> really don't concern most users, for reasons I'll discuss below.
Fair enough.
> 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.
So you think these should be more prominent?
> 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).
Yes, that certainly could be done, and I definitely could see the value of that.
> 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'.
Indeed. I was in fact looking to make the WikiStart page the main start page
for each project. Doing so would require a code edit (or plugin perhaps) to
replace the Overview page with the wiki page, or at least swap them.
> 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.
Heh, it's interesting that you should say that. That was, IIRC, one of the
things that was disliked about the old purple-y website. I think this is a
valid point, and if we get the above two things sorted, this should also sort
itself out.
> 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.
Except that the point was, if you recall, to see whether this would make a good
replacement for the main site.
> 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.
I find this an interesting thought. Any further thoughts along this line as to
what would 'engage' readers more?
> 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.
Yes, you've hit what I think amounts to an attitude problem in LFS. Sometimes
it's very heavy. 'This is how we do it, because this is how we've always done
it. I see no reason to consider another solution because this doesn't affect
me, and I can't be bothered to work on fixing this issue for someone else. Why
don't you do things the way I like to do it?'
Granted, you can't cater to everyone's preferences, and it's all the more
difficult when there are few hands lifting the load, but there could definitely
be a more sympathetic and welcoming atmosphere.
> 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.
Agreed.
> 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.
Agreed and again, personally, I feel it's connected to the same reasons as my
comments above.
> 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.
I think all of the above are great suggestions, Yaakov. I challenge you now to
take the next step and develop some of these ideas with a little more detail
and see if you can get some momentum behind them. :-) Not a very easy task, I
know, but I'll help as I can. For example, I've done a lot of work with RPM
recently in LightCube OS. I think there are possibilities there, and I'm
thoroughly enjoying using rpm now, since I understand a lot more about how it
works and why it does what it does. Of course, there are other options besides
RPM and there are other ways of doing things - it would really be nice if LFS
was a more dynamic and sharing community. Having a more dynamic and sharing
website might make that more of a possibility.
Regards,
Jeremy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
