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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
