Yoshinori K. Okuji wrote:
On Wednesday 01 April 2009 18:22:46 phcoder wrote:
ok, thanks. Now everything is in savannah task tracker. As for command
list I added important missing commands to task tracker and skipped
not-so-useful ones. As there is some subjectivity involved if you don't
agree wi
On Wednesday 01 April 2009 22:19:00 Robert Millan wrote:
> GRUB is in dire need of an active project lead. I'm happy to see what you
> plan to take back on that role. Over the last few months, I tried to cover
> up for some of the work you and Marco weren't doing, like processing the
> patches no
On Wednesday 01 April 2009 18:22:46 phcoder wrote:
> ok, thanks. Now everything is in savannah task tracker. As for command
> list I added important missing commands to task tracker and skipped
> not-so-useful ones. As there is some subjectivity involved if you don't
> agree with my choice just say
On Sun, Mar 29, 2009 at 07:09:56PM +0900, Yoshinori K. Okuji wrote:
>
> Indeed. I don't understand this tendency about splitting modules at all. What
> is the motivation behind? What is the real benefit for the user?
>
> From my point of view, it is wrong to force the user to manually load
> mo
David Miller wrote:
From: phcoder
Date: Wed, 01 Apr 2009 09:43:01 +0200
Move from todo on wiki is done except UltraSparc.
David Miller: these todos seem to be very outdated by your work. If some of
them or new tasks are applicable could you add them to task tracker?
# Install on disk
# Grub e
From: phcoder
Date: Wed, 01 Apr 2009 09:43:01 +0200
> Move from todo on wiki is done except UltraSparc.
> David Miller: these todos seem to be very outdated by your work. If some of
> them or new tasks are applicable could you add them to task tracker?
> # Install on disk
> # Grub emu
> # Boot s
Move from todo on wiki is done except UltraSparc.
David Miller: these todos seem to be very outdated by your work. If some
of them or new tasks are applicable could you add them to task tracker?
# Install on disk
# Grub emu
# Boot something
# Write a grub-install script to install grub and con
On Tue, 31 Mar 2009 14:11:28 +0800
Bean wrote:
> You're right, LUA is compact yet still powerful, it's quite suitable
> for our purpose. If it's fine with other developers, I can start
> working on it. Oh btw, is the license compatible ?
Lua 5.1 is under the MIT X11 license, which is GPL-compati
On Tue, Mar 31, 2009 at 4:04 AM, Colin D Bennett wrote:
> About the fancy menu support, I hope to pursue getting it finally
> committed soon; I just need to synchronize my graphical menu patch set
> with the current GRUB codebase. I have just been extremely busy until
> now, but I expect to get t
On Sun, 29 Mar 2009 22:10:34 +0900
"Yoshinori K. Okuji" wrote:
> On Sunday 29 March 2009 21:09:05 Bean wrote:
> > 3. Currently, the structure of normal.mod just mix things together to
> > a point that make modification difficult, if not impossible. For
> > example, the current bash script engine
On Tue, Mar 31, 2009 at 12:22 AM, Yoshinori K. Okuji wrote:
> On Tuesday 31 March 2009 00:43:01 Bean wrote:
>> Hi,
>>
>> I see the main objection here is about too many new modules, and the
>> use of script to configure boot process.
>
> I don't object to the latter any longer. Did you read my mes
Bean wrote:
> Also, some thoughts about grub2 authority. I do understand the needs
> to keep source clean and safe for a boot loader, but sometimes the
> process just seems too slow. For example, Colin's graphic menu patch
> has been pending for almost half a year. IMO, if a patch implement a
> gen
On Tuesday 31 March 2009 00:43:01 Bean wrote:
> Hi,
>
> I see the main objection here is about too many new modules, and the
> use of script to configure boot process.
I don't object to the latter any longer. Did you read my message?
> But how about the new
> parser/reader/menu_viewer model ?
N
Once I finish (not a lot remaining) I'll just put a notice in the head
that this page is preserved for historical purposes only and indications
to use savannah
Yoshinori K. Okuji wrote:
On Monday 30 March 2009 05:35:08 phcoder wrote:
I moved todo to the svannah task track.
3 pieces aren't move
On Monday 30 March 2009 05:35:08 phcoder wrote:
> I moved todo to the svannah task track.
> 3 pieces aren't moved yet
> -PPC / Ultrasparc
> -Command list
> -Feature requests by users
Isn't it better to remove the tasks which you moved to Savannah from the wiki?
Regards,
Okuji
__
Hi,
I see the main objection here is about too many new modules, and the
use of script to configure boot process. But how about the new
parser/reader/menu_viewer model ? If I put them back in one
normal.mod, but keep the parts separated in source, would that be
acceptable ?
Also, some thoughts ab
On Monday 30 March 2009 00:17:59 Bean wrote:
> >> But how to store the parameters ? Boot media is not available, so we
> >> can't read file, and we can't embed them in code.
> >
> > Could you be more specific? What case are you talking about?
>
> For example, something the boot modules can't detect
I agree. Developers should feel that their work is appreciated.
Otherwise they turn to something else. THis is especially true for
opensource where the only holding factor is the motivation
David Miller wrote:
From: "Yoshinori K. Okuji"
Date: Sun, 29 Mar 2009 21:55:34 +0900
On Sunday 29 Mar
I moved todo to the svannah task track.
3 pieces aren't moved yet
-PPC / Ultrasparc
-Command list
-Feature requests by users
phcoder wrote:
Yoshinori K. Okuji wrote:
> I wish your help on this.
Ok. You have it. Just at the moment I'm quite busybut in 2 weeks I'll be
more available
--
Regar
From: Vesa Jääskeläinen
Date: Sun, 29 Mar 2009 16:23:11 +0300
> Yoshinori K. Okuji wrote:
> > On Sunday 29 March 2009 20:40:17 David Miller wrote:
> >> Everybody is too busy to give this project the attention and time it
> >> deserves to be maintained properly.
> >>
> >> I honestly do not think t
From: "Yoshinori K. Okuji"
Date: Sun, 29 Mar 2009 21:55:34 +0900
> On Sunday 29 March 2009 20:40:17 David Miller wrote:
> > From: "Yoshinori K. Okuji"
> > Date: Sun, 29 Mar 2009 20:29:26 +0900
> >
> > > So if nobody else can, I would like to get it straight again myself,
> > > although I am pret
Yoshinori K. Okuji wrote:
> I wish your help on this.
Ok. You have it. Just at the moment I'm quite busybut in 2 weeks I'll be
more available
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.
Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 22:23:11 Vesa Jääskeläinen wrote:
>> 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,
On Sun, Mar 29, 2009 at 10:54 PM, Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 23:30:48 Bean wrote:
>> > If you use a label, label support should be loaded automatically.
>> > If you use an uuid, uuid support should be loaded automatically.
>> > If you set up a network, network support shou
On Sunday 29 March 2009 23:30:48 Bean wrote:
> > If you use a label, label support should be loaded automatically.
> > If you use an uuid, uuid support should be loaded automatically.
> > If you set up a network, network support should be loaded automatically.
> >
> > So I see no reason to stop aut
On Sunday 29 March 2009 22:00:05 phcoder wrote:
> Yes, it's perfect
>
> > For very small, trivial patches, I will fix the problem by giving the
> > write permission to you.
> >
> > For complex or big patches, I recommend that you use the bug tracker on
> > Savannah. I know that not many people use
On Sunday 29 March 2009 22:23:11 Vesa Jääskeläinen 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 b
On Sun, Mar 29, 2009 at 10:20 PM, Yoshinori K. Okuji wrote:
>> >> 2, Speaking of linux, it's actually doing the same thing. The kernel
>> >> is in vmlinuz, while the initialization script is in initrd.img. We
>> >> don't want the user to enter those commands manually, a default
>> >> boot.cfg shou
On Sunday 29 March 2009 22:59:53 Bean wrote:
> On Sun, Mar 29, 2009 at 9:10 PM, Yoshinori K. Okuji wrote:
> > On Sunday 29 March 2009 21:09:05 Bean wrote:
> >> Hi,
> >>
> >> Some of my consideration about splitting of normal mode.
> >>
> >> 1, In some environment, we have size limit of the boot im
On Sun, Mar 29, 2009 at 9:10 PM, Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 21:09:05 Bean wrote:
>> Hi,
>>
>> Some of my consideration about splitting of normal mode.
>>
>> 1, In some environment, we have size limit of the boot image.
>> Normal.mod is too big, and rescue mode has too litt
Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 20:40:17 David Miller wrote:
>> Everybody is too busy to give this project the attention and time it
>> deserves to be maintained properly.
>>
>> I honestly do not think the situation will change significantly until
>> someone is able to devote re
On Sunday 29 March 2009 21:09:05 Bean wrote:
> Hi,
>
> Some of my consideration about splitting of normal mode.
>
> 1, In some environment, we have size limit of the boot image.
> Normal.mod is too big, and rescue mode has too little functionality.
> Using the split method, we could combine modules
Yes, it's perfect
For very small, trivial patches, I will fix the problem by giving the write
permission to you.
For complex or big patches, I recommend that you use the bug tracker on
Savannah. I know that not many people use it, but putting patches on the
mailing list is not quite convenien
On Sunday 29 March 2009 20:40:17 David Miller wrote:
> From: "Yoshinori K. Okuji"
> Date: Sun, 29 Mar 2009 20:29:26 +0900
>
> > So if nobody else can, I would like to get it straight again myself,
> > although I am pretty busy (as I have a startup company, can you
> > imagine how tough it is?).
>
Vesa Jääskeläinen wrote:
> Yoshinori K. Okuji wrote:
>> Any objection?
>
> Not really. I will make some grief, but it might be a good thing in overall.
Just to make it clear:
It will... ;)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.g
Hi,
Some of my consideration about splitting of normal mode.
1, In some environment, we have size limit of the boot image.
Normal.mod is too big, and rescue mode has too little functionality.
Using the split method, we could combine modules in anyway we wanted.
2, Speaking of linux, it's actuall
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, we
On Sunday 29 March 2009 20:33:48 phcoder wrote:
> I agree when it's about big changes. I wouldalso not commit anything
> what isn't quite tested or may break something. But when one-line
> bugfixes stay uncommited during 2-3 weaks it's something that isn't
> quite ok. Also if noone comments a relat
From: "Yoshinori K. Okuji"
Date: Sun, 29 Mar 2009 20:29:26 +0900
> So if nobody else can, I would like to get it straight again myself,
> although I am pretty busy (as I have a startup company, can you
> imagine how tough it is?).
Everybody is too busy to give this project the attention and time
On Sunday 29 March 2009 19:48:45 Vesa Jääskeläinen wrote:
> Yoshinori K. Okuji wrote:
> > You should select compile-time "loading" (i.e. linking) whenever
> > possible. If a function is loaded eventually, it should be linked at
> > compile time.
> >
> > You should select automatic loading, if you n
I agree when it's about big changes. I wouldalso not commit anything
what isn't quite tested or may break something. But when one-line
bugfixes stay uncommited during 2-3 weaks it's something that isn't
quite ok. Also if noone comments a relatively small patch in 1-2 weeks I
think we should con
On Sunday 29 March 2009 19:43:33 phcoder wrote:
> I'm actually quite unhappy with the grub's authority in general. Some
> people can commit their patches after a week of no replies while others
> like me have to wait that someone has time to review their patches in
> depth. I already have a collect
Here I must comment that in some cases it is favorable to do it this
way. I personally will only commit changes that I am happy to live with.
Even if you are developer with SVN commit rights it is in some cases
good idea to have general review of the patch... but there has been some
lack of the tim
Yoshinori K. Okuji wrote:
> You should select compile-time "loading" (i.e. linking) whenever possible. If
> a function is loaded eventually, it should be linked at compile time.
>
> You should select automatic loading, if you need runtime linking.
>
> Manual loading should be considered evil, in
I'm actually quite unhappy with the grub's authority in general. Some
people can commit their patches after a week of no replies while others
like me have to wait that someone has time to review their patches in
depth. I already have a collection of patches that are not commited, not
because so
On Sunday 29 March 2009 18:40:16 Vesa Jääskeläinen wrote:
> Bean wrote:
> > Hi,
> >
> > This patch split the function of normal mode into small modules, here
> > is a summary:
> >
> > 1, Move dynamic command loader to commands/dyncmd.c (dyncmd.mod)
> > 2, Move automatic fs loader to fs/autofs.c (au
Bean wrote:
> Hi,
>
> This patch split the function of normal mode into small modules, here
> is a summary:
>
> 1, Move dynamic command loader to commands/dyncmd.c (dyncmd.mod)
> 2, Move automatic fs loader to fs/autofs.c (autofs.mod)
> 3, Split normal mode into three major parts:
> parser/normal
47 matches
Mail list logo
