[Top][All Lists]

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

Re: [PATCH 1/2] RFT: Eliminate Apple specific code from boot/i386/pc/bo

From: Pavel Roskin
Subject: Re: [PATCH 1/2] RFT: Eliminate Apple specific code from boot/i386/pc/boot.S
Date: Thu, 13 Aug 2009 01:21:13 -0400

On Thu, 2009-07-16 at 18:31 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Jul 16, 2009 at 5:47 AM, Pavel Roskin<address@hidden> wrote:
> > ChangeLog:
> >
> >        * boot/i386/pc/boot.S: Remove all code dependent on APPLE_CC.
> >        Use local labels starting with "L_" so that Apple assembler
> >        would know they are local.
> You have really a lot of patches.

I don't think so.

> It's undoubtly a good thing but
> since I was on vacation I lost a track a bit. For casual viewers I
> suppose it's even worse. Perhaps you could create a git repository
> which would hold all patches you haven't committed yet, one per
> branch?

I'm sorry, I don't have time to create any private repositories.  I wish
I could do it, but I couldn't find time from that for almost a month, so
chances are it won't happen any time soon.

> It will make a much better overview. Bean created a mirror on
> github. Perhaps we can use it as a tool to have an easily-viewable
> list of all unmerged patches and prevent patches from get lost. I know
> it's really unfortunate that I come up with a proposition of using
> such system for a relatively small project like grub. Alternatively we
> may want to formulate rules which would prevent future developpement
> deadlocks.

There are ways to apply patches from e-mail.  STGit can do it.

My concern is that we would make the submitters responsible for
something other than the quality of the patch if we require them to
create private repositories.  Normally, a patch is good as long as it
applies.  With a private repository, it will need to be kept up-to-date
with the master repository, otherwise testing might find already fixed

As for the deadlocks, I don't think it's a technical issue.

In any case, I find myself submitting too many patches, I'm ready to
reconsider, but right now I cannot create any private repositories.

Pavel Roskin

reply via email to

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