General design (was Re: [PATCH] Split of the normal mode)

[phcoder <phcoder@gmail.com>]

If you're here to fix things then it's okay with me. We could start with 
design discussions and have a document describing rules and roadmap. Of 
course it won't be an absolute reference but any step away from roadmap 
is to be discussed thoroughfully
> - Trivial changes, in particular bug fixes, were allowed to be checked in 
> without any review, if the developer is trusted. 
I agree with this way
> - 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' 
> ideas.
> 
IMO now even you would have to let people discuss your changes if they 
aren't trivial. This is because grub2 supports many platforms and 
restructuring may break some platforms in subtle way
> - 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.
This is especially true with all current ports and some people may want 
to delay design changes if some code is pending
> 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 
> demand.
Get me right, I have nothing against these people. Actually I'm very 
grateful to Robert Millan that my patches were incorporated at all. 
However I find current organisation problematic. Perhaps we need another 
collaboration model to avoid such problems in future
> 
> 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.

Every of these changes has to be discussed separately. Some of them may 
lead to design discussions.
> 
> - Many patches are pending.
> 
This is my main complaint.
Also some design disscussion stay without any activity.
> 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.
I think it would be a good idea to have a document describing those 
rules rather than playing "Mao" game.
> 
> Regards,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko