[Top][All Lists]

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

Re: [PATCH] Split of the normal mode

From: Yoshinori K. Okuji
Subject: Re: [PATCH] Split of the normal mode
Date: Sun, 29 Mar 2009 20:29:26 +0900
User-agent: KMail/1.9.10

On Sunday 29 March 2009 19:43:33 phcoder wrote:
> I'm actually quite unhappy with the grub's authority in general. Some
> people can commit their patches after a week of no replies while others
> like me have to wait that someone has time to review their patches in
> depth. I already have a collection of patches that are not commited, not
> because someone objects against them but just because nobody qualified
> enough has time to review and commit it. All this despite having already
> signed copyright assignment which because of slowness of FSF took more
> time than it should. From developer viewpoint it's very frustrating
> experience. If I wasn't so motivated as I am I would have already given
> up. IMO opinion if we want people coding for grub2 this has to be
> changed. But now you come and say you want to revert some patches just
> because they seem useless to you or rewrite some code just because you
> find it ugly or because it has a minor bug which could be easily fixed
> without rewriting. IMO this can easily drive developers to fork or leave
> project altogether. And additionally your energy would be much better
> spent in writing new stuff and making/reviewing design propositions than
> rewriting chunks of already working code.
> Sorry for being somewhat rude but I really find it frustrating this
> coder-unfriendliness

No problem. I am very glad to hear your honest opinion.

Since you are relatively new to this project, I would like to describe how it 
*was" when I or Marco was very active:

- Trivial changes, in particular bug fixes, were allowed to be checked in 
without any review, if the developer is trusted. Generally, I tend to trust 
all people who have the write permission. Just like in real life, trust may 
not be built instantly; it must be harvested gradually by showing what you do 
and what you don't do.

- Rather significant changes, even bug fixes when these require code 
restructuring, had to be reviewed. I think I was the only exception on this, 
because I am the designor. In reality, however, even I often posted messages 
to this mailing list before I made changes, because I appreciated others' 

- Design-level changes had to be always discussed a lot before being accepted. 
This included myself, because even I, the original author, didn't know every 
aspect of impacts.

These rules were adopted, partly because GRUB was very much in wide use, so we 
should not break our software, including compatibility issues. In particular, 
user-visible changes must be treated very carefully, because we may not 
simply get rid of them, once they are incorporated, otherwise we will make 
millions of machines in the world unbootable.

Afterwards, these rules were somehow forgotten for a practical reason: patches 
were not reviewed quickly or even ignored for a long time, because of the 
absense of leadership. I expected that we could overcome such a situation by 
co-maintainership, but after both I and Marco got too busy with other things, 
it stopped working. As you should know, several people, like Robert, Vesa, 
Pavel, and Bean, helped greatly, but it was not still good enough for your 

So the current situation is like this:

- Many changes have already been incorporated without proper reviews, 
including bad changes. The current GRUB is in a sense partly worse than 
before, due to this.

- Many patches are pending.

- Contributors work very randomly, because nobody shows what we should do and 
what we should not.

So if nobody else can, I would like to get it straight again myself, although 
I am pretty busy (as I have a startup company, can you imagine how tough it 

So, the first thing I would like to do is to remind people of the check-in 
rules, and apply them to past changes. Since a new version is not released 
yet (after things got bad), we can still fix up the bad pieces safely. If we 
miss this occasion, we will have to struggle with badly implemented features 
for years due to compatibility. I have experienced this enough with GRUB 
Legacy. I don't want it again. Otherwise, I wouldn't have made GRUB 2.


reply via email to

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