Mailinglist Archive: opensuse-buildservice (314 mails)

< Previous Next >
Re: [opensuse-buildservice] osc features for next milestone
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Thu, 10 Jan 2008 10:32:49 +0100
  • Message-id: <200801101032.50090.adrian@xxxxxxx>
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)


# 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.



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

< Previous Next >