grub-devel
[Top][All Lists]
Advanced

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

Re: please stop this


From: Vladimir 'phcoder' Serbinenko
Subject: Re: please stop this
Date: Sat, 18 Jul 2009 20:53:44 +0200

>> > 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.
I don't think that grub as a project isn't able to handle incoming
patches. I think that lack of organisation just wastes the effort.
Perhaps we could use some kind of core team approach. One example is
to designate N core team members and need a confirmation of floor
(N/2) core members for design changes and no oppositions and that at
least one weak passed after such consensus and a confirmation of one
core team member for ordinary patches or in case if author is in core
team and no further replies one weak that patch is laying on the list.
This way even if some core members are on vacation the system
continues to work
>
> 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).
>
If he'll be soonish available for discussion we should wait for him
and discuss this altogether.
> I think the "Unified" means it supports multiple filesystems, the Multiboot
> standard, etc, allowing it to support a wide variety of OSes.
Exactly. And if patches have problems to get in we risk not to recieve
features the project merits and gets loads of forks (=fragmentation
instead of unification) instead
>  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.
>
Could we perhaps create a developement branch in svn to share code easier?
> --
> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git




reply via email to

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