Hello Michal, hello Paul,
I'm a bit in-between your points of view. Me as a user have installed Familiar
with Opie and GPE on my h2200 guided by the Wiki pages. That worked well. I
tested both distributions a bit and decided to go with Opie ()maybe
only 'cause I'm a fanatic KDE user). Soon I realized that there are a lot of
bugs/quirks with this installation. Jumping of cursor at pen-up was very
annoying, the battery status was not shown (I never knew when power got
critical). Opie player didn't played ogg-vorbis files, Cursor keys, Enter and
the rest of the 4 button keys didn't work, ...
It was totally helpfull that for a few bugs there were descriptions for work
arounds on Wiki page (installation of old libraries for playing ogg-vorbis
format, etc.).
As I stumbled across Michas Page with a description of how to install his new
compiled kernel 2.6.17 (to be installed as a ipkg install) I was more than
happy that I have found a location where I could find improvements as a
normal user! ( {Un}-fortunately there was a problem with the format of his
page and that was the begin of our discussion :-)
Familiar users have to use last release and than they stuck with it and all
its bugs. I miss a branch where they can download bug-corrected, testing or
unstable versions for testing purposes or as an improvement over the official
release.
Don't know when next version of Familiar will be released. Thus I at least
encourage Michal to go on with his efforts. At minimum we can inform normal
user about the status of new kernel and that it improves situation of
Familiar stable release significantly. With a bit more effort, we can give
them ipkg packages for installing the new kernel. I don't think the normal
user should follow the kernel development. If we decide that a kernel is more
or less usefull and gives all the features hardly missed in the official
releases kernel - that's the one we should prepare for installation besides
new users will find new bugs. If others want to do the same effort for other
hxxxx devices - let them do.
I think it's much less than Michal likes to do in total, but I think it's
worth it.
My 2 cents
Gerhard
On Wednesday 20 June 2007 10:56:26 Paul Sokolovsky wrote:
> Hello Michal,
>
> I didn't reply to original post to kernel-discuss, so let me
> do a bit of cold shower now...
>
> Wednesday, June 20, 2007, 3:30:52 AM, you wrote:
> > Hello Gerhard, hello all h2200 owners!
> >
> >> BTW:
> >> I was wondering that you have created a very fine Wiki page in your
> >> private Wiki-Space at
> >> "http://www.handhelds.org/moin/moin.cgi/MichalPanczyk" but without
> >> linking to it anywhere. Why have you made this effort if you don't give
> >> others the chance to participate?
> >
> > I have created this page as a draft. I did want people to participate
> > - actually that was my greatest intention. But I had a chat with Paul,
> > and he convinced me that in this conversion it would be hard "for
> > developers" to take care of it.
>
> Yes. "Hard" as in there're not enough people and not enough
> their time to do that on the global scale. And building bright future
> in one single feud is just loss of time, IMHO.
>
> > Imagine the number of machines in the CVS tree multiplied by number of
> > kernel version "we" had.
>
> Consider just counted number of ports in CVS now - 34. Just
> updating such number of pages is the great chore, especially if they
> contain duplicate, not really related to hardware information.
>
> > That's quite a lot of work considering the
> > state of some ports - being unmaintained.
> > Of course, if You say that this can be handled by users, I will agree,
> > but... Some changes must be done by people who actually tested the
> > kernel and know exactly what problems might be experienced.... Plus
> > looking at the h2200 mailing list - most of problems are handled by
> > small number of people - where developers are in majority.... The same
> > would probably apply to such wiki page.
> >
> > Right now I am thinking of:
> > - in very short perspective - creating a page of TODO things
>
> For tracking individual items, like bugs and TODOs, we have a
> bugtracker:
> http://bugzilla.handhelds.org/buglist.cgi?bug_status=__open__&product=linux
>-2.6 That's the place to store and track individual issues, allowing to easy
> individual handling (commenting, etc.), and at the same time
> powerful aggregation and querying capabilities. Right tool for right
> task.
>
> > - in longer perspective - doing these things:
> > a) converting kernel status form "my personal" page (which I don't
> > treat in this way - it is a place to convert ideas to some more
> > realistic form) to actual kernel status of h2200 (which I feel the
> > most involved in).
>
> h2200 is just a random machine you randomly happen to have in
> your hands now. There're dozens of other machines around - what about
> them?
>
> > That would include solutions for common problems -
> > like we have just experienced with the sound module.
>
> Well, idea here is that users simply should not face such
> problems at all. Instead of writing stories for them how to deal with
> them or to solve them in the first place? In our case (great lack of
> developers), I believe most developers choose the second choice, even
> at the expense of not maintaining nice list of known problems in wiki.
>
> And in either way, this (and most other) problems are not
> h2200 specific at all. All machines have sound modules, and all need
> them loaded.
>
> > b) creating a page, with test procedures of kernel/system components
> > (ie. who to test if sound works)
>
> Ah, nice, glad to know you have this in queue ;-). Because I
> really wanted to summarize this mail with "and as you remember, we
> talked about QA formalization, that would be *much* better investment
> of effort" ;-)
>
> > and recipes how to distinct/solve
> > known problems (ie. load specific module)
>
> And this shows that even here you want to do user-orientation.
> Again, users simply should not do such things. And for developers,
> it's never easy - they have to solve hard problems anyway, so giving
> them one of hundred possible causes is not much helpful (you
> physically won't be able to list all causes). That would be helpful
> for beginner developers, but would resources put into maintenance be
> worth outcome?
>
> > c,d,... ) many others that I don't remember know or don't have time to
> > write about... (I just typed in the most of things for my short
> > perspective page).
> >
> > I hope that no one is going to be mad at me because I post it to h2200
> > mailing list, but this involves some interesting issues.
> >
> > Most of newcomers that have h2200 device and spot that Linux is
> > supported by their lovely devices ( like mine:D ) probably don't read
> > the mailing lists and are surprised that some features that are
> > obvious to work with windows don't work with Linux. The greatest
> > example - buttons, or the power status not working properly.
> > I am not sure if everybody at this port know that these problems have
> > been solved long, long time ago and h2200 is _very_ usable with Linux
> > now. I guess that there is one things missing at this port - lack of
> > good communication between developers (that have solved these issues
> > long time ago) and users (that don't read/search the list).
>
> This assumes there're 2 groups which deal with Linux-on-PDA -
> developers and users. That's not really the case. It's 3-layer
> structure, where at the top there're users, they use products and
> oftentimes five feedback to distro maintainers, and distro maintainers
> work with individual downstream software project, be it the kernel or a
> game.
>
> So, working on improving user experience if distro side of
> things. Of course, distro maintenance is pretty big effort, takes
> involvement of many people, and it's pretty hard to work both on
> specific project (like kernel), and on distro as the whole.
>
> > In the
> > first case - developers do inform the users about their (grate!!!!)
> > achievements, but in unattractive, incoherent way (at the list only) -
> > like "fire and forget" system. And then the same question are asked,
> > more developers' time is wasted - they loose they patience and don't
> > respond to next questions.
> >
> >>From the users point of view - who buys a car and signs to a fan club
> >
> > of particular brand/model to solve they basic problems ? In
> > problematic situations users call the service line (mail the
> > h2200-port) or some (the clever ones:D ) read the instructions (wiki
> > pages). But the wiki pages or install instruction don't mention about
> > possible problems with h2200....
> >
> > Why did I write all this text? Because I feel that there is a need for
> > more cooperation between developers and users at hh.org. I am probably
> > never going to be a real developer - I don't feel strong enough in
> > kernel programing, development philosophy/habits/etiquette and in free
> > communication in English. But I have spent a lot of time to find
> > solutions for the problems I had with h2200 and that paid back -my
> > h2200 is usable and I know how to bring it to this state.
>
> Too bad, that you still treat that as h2200 belongings ;-(. We
> just have this prolonged feudalistic stage which doesn't want to give
> up on peoples' minds ;-).
>
> > Now I am asking for some help from both sides:
> > - users - in updating the wiki pages, (maybe we should have a Q&A page
> > in h2200 port?), sharing solutions (for wiki pages, interesting
> > projects involving ipaqs, ways to promote hh.org projects), finding
> > bugs, etc.,
> > - developers - in some web space professionally maintained [*] and
> > keeping/building[**] fixed components in ipk form, and (maybe) sharing
> > the latest (development) kernel in the web so that every user could
> > try it out, without the need of compiling it by himself. That type of
> > solution (together with test procedure page that I have mentioned
> > earlier) would help in testing and finding bugs ....
>
> So, you want after all to make your try on distro
> maintenance... But why don't you want to join with one of existing
> distros instead, so your effort will be not local randomly-directed
> efforts, but instead part of bigger idea, and thus have more chances
> to not be lost (or wasted effort in the first place) and to contribute
> to Linux-on-PDA in general?
>
> > I hope that there is going to be some discussion about the
> > problems/ideas I mentioned and something good is going to come out of
> > that.
> >
> > Finally I would like to add a note that I did not want to offend
> > anybody by the text above. I just feel personally involved in this
> > port and I wanted to express I care about it. If anybody felt offended
> > - I am sorry and please don't feel this way.
>
> I just hope that you're long enough around to watch and judge
> the trends yourself. I also hope that you'll find interesting to
> listen to experiences of folks who already tried the stuff you suggest
> ;-).
Received on Wed Jun 20 2007 - 17:18:07 EDT
This archive was generated by hypermail 2.2.0 : Wed Jun 20 2007 - 17:18:59 EDT