Re: [PATCH] Split of the normal mode

["Yoshinori K. Okuji" <okuji@enbug.org>]

On Sunday 29 March 2009 22:23:11 Vesa Jääskeläinen wrote:
> For both of those projects there are people that are paid to do that
> work either directly or indirectly. How it internally affects, I don't
> know.
>
> Anyway... when people are paid to work there is certainly different
> driving force behind it.

It does not matter if people are paid or not in this discussion, because:

- even if some people are paid, there are tons of volunteers
- volunteers are still contributing, although patches are not reviewed quickly

> Both of those projects has divided work force dedicated to maintain and
> drive enhancements to defined goals.
>
> Now if we map this to our situation:
>
> - We are missing what we want to do (eg. roadmap, feature plan)

This is somehow intentional, because I believe that volunteers do only what 
they want to do anyway. In fact, the TODO list in the wiki has several high 
priority items, but they have been pending for a long, long time (e.g. 
writing a manual).

> - What different components should be able to do, eg. design documentation.
>
> - Use cases what we want to support
>
> - We don't really have defined responsibilities (expect for maintainers,
> and even that can be a bit vague)
>
> - What is philosophy what kind of work is being accepted and what we
> require for patches/commits
>
> - Systematic software functionality verification (either manual or
> automated)
>
> - If I am not mistaken no-one is being paid to maintain GRUB* or to
> develop for. (not so big deal)

Only temporarily, as far as I know. For example, some students were paid in 
SoC. I was paid for the initial research by IPA (PUPA).

> I have tried from time to time enhance some of those... but they seem
> not to drive enough interest. Perhaps with better coordination it could
> work.
>
> So perhaps it would be best to form some kind of organization that
> defines the goals and then defines responsibilities and backups for
> components and tries to drive targeting those goals. Those could be like
> though like internal maintainers for specific components. It could be
> like bi-monthly meeting to tackle issues on horizon.

So you like formalism. I myself like a loose development model. If you have 
many active developers, formalism works better, because they start to 
conflict and consume most of the time for endless discussions, otherwise. 
But, people appear and disappear frequently in GRUB. Do you really think it 
works with GRUB?

Some examples...

I am involved with GRUB for 10 years, but I sometimes disappear completely for 
several months. Then, back again.

I think Pavel is also working on GRUB for nearly as long as me, but he works 
from time to time. It looks nearly random to me.

Robert seems to be relatively constant these days, but he apparently does not 
have time to comment on all patches.

So, till now, "Do whatever you want to do when you feel that you want to" has 
been the most practical, and legwork has been finished by official 
maintainers who have some formal responsibility (actually, official 
maintainers have responsibility only for endorsing the GNU philosophy, but 
they have done more than this).

Regards,
Okuji