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