Mailinglist Archive: opensuse-buildservice (349 mails)

< Previous Next >
[opensuse-buildservice] Re: merge request concept page from Klaas
  • From: Klaas Freitag <freitag@xxxxxxx>
  • Date: Fri, 30 Nov 2007 11:45:16 +0100
  • Message-id: <200711301145.16552.freitag@xxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups