Mailinglist Archive: opensuse-buildservice (349 mails)

[Adrian Schröter <adrian@xxxxxxx>]

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@xxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx