From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lntg2-0004Af-Jr for mharc-grub-devel@gnu.org; Sun, 29 Mar 2009 07:59:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lntfx-00046s-NM for grub-devel@gnu.org; Sun, 29 Mar 2009 07:59:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lntfs-00046J-Kg for grub-devel@gnu.org; Sun, 29 Mar 2009 07:59:40 -0400 Received: from [199.232.76.173] (port=40059 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lntfs-00046D-Fq for grub-devel@gnu.org; Sun, 29 Mar 2009 07:59:36 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:22501) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lntfr-0006PF-Tl for grub-devel@gnu.org; Sun, 29 Mar 2009 07:59:36 -0400 Received: by fg-out-1718.google.com with SMTP id l27so187306fgb.7 for ; Sun, 29 Mar 2009 04:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=oXEUoWPomLDbRevyIZ/G2kmtJIZsuhIXsazNkpWkfZk=; b=otFSMXlRGD2+ntEyvCKp1yOytsPY3DUNsxBTofy5Au++AQBlblW5YJpfC0GDC+SSxF bnIc3VRPDklCPjmh8ohrKuWNkRzVleBJOdpPeYYhLqu8yY6ue69El8BSU1X9CT+mbrKs 1+q7F8XkXknU3cR6NUaePSukcMot0Ym7X+9GA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=nptoO52h2qcCJZSGJSzAUeeYyCU1dZwyTZuB4rBu5wwbbmuVUuf19mgD/CurrpcZSk m2/fByvxiB3vO6HXup2tn7miev9ieMESPRxe2R7GiWg5X5lez8QPPp5P26+5ridASUab RtqMEpOMZI5axhJcOS7MwlDHzQCStroyC2CrY= Received: by 10.86.68.1 with SMTP id q1mr1689990fga.22.1238327974945; Sun, 29 Mar 2009 04:59:34 -0700 (PDT) Received: from ?192.168.1.25? (242-90.62-81.cust.bluewin.ch [81.62.90.242]) by mx.google.com with ESMTPS id e20sm2563081fga.19.2009.03.29.04.59.34 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Mar 2009 04:59:34 -0700 (PDT) Message-ID: <49CF62AC.7090001@gmail.com> Date: Sun, 29 Mar 2009 13:59:40 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <200903291909.56201.okuji@enbug.org> <49CF50D5.4060308@gmail.com> <200903292029.26967.okuji@enbug.org> In-Reply-To: <200903292029.26967.okuji@enbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: General design (was Re: [PATCH] Split of the normal mode) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 11:59:42 -0000 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