[opensuse-buildservice] osc features for next milestone
Hi all and esp. Peter and Marcus Hüwe :), I have collected what I think we need in osc for our next milestone in three month. Consider this just as a braindump, please comment what makes sense for you and what not. * local build support of _link packages -> this gets currently blocked by needed modularisation in build IIRC. Peter, please talk directly with Michael how to solve this. * easy setup of _link + patch packages A typical usecase / workflow could be this: - osc co <project> <package> (maybe support even "osc co <package>" and the server decides from where to take the package by default. For instance take libqt4 from KDE:KDE4 project instead of openSUSE:Factory. This would help people responsible for openSUSE:Factory, because changes arrives there consolidated by the official maintainers of these components). - user edits package - osc ci -> server refuses, because no write permission in <project> -> osc offers to create home:<user>/<package> (optionally create temporary project) -> osc creates _link + patch file based on user changes -> osc asks to create a "merge request" (needs to get supported by server first) Except for the "merge request", everything should be possible to get implement without any further server side support. * After OBS server supports "merge request" handling add support for following usecases should be supported: -> list all merge request affecting me (the user) -> list all merge request affecting this or given project -> list all merge request affecting this or given package * merge handling, maybe in this way, just an idea. This would need the support on server side first: # osc mergerequests [--project <project>] [--package <package>] -> osc lists all wanted merge requests with numbers in front # osc merge [--project <project>] [--package <package>] 2 1 5 -> osc applies merge requests number 2, 1 and 5 in this order. -> merge should happen on the server side, because it is the same what the bs_srcserver is doing and we can log what got merged from whom and when. So this command does not need any checkout, however it would be nice to allow this also with checked out packges to avoid the need of [--project <project>] [--package <package>] # osc refusemerge 1 9 -> refuse request number 1 and 9 -> osc should ask for a reason statement and send it to the server # osc mergemove <project> <package> <numbers> -> modify/forward the merge requests to another project/package. This is needed for the case like the openSUSE:Factory owner do want an approval/review from someone/someproject . Peter, where shall we maintain this document, any wiki page or do you prefer a text file in svn ? Or do you want to integrate it into something existing ? There is the merge request document in the wiki, but IIRC we were still discussing it end of the last year. So this is not final yet and will most likely change: http://en.opensuse.org/Build_Service/Concepts/Merge_Request happy new year ! 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
* local build support of _link packages -> this gets currently blocked by needed modularisation in build IIRC. Peter, please talk directly with Michael how to solve this.
* easy setup of _link + patch packages A typical usecase / workflow could be this: - osc co <project> <package> (maybe support even "osc co <package>" and the server decides from where to take the package by default. For instance take libqt4 from KDE:KDE4 project instead of openSUSE:Factory. This would help people responsible for openSUSE:Factory, because changes arrives there consolidated by the official maintainers of these components). - user edits package - osc ci -> server refuses, because no write permission in <project> -> osc offers to create home:<user>/<package> (optionally create temporary project) -> osc creates _link + patch file based on user changes -> osc asks to create a "merge request" (needs to get supported by server first) Except for the "merge request", everything should be possible to get implement without any further server side support. Why? I think the base functionality of creation of the patched package (home:<user>/<package> here), the creation of the _link+patch file and
On Monday 07 January 2008 11:15, Adrian Schröter wrote: Hi, the creation of the merge request should be performned on the server. Interactivity of course has to be on the client, but we do not want to implement the crucial parts above in each and every client again, don't we?
* After OBS server supports "merge request" handling add support for following usecases should be supported: -> list all merge request affecting me (the user) -> list all merge request affecting this or given project -> list all merge request affecting this or given package -> list all requests (not neccessarily only merge requests)
# osc mergemove <project> <package> <numbers> -> modify/forward the merge requests to another project/package. This is needed for the case like the openSUSE:Factory owner do want an approval/review from someone/someproject . Hmm, not sure if I understand that correctly. Wouldn't that rather be handled by something like attaching people to requests, with the idea of "your input is requested on this request"?
There is the merge request document in the wiki, but IIRC we were still discussing it end of the last year. So this is not final yet
WIP 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 Thursday 10 January 2008 10:05:44 wrote Klaas Freitag:
On Monday 07 January 2008 11:15, Adrian Schröter wrote: ...
* easy setup of _link + patch packages A typical usecase / workflow could be this: - osc co <project> <package> (maybe support even "osc co <package>" and the server decides from where to take the package by default. For instance take libqt4 from KDE:KDE4 project instead of openSUSE:Factory. This would help people responsible for openSUSE:Factory, because changes arrives there consolidated by the official maintainers of these components). - user edits package - osc ci -> server refuses, because no write permission in <project> -> osc offers to create home:<user>/<package> (optionally create temporary project) -> osc creates _link + patch file based on user changes -> osc asks to create a "merge request" (needs to get supported by server first) Except for the "merge request", everything should be possible to get implement without any further server side support.
Why? I think the base functionality of creation of the patched package (home:<user>/<package> here), the creation of the _link+patch file and the creation of the merge request should be performned on the server. Interactivity of course has to be on the client, but we do not want to implement the crucial parts above in each and every client again, don't we?
At least the patch generation needs to happen localy for performance reasons. osc may also be able to decide apply to handle the changes differently, for example apply a patch against a spec file + add a patch or use the other _link file magics like <topadd>, <apply> or <add>. Since the server does not have a full copy of the modified source and neither be able to track user actions while creating the patch, it might be better do this in the command line client. I think also the workflow and usecases for creating modified versions in a CLI, a WEB gui or any other interface is quite different. So I think it makes sense to implement this in the client itself. Peter, Andreas, any opinions about that ?
* After OBS server supports "merge request" handling add support for following usecases should be supported: -> list all merge request affecting me (the user) -> list all merge request affecting this or given project -> list all merge request affecting this or given package
-> list all requests (not neccessarily only merge requests)
yes.
# osc mergemove <project> <package> <numbers> -> modify/forward the merge requests to another project/package. This is needed for the case like the openSUSE:Factory owner do want an approval/review from someone/someproject .
Hmm, not sure if I understand that correctly. Wouldn't that rather be handled by something like attaching people to requests, with the idea of "your input is requested on this request"?
Maybe. But you may not want want to see this request anymore, because it is up to others to handle this request (first). So it would be not just be adding someone, it would really redirect/moving the request. A concrete usecase, I have in mind is this: Someone (unknown person, with no given trust visibility) wants to submit a change to kdelibs4 into openSUSE:Factory and Rudi wants not review/handle this himself but by the people in KDE:KDE4 project. So he moves the request and it gets handled by Dirk and Beineri. Later on the KDE:KDE4 project submits their changes anyway to openSUSE:Factory, but in this case the owner of openSUSE:Factory can decide about it on the base how much he trust the owners of KDE:KDE4 project. In this way we can scale better and increase trust in the distro, because people who know the code do incorporate it. But it does not rely on single persons like with the classic one-person-as-maintainer concept. 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
On Monday 07 January 2008 11:15, Adrian Schröter wrote:
here is the merge request document in the wiki, but IIRC we were still discussing it end of the last year. I just updated the wiki to the current state auf discussion, which includes the "generic request" system. Please see
http://en.opensuse.org/Build_Service/Concepts/Merge_Request http://en.opensuse.org/Build_Service/Concepts/Requests http://en.opensuse.org/Build_Service/Concepts/Source_branching 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 Thursday 10 January 2008 16:22:00 wrote Klaas Freitag:
On Monday 07 January 2008 11:15, Adrian Schröter wrote:
here is the merge request document in the wiki, but IIRC we were still discussing it end of the last year.
I just updated the wiki to the current state auf discussion, which includes the "generic request" system. Please see
http://en.opensuse.org/Build_Service/Concepts/Merge_Request http://en.opensuse.org/Build_Service/Concepts/Requests
looks good to me... 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
On Thursday 10 January 2008, Klaas Freitag wrote:
The search URLs are ambiguous:
GET /search/requests/<requesttype>/<username>
GET /search/requests/<requesttype>/<project>
I would add the username as a parameter, so you can do stuff like:
GET /search/requests/<requesttype>?username=<name>
GET /search/requests/<requesttype>/<project>?username=<name>
This could also be extended to use other search criteria.
For changing the request status, why is there a parameter needed when the data
is written with PUT anyway? Or is it meant to be POST? What's the body then?
For deletion the natural way would be to use HTTP DELETE, but this would
imply, that the request is actually deleted. Only marking it as deleted keeps
it around. Do we really need that?
--
Cornelius Schumacher
Hi Cornelius, thanks for reading :)
The search URLs are ambiguous:
GET /search/requests/<requesttype>/<username> GET /search/requests/<requesttype>/<project>
I would add the username as a parameter, so you can do stuff like:
GET /search/requests/<requesttype>?username=<name> GET /search/requests/<requesttype>/<project>?username=<name>
This could also be extended to use other search criteria. Agreed and fixed. Just a little check to see if you're with me ;-)
For changing the request status, why is there a parameter needed when the data is written with PUT anyway? Or is it meant to be POST? What's the body then? I knew that this question will come up and it's a hard one. I understood some articles on that this way: PUT is used to update known ressources, which is the case here. And the parameters are to use if one does not want to send the entire document again in the body but only make the server change the document. As a result the body is empty here. I have to admit that this looks somehow strange to me as well, OTOH it makes sense that nothing could get lost for example in the livecycle if not the whole document is transmitted on update. I leave it the way it was for now but I am open for further discussions. Interesting btw: http://www.elharo.com/blog/software-development/web-development/2005/12/08/p...
For deletion the natural way would be to use HTTP DELETE, but this would imply, that the request is actually deleted. Only marking it as deleted keeps it around. Do we really need that? From my experience from other systems of that kind I would really love to have it. Sometimes it is really nice to find out what happened to a request that is not there.
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
GET /search/requests/<requesttype>/<project>?username=<name> ^^^^^^^^^^^^^^^ Who's that? Probably not the person who changed the livecycle. It's the owner of the request which is not yet reflected in the request data. My first thougth was to add an owner element to the
Hi, while thinking again about this topic, I found another glitch: livecycle tag but that would mean that changing the owner would requrire a new livecycle tag. Is that ok? The owner should probably not neccessarily be only a person but also a project name which results in the maintainer(s) of the project as owner or a "meta" owner like "admin" or such. More thinking required. 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 (3)
-
Adrian Schröter
-
Cornelius Schumacher
-
Klaas Freitag