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