Mailinglist Archive: opensuse-buildservice (339 mails)

< Previous Next >
Re: [opensuse-buildservice] concept for osc handling merge requests
  • From: "Dr. Peter Poeml" <poeml@xxxxxxx>
  • Date: Mon, 10 Mar 2008 13:28:46 +0100
  • Message-id: <20080310122846.GQ8818@xxxxxxx>
On Thu, Mar 06, 2008 at 01:25:23PM -0500, JP Rosevear wrote:

On Tue, 2008-03-04 at 12:37 +0100, Dr. Peter Poeml wrote:
Hi,

I'm thinking about how to implement that planned functionality.

Would it make sense to use it like this?

usage:
osc mergereq create SOURCEPRJ SOURCEPAC DESTPRJ [DESTPAC]
osc mergereq list PRJ [PKG]
osc mergereq user USER
osc mergereq show ID
osc mergereq refuse ID
osc mergereq accept ID

What is ID in this case?

ID is a unique identifier which the backend choses when a new request is
created. The identifiers that I have seen look like simple numbers.

How are multiple mergereq's for the same
package handled? (Maybe we should try to apply all the rdiffs?).

There is no plan for that. As far as I see, a second request could be
a) a new one from a previous submitter, or
b) from someone else, and another source package.

In a), the first request is probably obsoleted by the second one (if it
comes from the same source). Thus, it would be good from my perspective
of a packager to attach a "obsoletes XY" note. Or I could probably go
ahead and delete the request that I created earlier.

In b), the request recipient will probably choose one of the two
requests, or try to apply them subsequently.

Having said that, it might be a good thing if the request stores the
source and target revision id, which identifies the exact source
revision of the time when the request was created. Could come in handy
later.

Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"

SUSE LINUX Products GmbH
Research & Development
< Previous Next >
Follow Ups