[opensuse-buildservice] Re: merge request concept page from Klaas
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
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
Am Freitag, 30. November 2007 13:44 schrieb Adrian Schröter:
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 ? 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) name has additional meaning for identification of the request. So it probably should be required. Description might be optional, I also would enforce it.
I wonder why that should hurt. I think if somebody asks to take over a patch, she knows why and probably likes to tell why he did the change. And I do not want to reduce the information on the patch itself because people should not be expected to get all info from reading the patch only.
Would it be still possible to search for all requests, which affect me ? Something like
/requests/branches/*/*/adrian use the search interface: GET /search/requests/merge/<username>
Hm, or drop it complete for /requests/<project> only ? What other request could we have ? Maybe /request/add-user-to-project/<project> ? Yes, or renaming, branching, deleting, whatever. I think we should keep the request namespace open for future extensions.
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
participants (2)
-
Adrian Schröter -
Klaas Freitag