grub-devel
[Top][All Lists]
Advanced

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

Re: please stop this


From: Robert Millan
Subject: Re: please stop this
Date: Sat, 18 Jul 2009 20:15:32 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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."




reply via email to

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