Hi, this is a followup on a discussion about package merge requests that slipped inside accidentially, sorry for that. It discusses the first draft of the concept here:
http://en.opensuse.org/Build_Service/Concepts/Merge_Request I already updated the wiki page according to the discussion in this mail.
[adrian & abauer wrote:]
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.
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).
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 :-) regards, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org