From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LnwKr-00045Q-TB for mharc-grub-devel@gnu.org; Sun, 29 Mar 2009 10:50:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LnwKp-000433-VX for grub-devel@gnu.org; Sun, 29 Mar 2009 10:50:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LnwKp-00042K-CB for grub-devel@gnu.org; Sun, 29 Mar 2009 10:50:03 -0400 Received: from [199.232.76.173] (port=42809 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnwKo-000429-Vz for grub-devel@gnu.org; Sun, 29 Mar 2009 10:50:03 -0400 Received: from mail.nexedi.com ([91.121.25.85]:44949 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LnwKo-0007H8-Cr for grub-devel@gnu.org; Sun, 29 Mar 2009 10:50:02 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 9FE6A3D9F7 for ; Sun, 29 Mar 2009 16:49:57 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 29 Mar 2009 23:49:51 +0900 User-Agent: KMail/1.9.10 References: <200903291909.56201.okuji@enbug.org> <200903292155.34578.okuji@enbug.org> <49CF763F.2040305@nic.fi> In-Reply-To: <49CF763F.2040305@nic.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903292349.51566.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: 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 14:50:04 -0000 On Sunday 29 March 2009 22:23:11 Vesa J=E4=E4skel=E4inen wrote: > For both of those projects there are people that are paid to do that > work either directly or indirectly. How it internally affects, I don't > know. > > Anyway... when people are paid to work there is certainly different > driving force behind it. It does not matter if people are paid or not in this discussion, because: =2D even if some people are paid, there are tons of volunteers =2D volunteers are still contributing, although patches are not reviewed qu= ickly > Both of those projects has divided work force dedicated to maintain and > drive enhancements to defined goals. > > Now if we map this to our situation: > > - We are missing what we want to do (eg. roadmap, feature plan) This is somehow intentional, because I believe that volunteers do only what= =20 they want to do anyway. In fact, the TODO list in the wiki has several high= =20 priority items, but they have been pending for a long, long time (e.g.=20 writing a manual). > - What different components should be able to do, eg. design documentatio= n. > > - Use cases what we want to support > > - We don't really have defined responsibilities (expect for maintainers, > and even that can be a bit vague) > > - What is philosophy what kind of work is being accepted and what we > require for patches/commits > > - Systematic software functionality verification (either manual or > automated) > > - If I am not mistaken no-one is being paid to maintain GRUB* or to > develop for. (not so big deal) Only temporarily, as far as I know. For example, some students were paid in= =20 SoC. I was paid for the initial research by IPA (PUPA). > I have tried from time to time enhance some of those... but they seem > not to drive enough interest. Perhaps with better coordination it could > work. > > So perhaps it would be best to form some kind of organization that > defines the goals and then defines responsibilities and backups for > components and tries to drive targeting those goals. Those could be like > though like internal maintainers for specific components. It could be > like bi-monthly meeting to tackle issues on horizon. So you like formalism. I myself like a loose development model. If you have= =20 many active developers, formalism works better, because they start to=20 conflict and consume most of the time for endless discussions, otherwise.=20 But, people appear and disappear frequently in GRUB. Do you really think it= =20 works with GRUB? Some examples... I am involved with GRUB for 10 years, but I sometimes disappear completely = for=20 several months. Then, back again. I think Pavel is also working on GRUB for nearly as long as me, but he work= s=20 from time to time. It looks nearly random to me. Robert seems to be relatively constant these days, but he apparently does n= ot=20 have time to comment on all patches. So, till now, "Do whatever you want to do when you feel that you want to" h= as=20 been the most practical, and legwork has been finished by official=20 maintainers who have some formal responsibility (actually, official=20 maintainers have responsibility only for endorsing the GNU philosophy, but= =20 they have done more than this). Regards, Okuji