On Friday 30 November 2007 11:45:16 wrote Klaas Freitag: ...
what about this version:
<mergerequest creationTS="..."> <source project="home:<person>" package="my_package"/> <destination project="openSUSE:Factory" package="your_package"/> <state>new|declined|accepted|deleted|review</state> <reason> please fix your build first and resubmit ! </reasons> </mergerequest>
Ok, the difference is that there is a source- and a destination tag which is nice. You also propose to not restrict source packages/projects to a special directory which I wrote down initially. That also sounds very reasonable for me now, the reason why I did that initially was that it would make /search/requests/merge/<username> easier.
hm, the interface can stay we just have to support it differently in the backend right ?
Klaas, could you explain the meaning of the name and desc elements?
They have the same meaning as the word 'Klaas' in the sentence above ;o) Everything needs a name, why not a patch proposal? People probably prefer to talk about the "Enable PDF"-Patch for Okular than about the ??? Patch Proposal. And one of the targets of this is to foster talking about these requests I think. Description gives the requester the chance to give some explanation. Name and description are of course "weak" attributes which are usefull for human beings and not so much for needed from a technical POV (beside the name, see below).
so <name> is optional ? Or would I be enforce to fill <name> and <description> always ? (Would more hurt than help IMHO)
Why is the prefix named /request/branches? Wouldn't /request/merge make more sense?
Sure.
GET /request/branches/project and GET /search/branches/project looks to me as they serve the same purpose.
Yes, they do. But I think they should be both there for consistency of the API. And maybe in the future the /search path might be more featurerich like searching with wildcards or so which we probably do not implement for dir listings.
How is a request identified? Is this the name field you propose? How would this name be determined? Shouldn't the request identifier be put into the URI?
Yeah - thats a real good question. The initial proposal only allows one request per package which is probably not what we want.
Why not use the name from above for this? That gives us this URIs /requests/branches/<project>/<package>/<name> for example /requests/branches/KDE4/okular/enable_pdf
Thank you all for taking the time to read and comment :-)
Would it be still possible to search for all requests, which affect me ? Something like /requests/branches/*/*/adrian ? Another thing is that I personally really dislike the /branches part here as well. We just want to merge from package A into B where it is. So I think this should be /requests/merge/ here as well. Hm, or drop it complete for /requests/<project> only ? What other request could we have ? Maybe /request/add-user-to-project/<project> ? bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org