Bean wrote: > On Sat, Nov 14, 2009 at 3:06 AM, Robert Millan <r...@aybabtu.com> wrote: > >> On Sat, Nov 14, 2009 at 02:12:38AM +0800, Bean wrote: >> >>> But no worry, I've created a fork project BURG that contains some >>> brand-new features, the LUA engine will be added back soon. >>> >> Does that make it any easier than maintaining LUA in grub-extras? >> >> When moving it there, I made it clear [1] that anyone who wishes to work >> on LUA is welcome to use the grub-extras repository for that purpose [1]. >> >> I expected a reply from you, but there was none. >> >> [1] http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00424.html >> > > Hi, > > As I see it, one problem of grub-extra is that it can't be compiled > separately, so user have to setup an environment to build it, which is > not straightforward. Then propose a better system. I don't find any problem with setting GRUB_CONTRIB > And as they have two revision system, this make > it difficult to track previous bug. For example, it's hard to tell > which revision of grub-extra can compile with which main stream > revision. It's always latest-to-latest. And it's how it's done in Debian. > And it's also the question of confidence, I don't see anyone > claim responsibility for grub-extra, it' more like a garbage dump to > me. It's hard to convince others to send patches on something that's > not actively maintained. > The same code wouldn't have recieved more attention if it was in the mainline. You can pretty much say nobody looks into hello/hello.c but is it a reason to tell it garbage. I personally handle grub-extras the same way as GRUB2 Actually the same people that take care of mainline also take care of grub-extras. I also have two new things on the queue for grub-extras: LUKS and gPXE import.
-- Regards Vladimir 'phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
