grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Split of the normal mode


From: Vesa Jääskeläinen
Subject: Re: [PATCH] Split of the normal mode
Date: Sun, 29 Mar 2009 16:23:11 +0300
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 20:40:17 David Miller wrote:
>> Everybody is too busy to give this project the attention and time it
>> deserves to be maintained properly.
>>
>> I honestly do not think the situation will change significantly until
>> someone is able to devote real time as a maintainer and process all of
>> the patches that get submitted each day.
> 
> This is ideal but not absolutely required. If you look at some popular 
> projects, such as Linux and Firefox, you can find out that not all (actually, 
> very few) patches are handled so quickly, but those projects are functioning 
> so well.

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.

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)

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

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]