Re: Manifesto

From: Marcus Brown <marcusbrutus_at_internode.on.net>
Date: Thu, 21 Jun 2007 23:28:58 +1000

Paul Sokolovsky wrote:
> Hello Michal,

[massive snip]

>
>> I want to work on that status page to help assuring that the port is
>> well prepared for next familiar release.
>
> Gotcha! Nice plan! But then again, you really should try to
> work closer with Familiar maintainers, to make sure that results of
> your work are easily reusable for next Familiar release.
>

I believe that I understand the point that each of you are making.
However, both of you need to find a way of breaching the gap between
maintainer/developer and user for this conversation to be productive.
 From Paul's perspective, perhaps Michal's suggestion is naive, and
from Michal's perspective Paul's is too complicated? As Michal has
suggested previously I'm convinced you can find middle ground.

[another snip]

>
> If speak about QA, I (from my point of view) think that thing
> which needs most QA is kernel. Just because it's core part of Linux
> system, and because there're many kernels - for each device, so formal
> testing is highly needed. kernel-discuss consequently is a good place
> to discuss it.
>

QA would be a nice thing to have throughout all distros, but we have to
start somewhere. ATM the best efforts have probably been at the kernel
level simply because that's where committed developers tend to migrate.
Eventually, this methodology should migrate up the chain and developers
at ALL levels will be able to contribute to QA projects. However, atm
there is no such structure, so I would suggest that a QA approach is
something that should be a goal for all levels. However, going from
"email complaints" vs "developer questions", to QA in one step is a
fantasy IMHO. This is something that needs work from both ends.
The hardest point here is that as a user becomes more experienced, he
becomes less aware of the issues that a newbie will encounter ...
points that a developer would possibly consider trivial.

>> I just would like it be be in the wiki -- so that everybody willing to
>> help could do that. I will try to sketch something tonight....
>
> Sure, and no hurries with this...
>
>

>>> 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.

I'd suggest there are more "LEVELS" than you can imagine, and it's not
just "experience" based, but "involvement", "community" and so on.
It would be nice to imagine a feedback system that is usable AND useful
by ALL levels. I do not believe there is any such system in place.

[snip personal conversation]

>
>>> 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 ;-).
>
>> I agree - it is still on my mind- but I don't feel like developer but
>> as "more experienced" user, especially of h2200. But of course I do
>> see all the unification processes and understand the reasons why do
>> they take place (ie. defconfigman).

Please remember that the h2200, in a way, was the flagship for the 2.6
kernel effort on handhelds. From that point of view, also being an
"early adopter" and a "consumer product" means that the h2200 is/was
uniquely positioned to be the most likely device for support, AND the
most likely device to have a multitude of willing Linux participants.
I do not consider ANY of the lessons learnt on the h2200 port & list
to be "owned" by the h2200-port, but rather as a means to an end for
Linux on handhelds in general.

>
>>> 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?
>>>
>
>> Everybody has to start with something:) I feel the need of correcting
>> the familiar for h2200 - because I experienced the bugs by myself. But
>> without this feeling I would probably not do much at hh.org projects.
>
> Again, nice approach. Worth mixing more with Familiar people
> then. For example, Pawel Kolodziejski, h1910 maintainer, does own
> interim releases just like you want to do. Paul Eggleton works on
> adding/testing Opie 1.2.3 support in Familiar, etc. familiar-devel and
> opie-devel are good lists to discuss that, I guess.
>

Paul, forgive the phrase, but you are attempting to drag Michal up (or
down!;) to your level, which misses his previous points about users,
developers and maintainers ... and their respective levels of involvement.
Forcing Michal to become more "development oriented" would suggest that
he loses his "user" perspective ... which I think is his real point.

TBH, I had actually tried to bridge this gap a little with RamdiskRescue,
however, I've not been able to keep up with the number of machines,
requests, and possibilities to actually be able to achieve the idealistic
view of "two levels" (aka. user vs developer) ... although it seems
possible AFAICT.

>> As it goes for Linux-on-PDA:
>> I guess that we all (users and developers) have a big problem here.
>> Familiar has a limited number of developers and the releases take
> place every >>12 months. This 12 months is a lot of time in PDA
>> business. Let's look at the h2200 example - I remember the first notes
>> on Koens page about h2200 being supported by Linux in 2004 (or 2005 -
>> I don't remember exactly). It was already some time after it was
>> released by HP. Now we have A.D. 2007 - and the current status - for
>> users - has not changed much since last 12 months. We have almost the
>> same number of bugs in the port like we had in rc1 (please don't kill
>> me for that - I do remember that the number of them was reduced until
>> 0.8.4 ) and the port (as seen by users) is still not ready for
>> everyday use. If there's anybody willing to argue about that with me -
>> install the latest official release of famliar (0.8.4) and give it to
>> a any girl to test it. Girls are very practical for judging
>> functionality....

You have committed two sins in that paragraph, both of which will remain
unnamed, but one of which involves sexism! :)

>> In general - the market/hardware is growing rapidly and the project is
>> moving with it's own speed.... We have pda's being (slowly) pushed out
>> of the market by phone+pda combos while not every (I don't want to
>> judge the state of other ports) (old) pda's running familiar linux are
>> not everyday user ready.
>
> Familiar has other aims, like stability and security. Drawback
> is that it's like Debian stable - not up with the fresh releases. If you
> want more fresh, or to be exact, bleeding edge, there's OE.dev, which
> changes and updates at high pace. Just to remind, this pace was one
> of the reason that Familiar chose to fork own codease for stability.

It may help to mention here Debian, and the difference between stable,
testing and unstable. To date, Familiar is not mature(?) or populous(?)
enough to maintain that many branches, but from a theoretical point of
view could probably be considered as the 'stable' level, compared to the
others (IMHO).

>
>> I would like to express that there is a need for more elastic release
>> schedule - even the unofficial one. I can imagine who hard it is to
>> maintain official and unofficial distros, but I believe that it is a
>> way of cooperation between users and developers.
>> But this bring some positive effects too. As an example I will write
>> about my how I met Gerhard. He found (I don't know how:D ) my page
>> with unofficial kernel release fixing the buttons problems. He had
>> problem with the feed so he mailed me, we had a long chat about the
>> h2200 port status, the kernel-discuss mailing list and now he is
>> taking active part in h2200 kernel development.
>
> Yes, this is really great and good confirmation of our efforts
> - that new people come.

More frequent releases implies good feedback with many+varied developers.
(among other things)

>
>> I guess more similar forms of communication are needed and would have
>> many more positive effects.
>

Agreed. Let's move into the new age! ;)

>
>>> 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
>>> ;-).
>
>> Paul - of course I will - especially from such an active/experienced
>> person as You:)
>> But I worry about the hh.org , h2200 port status, being handled by
>> developers and for developers, while the real users and their needs
>> are moved to the second place.
>
> You really should try to push Familiar then ;-)
>
>

Congrats to both on your combination of patronising statements.
I am sure if you persevere with BOTH your agendas you will see common
ground, and a method whereby ALL parties are satisfied.

Marcus.

ps. Let me know if/when any of the lessons you learn can be applied
in RamdiskRescue as "hotfixes" ;)

pps. this mail was added to on an ad-hoc basic over a period of time,
and due to time restrictions, was poorly checked for coherency! ;))
YMMV!! ;)
Received on Thu Jun 21 2007 - 09:29:14 EDT

This archive was generated by hypermail 2.2.0 : Thu Jun 21 2007 - 09:29:35 EDT