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

[Pavel Roskin <proski@gnu.org>]

On Thu, 2009-07-16 at 18:31 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Jul 16, 2009 at 5:47 AM, Pavel Roskin<proski@gnu.org> 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
problems.

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.

-- 
Regards,
Pavel Roskin