gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Arch Roadmap Draft (the anticipated part 3)


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] Arch Roadmap Draft (the anticipated part 3)
Date: Thu, 1 Jul 2004 22:59:17 +0100
User-agent: Mutt/1.5.6+20040523i

On Thu, Jul 01, 2004 at 01:58:46PM -0700, Tom Lord wrote:
>      One example is the very ad hoc way that we exchange
>      patches, even when we're using arch for that exchange.
>      It would currently be impossible (just because we're
>      sloppy and inconsistent about patch submission) to 
>      do something obvious and useful like set up a browser
>      that can show all of the changes that are in the 
>      Bug Goo queue.

And the only blocking prerequisite on this is:

>   1. We need a standard for how to submit changes.

I have most of the other pieces either in mind or on hand. My current
low-level plan is to have something like
address@hidden/tla-merges--merge-xx--0 be a
copy of the merge. What I don't have is an method for submitters to
describe how to construct that branch, or any really good ideas about
how to do it. Everything is stuck until this is solved. Solutions need
to consider what 'tla submit' (or whatever) is going to do, because it
needs to generate these.

I think that this is the right way to approach the problem - given
those branches, we can construct most anything else on top of it (like
throw a browser at the category). It's always possible to construct
the change directly from the merge request - but most of the time you
just replay from the relevant branch.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

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