On Thu, Jul 16, 2009 at 06:10:48PM +0200, Vladimir 'phcoder' Serbinenko wrote: > > > > Usually, I only go through the trouble of implementing things when it's > > clear they will be merged in some form. But I understand it's not > > the same for everyone. So if I missunderstood, please accept my apology. > In some cases actually implementing something is needed to know > whether it will give an advantage
Agreed, in some cases it helps. > > In any case, this kind of changes need wider consensus, and including the > > maintainers in it. > The problem is that most comments are in the form "maybe I agree maybe > I don't". Such kind of discussions may never result in consensus. > Useful patches lying in bitrot somewhere on the list is unfortunately > something common. We need a better organisation and more dynamism if > we want project to advance. New maintainer can make these changes > happen. And generally I tend to accept a rule "absent person is wrong > and agrees". Not because I don't respect other people but just because > I don't see why project would eternally wait for someone to come by. I > think that main rules are Sane-o-cracy and Do-o-cracy: As long as > choice is sane and expandable doer decides I agree we need better organisation, but I don't think even more dynamism is the answer. Actually I think we've got _more_ dynamism than we can handle (I don't think dynamism is bad, but we have to acknowledge our limits). Some people do lots of work, sometimes things we obviously want, and sometimes design changes that need careful review and analisys. The problem is that our resources to do the latter are not a la par with the amount of contribution we receive. What we have now is that often a single person comes up with an idea that changes GRUB in significant ways, it is proposed, and because we lack the resources to review it it's not reviewed, or only barely so. Then the "absent person is wrong and agrees" rule prevails, change is merged, and we may later find that this is not really what we wanted. Marco's been in Catalonia this week. Last thursday he came to Barcelona and we had some talk about the situation with GRUB. I can assure you that he's concerned about this. He sees this "maintainer's not here so let's do what ever we want" approach as a problem, although it's pretty understandable given the situation (he acknoledges that as well). > > And in general, I think we should hold off from big > > restructuring at this time. Using branches is a good idea IMHO (be it > > "someone's branch" or "pupa2" or whatever). > Having too many branches per developer may prevent GRUB from being > GRand and Unified. I think the "Unified" means it supports multiple filesystems, the Multiboot standard, etc, allowing it to support a wide variety of OSes. But it's just a word anyway... IMO, branches are useful sometimes, because they make it easier to experiment with new things without risk of breaking our core functionality. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
