[opensuse-buildservice] Build Service Status
present: ro, mls, froh, tpatzig, abauer, rlihm, adrian, jcborn, poeml * Status * Upstream Project * Source link handling Status: * jcborn: worked on redirector scanner checks now if mirror servers can handle files > 2GB to avoid redirection to mirrors which can not handle DVD iso files. Suggestion to check also for > 4GB size problems. * mls improved speed of scheduler esp. working on Factory. Not active yet. * tpatzig is new trainee in build service team, worked before im mobile devices and KDE team. Start looking into Ruby on Rails. Welcome Tom :) * abauer working on test server instance. Merge request api call exists in svn but is not yet deployed Missing stuff: -> api lacks permission checks. -> no schema check yet. * poeml requested security audith for download redirector helped OpenOffice team to install own redirector for them. Upstream Project: ================= We discussed a proposal to define a project for a package where the next version gets developed. This would be especially usefull for openSUSE:Factory, where everybody (and also our tools) gets a hint who does maintain it usually. This would also obsoleted a seperated review step on merge. The concept is described at: http://en.opensuse.org/Build_Service/Concepts/Upstream_Project However we agreed on * using <maintainedin> instead of <upstreamproject> to avoid confusing with real source upstream. We ask for review or better proposal for the tag from Klaas :) * Suggestion <maintainedin> should also offer to define a package optinally. * open question: How to handle this information for stable distribution branch, like when branching openSUSE:12.3 away from openSUSE:Factory. Source Link: ============ While discussing the source handling itself, what osc should do and so on we figured out some missing features in source link implementation we need: * remove files functionality * add changelog entry (In which relation is this to merge request description ? osc shall support to work on _link file sources directly, but also offer to work on merged sources but submitting the user changes only with a _link later. * The "merge request" should get renamed to "submit request". We did not finish our discussion, so we will follow up by mail an follow up tomorrow together with Klaas. 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
Adrian, didn't you say you would circulate your report for review, before posting it? On Tue, Mar 04, 2008 at 04:23:45PM +0100, Adrian Schröter wrote:
* poeml requested security audith for download redirector
The audit was already done. Successfully.
Source Link: ============
While discussing the source handling itself, what osc should do and so on we figured out some missing features in source link implementation we need:
* remove files functionality * add changelog entry (In which relation is this to merge request description ?
I'm not sure what you mean here; could you clarify a bit, please?
osc shall support to work on _link file sources directly, but also offer to work on merged sources but submitting the user changes only with a _link later.
The open question for me here still is what's the differentiator for the user, compared with working on a copy. Especially since in all cases the user needs to merge the local changes into upstream changes.
* The "merge request" should get renamed to "submit request".
If we all agree on that, I'll go ahead and rename it in the code that I just added. Andreas & Klaas, are you going to rename it in the api code, and in the Wiki as well?
We did not finish our discussion, so we will follow up by mail an follow up tomorrow together with Klaas.
bye adrian
I would appreciate input from our users here. Folks, what do you think about source links, and how would you like to seem them handled by osc? What would you be able to do with them? Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Wednesday 05 March 2008 13:22:46 wrote Dr. Peter Poeml:
Adrian,
didn't you say you would circulate your report for review, before posting it?
I can not remember that I said this.
Source Link: ============
While discussing the source handling itself, what osc should do and so on we figured out some missing features in source link implementation we need:
* remove files functionality * add changelog entry (In which relation is this to merge request description ?
I'm not sure what you mean here; could you clarify a bit, please?
IIRC, Michael said that he wanted to add some functionality in source link support to handled additionaly changelog entries in .changes files better.
osc shall support to work on _link file sources directly, but also offer to work on merged sources but submitting the user changes only with a _link later.
The open question for me here still is what's the differentiator for the user, compared with working on a copy. Especially since in all cases the user needs to merge the local changes into upstream changes.
the user requesting a merge is not the only view, another view is also the owner of the project who receives the merge request. Or quite possible multiple at the same time.
* The "merge request" should get renamed to "submit request".
If we all agree on that, I'll go ahead and rename it in the code that I just added.
Andreas & Klaas, are you going to rename it in the api code, and in the Wiki as well?
We will do so, if we all agree on that new suggestion.
We did not finish our discussion, so we will follow up by mail an follow up tomorrow together with Klaas.
I set up another small internal call about this for tomorrow JFYI. 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 Mittwoch, 5. März 2008, Adrian Schröter wrote:
* add changelog entry (In which relation is this to merge request description ?
I'm not sure what you mean here; could you clarify a bit, please?
IIRC, Michael said that he wanted to add some functionality in source link support to handled additionaly changelog entries in .changes files better. Which changes-file? From a buildservice POV I see no changelogs at all unfortunately. Is there any initiative ongoing and if so, can we hear about the plans?
thanks, 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 Wednesday 05 March 2008 15:02:51 wrote Klaas Freitag:
On Mittwoch, 5. März 2008, Adrian Schröter wrote:
* add changelog entry (In which relation is this to merge request description ?
I'm not sure what you mean here; could you clarify a bit, please?
IIRC, Michael said that he wanted to add some functionality in source link support to handled additionaly changelog entries in .changes files better.
Which changes-file? From a buildservice POV I see no changelogs at all unfortunately. Is there any initiative ongoing and if so, can we hear about the plans?
the usuall and well known .changes file ;) The status quo is that we maintain, in our internal build system, but also in openSUSE:Factory the rpm changelogs via the .changes files. It is no initiative, it is just the current status. I think we all want a successor for this system, however it is not defined and implemented yet. It needs definitive quite some time for getting a new working concept here. 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 Mittwoch, 5. März 2008, Adrian Schröter wrote:
On Wednesday 05 March 2008 15:02:51 wrote Klaas Freitag:
On Mittwoch, 5. März 2008, Adrian Schröter wrote:
* add changelog entry (In which relation is this to merge request description ?
I'm not sure what you mean here; could you clarify a bit, please?
IIRC, Michael said that he wanted to add some functionality in source link support to handled additionaly changelog entries in .changes files better.
Which changes-file? From a buildservice POV I see no changelogs at all unfortunately. Is there any initiative ongoing and if so, can we hear about the plans?
the usuall and well known .changes file ;)
The status quo is that we maintain, in our internal build system, but also in openSUSE:Factory the rpm changelogs via the .changes files. Yes, my sillyness not knowing that we handle the changes file in obs as well. Sorry.
It is no initiative, it is just the current status. I think we all want a successor for this system, however it is not defined and implemented yet. Sure, that was why I asked.
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 Wed, Mar 05, 2008 at 02:12:39PM +0100, Adrian Schröter wrote:
On Wednesday 05 March 2008 13:22:46 wrote Dr. Peter Poeml:
Adrian,
didn't you say you would circulate your report for review, before posting it?
I can not remember that I said this.
I thought so - and you used to do so in the past. I would appreciate it.
Source Link: ============
While discussing the source handling itself, what osc should do and so on we figured out some missing features in source link implementation we need:
* remove files functionality * add changelog entry (In which relation is this to merge request description ?
I'm not sure what you mean here; could you clarify a bit, please?
IIRC, Michael said that he wanted to add some functionality in source link support to handled additionaly changelog entries in .changes files better.
Where "better" means what? Details could be interesting.
osc shall support to work on _link file sources directly, but also offer to work on merged sources but submitting the user changes only with a _link later.
The open question for me here still is what's the differentiator for the user, compared with working on a copy. Especially since in all cases the user needs to merge the local changes into upstream changes.
the user requesting a merge is not the only view, another view is also the owner of the project who receives the merge request. Or quite possible multiple at the same time.
Uhm, what are you talking about? Apparently about someting completely different. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
* The "merge request" should get renamed to "submit request".
If we all agree on that, I'll go ahead and rename it in the code that I just added.
Andreas & Klaas, are you going to rename it in the api code, and in the Wiki as well? Did that, added http://en.opensuse.org/Build_Service/Concepts/Submit_Request
On Mittwoch, 5. März 2008, Dr. Peter Poeml wrote: that obsoletes the Merge Request page and hopefully gives a better overview how the whole system should look like. As always: Feedback is appreciated. 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 Wed, Mar 05, 2008 at 04:55:05PM +0100, Klaas Freitag wrote:
* The "merge request" should get renamed to "submit request".
If we all agree on that, I'll go ahead and rename it in the code that I just added.
Andreas & Klaas, are you going to rename it in the api code, and in the Wiki as well? Did that, added http://en.opensuse.org/Build_Service/Concepts/Submit_Request
On Mittwoch, 5. März 2008, Dr. Peter Poeml wrote: that obsoletes the Merge Request page and hopefully gives a better overview how the whole system should look like.
As always: Feedback is appreciated.
Great, I think that change makes sense. (And altogether, an interesting proposal.) Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Wednesday 05 March 2008 16:55:05 Klaas Freitag wrote:
On Mittwoch, 5. März 2008, Dr. Peter Poeml wrote:
* The "merge request" should get renamed to "submit request".
If we all agree on that, I'll go ahead and rename it in the code that I just added.
Andreas & Klaas, are you going to rename it in the api code, and in the Wiki as well?
Did that, added http://en.opensuse.org/Build_Service/Concepts/Submit_Request that obsoletes the Merge Request page and hopefully gives a better overview how the whole system should look like.
As always: Feedback is appreciated.
Will it also be possible to create a branch on the server without having the client to copy around files? Depending on the number and size of the file that can become an expensive operation, while on the server the overhead is much less. It would also be interesting to have this operation available in a general way, so that you can copy (or move) packages between arbitrary projects, not only to the home:branch projects. This would for example make it easier to create a project for a development version of a stable package, without having to manually copy spec files, etc. It would also be nice to be able to branch without automatically creating a submit request. Otherwise this will be a purely offline feature. But it would be useful to be able work on a branched package a bit on the build service servers (e.g. in the web interface or together with some other people) before submitting it to the original project. -- Cornelius Schumacher <cschum@suse.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed, Mar 05, 2008 at 09:29:39PM +0100, Cornelius Schumacher wrote:
On Wednesday 05 March 2008 16:55:05 Klaas Freitag wrote:
On Mittwoch, 5. März 2008, Dr. Peter Poeml wrote:
* The "merge request" should get renamed to "submit request".
If we all agree on that, I'll go ahead and rename it in the code that I just added.
Andreas & Klaas, are you going to rename it in the api code, and in the Wiki as well?
Did that, added http://en.opensuse.org/Build_Service/Concepts/Submit_Request that obsoletes the Merge Request page and hopefully gives a better overview how the whole system should look like.
As always: Feedback is appreciated.
Will it also be possible to create a branch on the server without having the client to copy around files? Depending on the number and size of the file that can become an expensive operation, while on the server the overhead is much less.
The actual copy is planned to be done on the server side, indeed.
It would also be interesting to have this operation available in a general way, so that you can copy (or move) packages between arbitrary projects, not only to the home:branch projects. This would for example make it easier to create a project for a development version of a stable package, without having to manually copy spec files, etc.
In some way, the functionality you describe is similar to what is possible with linked packages, I think -- with the possible extension of linked package handling to allow seeing actual source files, instead of a _link file. (Whereas it still is represented as linked package plus patch on the server.)
It would also be nice to be able to branch without automatically creating a submit request. Otherwise this will be a purely offline feature. But it would be useful to be able work on a branched package a bit on the build service servers (e.g. in the web interface or together with some other people) before submitting it to the original project.
Yes, agreed. A branching should not lead to a "request" right away - that would be a tad unrealistic. Except for the occasional typo fix, or some real genius ;) Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tuesday 04 March 2008 16:23:45 Adrian Schröter wrote:
However we agreed on * using <maintainedin> instead of <upstreamproject> to avoid confusing with real source upstream. We ask for review or better proposal for the tag from Klaas :)
I would suggest to use <origin/> instead of <maintainedin/>. I also think that this feature becomes much more powerful and useful if it's not only thought in context of externals contributing to Factory, but as a generic branch tracking functionality. It can be very helpful to be able to find out after copying (or branching) projects and/or packages where they came from, i.e. where the original data lives. -- Cornelius Schumacher <cschum@suse.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed, Mar 05, 2008 at 09:40:26PM +0100, Cornelius Schumacher wrote:
On Tuesday 04 March 2008 16:23:45 Adrian Schröter wrote:
However we agreed on * using <maintainedin> instead of <upstreamproject> to avoid confusing with real source upstream. We ask for review or better proposal for the tag from Klaas :)
I would suggest to use <origin/> instead of <maintainedin/>.
We actually considered "origin" in the last buildservice meeting, however it was felt that it is too misleading, souding too much like upstream, which isn't the point in those case. Thus, we settled for maintained_in.
I also think that this feature becomes much more powerful and useful if it's not only thought in context of externals contributing to Factory, but as a generic branch tracking functionality. It can be very helpful to be able to find out after copying (or branching) projects and/or packages where they came from, i.e. where the original data lives.
I think you are right. Thanks for pointing that out. Helps me to see it clearer. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Wednesday 05 March 2008 21:51, Dr. Peter Poeml wrote:
On Wed, Mar 05, 2008 at 09:40:26PM +0100, Cornelius Schumacher wrote:
I would suggest to use <origin/> instead of <maintainedin/>.
We actually considered "origin" in the last buildservice meeting, however it was felt that it is too misleading, souding too much like upstream, which isn't the point in those case. Thus, we settled for maintained_in.
For me "origin" doesn't sound like "upstream". It's a copy which clearly has an origin. If this is origin is the upstream project, a maintained version or something completely different isn't implied and also isn't really relevant. "maintainedin" is a bad choice for two reasons: First it doesn't fit language-wise because it isn't a noun, so trying to use that in context will create awkward sentences (see for example the wiki page where it's already used), and second it implies that its meaning has something to do with maintenance, which actually isn't true. For the Factory use case it might coincidentally be true, that the project you copy from is the one where packages are usually maintained, but in general this isn't the case. The functionality is about copying or branching projects and packages, not if and how these projects and packages are maintained. -- Cornelius Schumacher <cschum@suse.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Mar 06, 2008 at 12:08:46 +0100, Cornelius Schumacher wrote:
On Wednesday 05 March 2008 21:51, Dr. Peter Poeml wrote:
On Wed, Mar 05, 2008 at 09:40:26PM +0100, Cornelius Schumacher wrote:
I would suggest to use <origin/> instead of <maintainedin/>.
We actually considered "origin" in the last buildservice meeting, however it was felt that it is too misleading, souding too much like upstream, which isn't the point in those case. Thus, we settled for maintained_in.
For me "origin" doesn't sound like "upstream". It's a copy which clearly has an origin. If this is origin is the upstream project, a maintained version or something completely different isn't implied and also isn't really relevant.
"maintainedin" is a bad choice for two reasons: First it doesn't fit language-wise because it isn't a noun, so trying to use that in context will create awkward sentences (see for example the wiki page where it's already used), and second it implies that its meaning has something to do with maintenance, which actually isn't true. For the Factory use case it might coincidentally be true, that the project you copy from is the one where packages are usually maintained, but in general this isn't the case. The functionality is about copying or branching projects and packages, not if and how these projects and packages are maintained.
Good points, Cornelius. We might want to use "ancestor" for the location where the package was taken from, and "origin" for the original location where it stems from (considering a series of moves, links, submits, or whatever actions which move stuff around). How about that? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Thu, 6 Mar 2008, Dr. Peter Poeml wrote:
On Thu, Mar 06, 2008 at 12:08:46 +0100, Cornelius Schumacher wrote:
On Wednesday 05 March 2008 21:51, Dr. Peter Poeml wrote:
On Wed, Mar 05, 2008 at 09:40:26PM +0100, Cornelius Schumacher wrote:
I would suggest to use <origin/> instead of <maintainedin/>.
We actually considered "origin" in the last buildservice meeting, however it was felt that it is too misleading, souding too much like upstream, which isn't the point in those case. Thus, we settled for maintained_in.
For me "origin" doesn't sound like "upstream". It's a copy which clearly has an origin. If this is origin is the upstream project, a maintained version or something completely different isn't implied and also isn't really relevant.
"maintainedin" is a bad choice for two reasons: First it doesn't fit language-wise because it isn't a noun, so trying to use that in context will create awkward sentences (see for example the wiki page where it's already used), and second it implies that its meaning has something to do with maintenance, which actually isn't true. For the Factory use case it might coincidentally be true, that the project you copy from is the one where packages are usually maintained, but in general this isn't the case. The functionality is about copying or branching projects and packages, not if and how these projects and packages are maintained.
Good points, Cornelius.
We might want to use "ancestor" for the location where the package was taken from, and "origin" for the original location where it stems from (considering a series of moves, links, submits, or whatever actions which move stuff around).
How about that?
I prefer this. I like this direction. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thursday 06 March 2008 00:08:46 wrote Cornelius Schumacher:
On Wednesday 05 March 2008 21:51, Dr. Peter Poeml wrote:
On Wed, Mar 05, 2008 at 09:40:26PM +0100, Cornelius Schumacher wrote:
I would suggest to use <origin/> instead of <maintainedin/>.
We actually considered "origin" in the last buildservice meeting, however it was felt that it is too misleading, souding too much like upstream, which isn't the point in those case. Thus, we settled for maintained_in.
For me "origin" doesn't sound like "upstream". It's a copy which clearly has an origin. If this is origin is the upstream project, a maintained version or something completely different isn't implied and also isn't really relevant.
"maintainedin" is a bad choice for two reasons: First it doesn't fit language-wise because it isn't a noun, so trying to use that in context will create awkward sentences (see for example the wiki page where it's already used), and second it implies that its meaning has something to do with maintenance, which actually isn't true.
You speak about maintenance in the regard of maintenaining packages of released distros, right ? The field would be used for that as well most likely, but it would need to get changed when branching openSUSE:12.3 from openSUSE:Factory .
For the Factory use case it might coincidentally be true, that the project you copy from is the one where packages are usually maintained, but in general this isn't the case. The functionality is about copying or branching projects and packages, not if and how these projects and packages are maintained.
I think, I am not sure how you use the word "maintained" here. Isn't it also a kind of maintenance when ugrading the package for Factory as well ? The field will not be used for copying or branching, but for finding the group (or single) people who usually do take care about a package. Just that it does it indirectly, by pointing to a project which can self-admin how they work. -- 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 06 March 2008 07:41, Adrian Schröter wrote:
The field will not be used for copying or branching, but for finding the group (or single) people who usually do take care about a package. Just that it does it indirectly, by pointing to a project which can self-admin how they work.
I don't think that indirect functionality is the best criteria for naming fields in an API. I would focus on the technical meaning of this element here and let indirections and self-organized workflows to application logic (or maybe even to user policies). -- Cornelius Schumacher <cschum@suse.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 04 March 2008 16:23:45 Adrian Schröter wrote:
However we agreed on * using <maintainedin> instead of <upstreamproject> to avoid confusing with real source upstream. We ask for review or better proposal for the tag from Klaas :)
I would suggest to use <origin/> instead of <maintainedin/>. As some of you know my weakness to find usefull names I am absolutely open to renames. Go ahead, but please make sure to hold the Wikipage consistent.
I also think that this feature becomes much more powerful and useful if it's not only thought in context of externals contributing to Factory, but as a generic branch tracking functionality. Yes, a generic branch functionality is also nice, not talking about it in
On Mittwoch, 5. März 2008, Cornelius Schumacher wrote: the first place does not mean that we do not want it but that it is not in the focus atm - I am still single core ;-) I agree that a very general branch functionality is cool.
It can be very helpful to be able to find out after copying (or branching) projects and/or packages where they came from, i.e. where the original data lives. I expect that *all* changes to packages are recorded in the history, also branching etc. The history needs to give a clear picture of the whole live of the package.
Thanks for the comments, 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 06 March 2008 09:57, Klaas Freitag wrote:
Yes, a generic branch functionality is also nice, not talking about it in the first place does not mean that we do not want it but that it is not in the focus atm - I am still single core ;-) I agree that a very general branch functionality is cool.
I don't think you need more cores to implement more general branching functionality. The submit request proposal basically already includes that. You just have to make sure that it's still possible to use the feature if you are not working in the specific context of Factory contributions. -- Cornelius Schumacher <cschum@suse.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter -
Boyd Lynn Gerber -
Cornelius Schumacher -
Dr. Peter Poeml -
Klaas Freitag