On Thu, Jul 16, 2009 at 5:23 PM, Robert Millan<r...@aybabtu.com> wrote: > On Wed, Jul 15, 2009 at 02:17:39AM +0800, Bean wrote: >> On Wed, Jul 15, 2009 at 2:09 AM, Pavel Roskin<pro...@gnu.org> wrote: >> > On Tue, 2009-07-14 at 19:57 +0200, Robert Millan wrote: >> > >> >> I agree that we have a problem due to lack of leadership, but this is not >> >> acceptable. Marco is busy right now (traveling), so please put this on >> >> hold >> >> untill he's back, then we can discuss it. >> > >> > I agree that we should not rush with such changes. However, publishing >> > patches for discussion and testing is a good thing and should not be >> > discouraged. >> >> Hi, >> >> Yeah, I don't mean to push it. In fact, I've created a git repository >> for my temporary work >> >> http://repo.or.cz/w/grub2/bean.git > > Hi, > > 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 > > 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 > 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. > > -- > 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 >
-- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
