[opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

newer
[opensuse-buildservice] Build Team...

older
Re: [opensuse-buildservice] Tear...

victor.liu＠nokia.com

6 May 2010 6 May '10

10:18

Hi, I just noticed this feature which I was dealing with in my work. I have the initial trying on this. So I would like to take this feature and publish my codes in short time. Does anyone who has been working on this? Thanks Victor Liu -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Show replies by date

Adrian Schröter

6 May 6 May

13:50

Am Donnerstag, 6. Mai 2010 12:18:56 schrieb victor.liu@nokia.com:

...

Hi,

I just noticed this feature which I was dealing with in my work. I have the initial trying on this. So I would like to take this feature and publish my codes in short time. Does anyone who has been working on this?

Nope. However, I think we should discuss here how the osc syntax should be for a request with multiple actions. It would be great, if you post a proposal here first. thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

victor.liu＠nokia.com

10 May 10 May

02:49

Hi, Yes, we still need some discussion here. At present, if we run osc sr in a project directory, it will create requests as many as packages in the project, and regardless of if there is change for a certain package. So firstly, it should detect if there is any change in every package. If there is no any change, no request will be created, otherwise a single request will be created to include all the changes from all those changed packages. Thus the issue is to identify if there is change from the source package to the destination package. Thanks Victor Liu & Brook Hong -----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Thursday, May 06, 2010 9:51 PM To: opensuse-buildservice@opensuse.org Cc: Liu Victor (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request Am Donnerstag, 6. Mai 2010 12:18:56 schrieb victor.liu@nokia.com:

...

Hi,

I just noticed this feature which I was dealing with in my work. I have the initial trying on this. So I would like to take this feature and publish my codes in short time. Does anyone who has been working on this?

Adrian Schröter

05:38

Am Montag, 10. Mai 2010, 04:49:18 schrieb victor.liu@nokia.com:

...

Hi,

Yes, we still need some discussion here.

At present, if we run osc sr in a project directory, it will create requests as many as packages in the project, and regardless of if there is change for a certain package.

So firstly, it should detect if there is any change in every package. If there is no any change, no request will be created, otherwise a single request will be created to include all the changes from all those changed packages.

Yep, sounds good. (Doing the seperate requests was implemented, because we have problems with one big request with SUSE internal tools. But we need to solve them anyway.).

...

Thus the issue is to identify if there is change from the source package to the destination package.

Hm, maybe just do a rdiff call before. We may can also add an api function which comes back with yes or no, telling if there are changes. Maybe one call for the entire project listing the affected packages. Another thing (what I had in mind originally) was how to specifiy multple actions on command line when creating one request. There can be also no-code relevant requests, like devel_change, add_role or set_bugowner. Just as an example osc create_request "submit openSUSE:Tools/osc openSUSE:Factory" "change_devel openSUSE:Tools/build openSUSE:Factory/build" "delete openSUSE:Factory/build.old" for creating three actions in one request. bye adrian

...

Thanks Victor Liu & Brook Hong

-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Thursday, May 06, 2010 9:51 PM To: opensuse-buildservice@opensuse.org Cc: Liu Victor (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Donnerstag, 6. Mai 2010 12:18:56 schrieb victor.liu@nokia.com:

...
Hi,

I just noticed this feature which I was dealing with in my work. I have the initial trying on this. So I would like to take this feature and publish my codes in short time. Does anyone who has been working on this?

Nope.

However, I think we should discuss here how the osc syntax should be for a request with multiple actions.

It would be great, if you post a proposal here first.

thanks adrian

-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Stephan Kulow

08:07

Am Montag 10 Mai 2010 schrieb victor.liu@nokia.com:

...

Hi,

Yes, we still need some discussion here.

At present, if we run osc sr in a project directory, it will create requests as many as packages in the project, and regardless of if there is change for a certain package.

But that's not the only use case of this feature. Another is "I submit banshee from Banshee project, but this can't be accepted unless the new mono-core from Mono project goes in to", so I create a submit request with two source projects. Your use case is easier to define as osc command line, but mine should be supported too - just I don't know how. Possibly in allowing to append to a submit request? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

brook.hong＠nokia.com

09:08

How about using the below syntax to cover your case as Adrian spoke? osc create_request "submit home:stephan:branches:openSUSE:Factory banshee-1 openSUSE:Factory" "submit home:stephan:branches:Mono mono-core Mono" If I'm not misunderstanding, there are two requirements in this feature. 1. It shall become easy to submit multiple packages within one request with osc. -- this is yours. 2. osc may get also a mode to detect all packages with changes in a certain project and creates one request. -- this is ours. I note that doing separate request was implemented, and if there are problems with one big request, won't it block the implementation of this feature? What kind of problems are they? Speaking of changedevelrequest, there no any change on the package even after the request is accepted. I thought _link file will be changed after the request was accepted, but it didn't. What does changedevelrequest really do? ---------------- Best Regards, Brook Hong -----Original Message----- From: ext Stephan Kulow [mailto:coolo@suse.de] Sent: Monday, May 10, 2010 4:08 PM To: opensuse-buildservice@opensuse.org Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request Am Montag 10 Mai 2010 schrieb victor.liu@nokia.com:

...

Hi,

Yes, we still need some discussion here.

At present, if we run osc sr in a project directory, it will create requests as many as packages in the project, and regardless of if there is change for a certain package.

Adrian Schröter

09:28

Am Montag, 10. Mai 2010, 11:08:56 schrieb brook.hong@nokia.com:

...

How about using the below syntax to cover your case as Adrian spoke? osc create_request "submit home:stephan:branches:openSUSE:Factory banshee-1 openSUSE:Factory" "submit home:stephan:branches:Mono mono-core Mono"

it was just an example, I do not think it makes sense in this way ;) maybe osc create_request -a submit home:stephan:branches:openSUSE:Factory banshee-1 openSUSE:Factory -a submit home:stephan:branches:Mono mono-core Mono to seperate the requests.

...

If I'm not misunderstanding, there are two requirements in this feature. 1. It shall become easy to submit multiple packages within one request with osc. -- this is yours. 2. osc may get also a mode to detect all packages with changes in a certain project and creates one request. -- this is ours.

yep

...

I note that doing separate request was implemented, and if there are problems with one big request, won't it block the implementation of this feature? What kind of problems are they?

The obs server itself can handle it already. We just have inhouse in SUSE private scripts which can't handle them. But this should not be an issue here on the list. I just mentionend it to explain why it was not implemented in the way you suggested in first place.

...

Speaking of changedevelrequest, there no any change on the package even after the request is accepted. I thought _link file will be changed after the request was accepted, but it didn't. What does changedevelrequest really do?

It does add/change the

...

---------------- Best Regards, Brook Hong

-----Original Message----- From: ext Stephan Kulow [mailto:coolo@suse.de] Sent: Monday, May 10, 2010 4:08 PM To: opensuse-buildservice@opensuse.org Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Montag 10 Mai 2010 schrieb victor.liu@nokia.com:

...
Hi,

Yes, we still need some discussion here.

At present, if we run osc sr in a project directory, it will create requests as many as packages in the project, and regardless of if there is change for a certain package.

But that's not the only use case of this feature. Another is "I submit banshee from Banshee project, but this can't be accepted unless the new mono-core from Mono project goes in to", so I create a submit request with two source projects.

Your use case is easier to define as osc command line, but mine should be supported too - just I don't know how. Possibly in allowing to append to a submit request?

Greetings, Stephan

brook.hong＠nokia.com

18 May 18 May

05:46

Hello, I have modified osc/commandline.py to add client support for this feature, below is the detail

...

osc help creq createrequest (creq): create multiple requests with a single command

usage: osc creq [OPTIONS] [ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] -a delete PROJECT [PACKAGE] -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] ] Option -m works for all types of request, the rest work only for submit. example: osc creq -a submit -a delete home:brookhong:branches:openSUSE:Tools -a change_devel openSUSE:Tools osc home:brookhong:branches:openSUSE:Tools -m ok This will submit all modified packages under current directory, delete project home:brookhong:branches:openSUSE:Tools and change the devel project to home:brookhong:branches:openSUSE:Tools for package osc in project openSUSE:Tools. Options: -h, --help show this help message and exit --yes proceed without asking. -d, --diff show diff only instead of creating the actual request --no-update never touch source package on accept (will break source links) --no-cleanup never remove source package on accept, but update its content --cleanup remove package if submission gets accepted (default for home:<id>:branch projects) --nodevelproject do not follow a defined devel project (primary project where a package is developed) -s SUPERSEDE, --supersede=SUPERSEDE Superseding another request by this one -r REV, --revision=REV for "create", specify a certain source revision ID (the md5 sum) -m TEXT, --message=TEXT specify message TEXT -a, --action specify action type of a request, can be : submit/delete/change_devel With command "osc creq -a submit -a delete home:brookhong:branches:hello_test -a change_devel hello_test hello_people home:brookhong:branches:hello_test -m ok", I can create a request successfully which consists of three actions as <request id="39"> <action type="submit"> <source project="home:brookhong:branches:hello_test" package="hello_people" rev="2" /> <target project="hello_test" package="hello_people" /> <options> <sourceupdate>noupdate</sourceupdate> </options> </action> <action type="submit"> <source project="home:brookhong:branches:hello_test" package="hello_world" rev="3" /> <target project="hello_test" package="hello_world" /> <options> <sourceupdate>noupdate</sourceupdate> </options> </action> <action type="delete"> <target project="home:brookhong:branches:hello_test" /> </action> <action type="change_devel"> <source project="home:brookhong:branches:hello_test" package="hello_people" /> <target project="hello_test" package="hello_people" /> </action> <state name="new" who="brookhong" when="2010-05-19T11:05:02" /> <description>ok</description> </request> Here are the code patch, I tried to push into http://gitorious.org/opensuse/osc, seems I have no permission. diff --git a/osc/commandline.py b/osc/commandline.py old mode 100644 new mode 100755 index 98d5844..59a3ee5 --- a/osc/commandline.py +++ b/osc/commandline.py @@ -942,6 +942,322 @@ Please submit there instead, or use --nodevelproject to force direct submission. print 'created request id', result + def actionparser(option, opt_str, value, parser): + value = [] + if not hasattr(parser.values, 'actiondata'): + setattr(parser.values, 'actiondata', []) + if parser.values.actions == None: + parser.values.actions = [] + + rargs = parser.rargs + while rargs: + arg = rargs[0] + if ((arg[:2] == "--" and len(arg) > 2) or + (arg[:1] == "-" and len(arg) > 1 and arg[1] != "-")): + break + else: + value.append(arg) + del rargs[0] + + parser.values.actions.append(value[0]) + del value[0] + parser.values.actiondata.append(value) + + def _submit_request(self, args, opts, options_block): + actionxml="" + apiurl = self.get_api_url() + if len(args) == 0 and is_project_dir(os.getcwd()): + import cgi + # submit requests for multiple packages are currently handled via multiple requests + # They could be also one request with multiple actions, but that avoids to accepts parts of it. + project = store_read_project(os.curdir) + apiurl = store_read_apiurl(os.curdir) + + pi = [] + pac = [] + targetprojects = [] + rdiffmsg = [] + # loop via all packages for checking their state + for p in meta_get_packagelist(apiurl, project): + if p.startswith("_patchinfo:"): + pi.append(p) + else: + # get _link info from server, that knows about the local state ... + u = makeurl(apiurl, ['source', project, p]) + f = http_GET(u) + root = ET.parse(f).getroot() + linkinfo = root.find('linkinfo') + if linkinfo == None: + print "Package ", p, " is not a source link." + sys.exit("This is currently not supported.") + if linkinfo.get('error'): + print "Package ", p, " is a broken source link." + sys.exit("Please fix this first") + t = linkinfo.get('project') + if t: + rdiff = '' + try: + rdiff = server_diff(apiurl, t, p, opts.revision, project, p, None, True) + except: + rdiff = '' + + if rdiff != '': + targetprojects.append(t) + pac.append(p) + rdiffmsg.append("old: %s/%s\nnew: %s/%s\n%s" %(t, p, project, p,rdiff)) + else: + print "Skipping package ", p, " since it has no difference with the target package." + else: + print "Skipping package ", p, " since it is a source link pointing inside the project." + if opts.diff: + print ''.join(rdiffmsg) + sys.exit(0) + + if not opts.yes: + if pi: + print "Submitting patchinfo ", ', '.join(pi), " to ", ', '.join(targetprojects) + print "\nEverything fine? Can we create the requests ? [y/n]" + if sys.stdin.read(1) != "y": + sys.exit("Aborted...") + + # loop via all packages to do the action + for p in pac: + s = """<action type="submit"> <source project="%s" package="%s" rev="%s"/> <target project="%s" package="%s"/> %s </action>""" % \ + (project, p, opts.revision or show_upstream_rev(apiurl, project, p), t, p, options_block) + actionxml += s + + # create submit requests for all found patchinfos + for p in pi: + for t in targetprojects: + s = """<action type="submit"> <source project="%s" package="%s" /> <target project="%s" package="%s" /> %s </action>""" % \ + (project, p, t, p, options_block) + actionxml += s + + return actionxml + + elif len(args) <= 2: + # try using the working copy at hand + p = findpacs(os.curdir)[0] + src_project = p.prjname + src_package = p.name + apiurl = p.apiurl + if len(args) == 0 and p.islink(): + dst_project = p.linkinfo.project + dst_package = p.linkinfo.package + elif len(args) > 0: + dst_project = args[0] + if len(args) == 2: + dst_package = args[1] + else: + dst_package = src_package + else: + sys.exit('Package \'%s\' is not a source link, so I cannot guess the submit target.\n' + 'Please provide it the target via commandline arguments.' % p.name) + + modified = [i for i in p.filenamelist if p.status(i) != ' ' and p.status(i) != '?'] + if len(modified) > 0: + print 'Your working copy has local modifications.' + repl = raw_input('Proceed without committing the local changes? (y|N) ') + if repl != 'y': + sys.exit(1) + elif len(args) >= 3: + # get the arguments from the commandline + src_project, src_package, dst_project = args[0:3] + if len(args) == 4: + dst_package = args[3] + else: + dst_package = src_package + else: + raise oscerr.WrongArgs('Incorrect number of arguments.\n\n' \ + + self.get_cmd_help('request')) + + if not opts.nodevelproject: + devloc = None + try: + devloc = show_develproject(apiurl, dst_project, dst_package) + except urllib2.HTTPError: + print >>sys.stderr, """\ +Warning: failed to fetch meta data for '%s' package '%s' (new package?) """ \ + % (dst_project, dst_package) + pass + + if devloc and \ + dst_project != devloc and \ + src_project != devloc: + print """\ +A different project, %s, is defined as the place where development +of the package %s primarily takes place. +Please submit there instead, or use --nodevelproject to force direct submission.""" \ + % (devloc, dst_package) + if not opts.diff: + sys.exit(1) + + rdiff = None + if opts.diff: + try: + rdiff = 'old: %s/%s\nnew: %s/%s' %(dst_project, dst_package, src_project, src_package) + rdiff += server_diff(apiurl, + dst_project, dst_package, opts.revision, + src_project, src_package, None, True) + except: + rdiff = '' + if opts.diff: + print rdiff + else: + reqs = get_request_list(apiurl, dst_project, dst_package, req_type='submit') + user = conf.get_apiurl_usr(apiurl) + myreqs = [ i for i in reqs if i.state.who == user ] + repl = '' + if len(myreqs) > 0: + print 'You already created the following submit request: %s.' % \ + ', '.join([str(i.reqid) for i in myreqs ]) + repl = raw_input('Supersede the old requests? (y/n/c) ') + if repl.lower() == 'c': + print >>sys.stderr, 'Aborting' + sys.exit(1) + + actionxml = """<action type="submit"> <source project="%s" package="%s" rev="%s"/> <target project="%s" package="%s"/> %s </action>""" % \ + (src_project, src_package, opts.revision or show_upstream_rev(apiurl, src_project, src_package), dst_project, dst_package, options_block+ if repl.lower() == 'y': + for req in myreqs: + change_request_state(apiurl, str(req.reqid), 'superseded', + 'superseded by %s' % result, result) + + if opts.supersede: + r = change_request_state(conf.config['apiurl'], + opts.supersede, 'superseded', '', result) + + #print 'created request id', result + return actionxml + + def _delete_request(self, args, opts): + if len(args) < 1: + raise oscerr.WrongArgs('Please specify at least a project.') + if len(args) > 2: + raise oscerr.WrongArgs('Too many arguments.') + + apiurl = self.get_api_url() + + package = "" + if len(args) > 1: + package = """package="%s" """ % (args[1]) + actionxml = """<action type="delete"> </action> """ % (args[0], package) + return actionxml + + def _changedevel_request(self, args, opts): + if len(args) > 4: + raise oscerr.WrongArgs('Too many arguments.') + + if len(args) == 0 and is_package_dir('.') and len(conf.config['getpac_default_project']): + wd = os.curdir + devel_project = store_read_project(wd) + devel_package = package = store_read_package(wd) + apiurl = store_read_apiurl(wd) + project = conf.config['getpac_default_project'] + else: + if len(args) < 3: + raise oscerr.WrongArgs('Too few arguments.') + + apiurl = self.get_api_url() + + devel_project = args[2] + project = args[0] + package = args[1] + devel_package = package + if len(args) > 3: + devel_package = args[3] + + actionxml = """ <action type="change_devel"> <source project="%s" package="%s" /> <target project="%s" package="%s" /> </action> """ % \ + (devel_project, devel_package, project, package) + + return actionxml + + + #@cmdln.option('-a', '--action', action='append', default = [], + @cmdln.option('-a', '--action', action='callback', callback = actionparser,dest = 'actions', + help='specify action type of a request, can be : submit/delete/change_devel') + @cmdln.option('-m', '--message', metavar='TEXT', + help='specify message TEXT') + @cmdln.option('-r', '--revision', metavar='REV', + help='for "create", specify a certain source revision ID (the md5 sum)') + @cmdln.option('-s', '--supersede', metavar='SUPERSEDE', + help='Superseding another request by this one') + @cmdln.option('--nodevelproject', action='store_true', + help='do not follow a defined devel project ' \ + '(primary project where a package is developed)') + @cmdln.option('--cleanup', action='store_true', + help='remove package if submission gets accepted (default for home:<id>:branch projects)') + @cmdln.option('--no-cleanup', action='store_true', + help='never remove source package on accept, but update its content') + @cmdln.option('--no-update', action='store_true', + help='never touch source package on accept (will break source links)') + @cmdln.option('-d', '--diff', action='store_true', + help='show diff only instead of creating the actual request') + @cmdln.option('--yes', action='store_true', + help='proceed without asking.') + @cmdln.alias("creq") + def do_createrequest(self, subcmd, opts, *args): + """${cmd_name}: create multiple requests with a single command + + usage: + osc creq [OPTIONS] [ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] -a delete PROJECT [PACKAGE] -a change_devel PROJECT PACKAGE DEVEL_PROJECT [+ + Option -m works for all types of request, the rest work only for submit. + example: + osc creq -a submit -a delete home:brookhong:branches:openSUSE:Tools -a change_devel openSUSE:Tools osc home:brookhong:branches:openSUSE:Tools -m+ + This will submit all modified packages under current directory, delete project home:brookhong:branches:openSUSE:Tools and change the devel proje+ ${cmd_option_list} + """ + src_update = conf.config['submitrequest_on_accept_action'] or None + # we should check here for home:<id>:branch and default to update, but that would require OBS 1.7 server + if opts.cleanup: + src_update = "cleanup" + elif opts.no_cleanup: + src_update = "update" + elif opts.no_update: + src_update = "noupdate" + + options_block="" + if src_update: + options_block="""<options><sourceupdate>%s</sourceupdate></options> """ % (src_update) + + args = slash_split(args) + + apiurl = self.get_api_url() + + i = 0 + actionsxml = "" + for ai in opts.actions: + if ai == 'submit': + args = opts.actiondata[i] + i = i+1 + actionsxml += self._submit_request(args,opts, options_block) + elif ai == 'delete': + args = opts.actiondata[i] + actionsxml += self._delete_request(args,opts) + i = i+1 + elif ai == 'change_devel': + args = opts.actiondata[i] + actionsxml += self._changedevel_request(args,opts) + i = i+1 + else: + raise oscerr.WrongArgs('Unsupported action %s' % ai) + if actionsxml == "": + sys.exit('No actions need to be taken.') + + if not opts.message: + opts.message = edit_message() + + import cgi + xml = """<request> %s <state name="new"/> <description>%s</description> </request> """ % \ + (actionsxml, cgi.escape(opts.message or "")) + u = makeurl(apiurl, ['request'], query='cmd=create') + f = http_POST(u, data=xml) + + root = ET.parse(f).getroot() + return root.get('id') + @cmdln.option('-m', '--message', metavar='TEXT', help='specify message TEXT') -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

06:43

Am Dienstag, 18. Mai 2010, 07:46:32 schrieb brook.hong@nokia.com:

...

Hello,

I have modified osc/commandline.py to add client support for this feature, below is the detail

...
osc help creq createrequest (creq): create multiple requests with a single command

usage: osc creq [OPTIONS] [ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] -a delete PROJECT [PACKAGE] -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] ]

Looks good to me. Except that the new request types "set_bugowner" and "add_role" are still missing ;) And I think we need to fix some other places in osc to support request in actions better, esp when showing a request. Currently you do not see the entire truth when doing "osc rq show" to a request with multiple actions Marcus (Hüwe), what do you think about it ? Brook, when you create an account at www.gitorious.org and tell me your account name, I can give you push rights to the osc repository. thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

06:47

Am Dienstag, 18. Mai 2010, 08:43:43 schrieb Adrian Schröter:

...

Am Dienstag, 18. Mai 2010, 07:46:32 schrieb brook.hong@nokia.com:

...
Hello,

I have modified osc/commandline.py to add client support for this feature, below is the detail

...
osc help creq createrequest (creq): create multiple requests with a single command

usage: osc creq [OPTIONS] [ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] -a delete PROJECT [PACKAGE] -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] ]

Looks good to me. Except that the new request types "set_bugowner" and "add_role" are still missing ;)

And I think we need to fix some other places in osc to support request in actions better, esp when showing a request. Currently you do not see the entire truth when doing "osc rq show" to a request with multiple actions

Another thing what comes to my mind is that we should be able to cleanup existing code and use your new functions to have one place to create submit request xml for example. This would have the downside that OBS 1.0 servers can't parse the new request xml anymore (1.5 and later can), but I think this is acceptable with release of OBS 2.0 soon. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

brook.hong＠nokia.com

06:56

...

...
Looks good to me. Except that the new request types "set_bugowner" and "add_role" are still missing ;) Ok, I'll add code support for these soon.

...

...
And I think we need to fix some other places in osc to support request

in actions better, esp when

...
showing a request. Currently you do not see the entire truth when doing "osc rq show" to a request with multiple actions

That's true, will fix.

...

Another thing what comes to my mind is that we should be able to cleanup existing code and use your new functions to have one place to create submit request xml for example.

This would have the downside that OBS 1.0 servers can't parse the new request xml anymore (1.5 and later can), but I think this is acceptable with release of OBS 2.0 soon. Then how about keeping the old commands for compatibility?

My user name at www.gitorious.org is brookhong.

...

bye adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

Adrian Schröter

07:05

Am Dienstag, 18. Mai 2010, 08:56:18 schrieb brook.hong@nokia.com:

...

...
...
Looks good to me. Except that the new request types "set_bugowner" and "add_role" are still missing ;) Ok, I'll add code support for these soon.

great :)

...

...
...
And I think we need to fix some other places in osc to support request

in actions better, esp when

...
showing a request. Currently you do not see the entire truth when doing "osc rq show" to a request with multiple actions

That's true, will fix.

also great :)

...

...
Another thing what comes to my mind is that we should be able to cleanup existing code and use your new functions to have one place to create submit request xml for example.

This would have the downside that OBS 1.0 servers can't parse the new request xml anymore (1.5 and later can), but I think this is acceptable with release of OBS 2.0 soon. Then how about keeping the old commands for compatibility?

I am a bit unsure here. Actually I would suggest that we freeze current osc (and build) packages in openSUSE:Tools:1.7 project and cleanup code in new osc instead. Removed code is best code, because it is bug free and easy to read ;) Marcus, any opinion ?

...

My user name at www.gitorious.org is brookhong.

I have added you there now, but please wait for a comment from Marcus Hüwe about your patch before pushing. thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

brook.hong＠nokia.com

08:52

For the new request types "set_bugowner" and "add_role", the server side is implemented by editing project meta file directly. When running command as --- osc maintainer hello_test -a somebody -r bugowner, no request was generated. I'm wondering if it is sensible to cover these functions in this command. ---------------- Best Regards, Brook Hong

...

-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Tuesday, May 18, 2010 3:06 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Dienstag, 18. Mai 2010, 08:56:18 schrieb brook.hong@nokia.com:

...
...
...
Looks good to me. Except that the new request types "set_bugowner" and "add_role" are still missing ;) Ok, I'll add code support for these soon.

great :)

...
...
...
And I think we need to fix some other places in osc to support

request in actions better, esp when

...
showing a request. Currently you do not see the entire truth when doing "osc rq show" to a request with multiple actions

That's true, will fix.

also great :)

...
...
Another thing what comes to my mind is that we should be able to cleanup existing code and use your new functions to have one place to create submit request xml for example.

This would have the downside that OBS 1.0 servers can't parse the new request xml anymore (1.5 and later can), but I think this is acceptable with release of OBS 2.0 soon. Then how about keeping the old commands for compatibility?

I am a bit unsure here. Actually I would suggest that we freeze current osc (and build) packages in openSUSE:Tools:1.7 project and cleanup code in new osc instead.

Removed code is best code, because it is bug free and easy to read ;)

Marcus, any opinion ?

...
My user name at www.gitorious.org is brookhong.

I have added you there now, but please wait for a comment from Marcus Hüwe about your patch before pushing.

thanks adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

Adrian Schröter

10:59

Am Dienstag, 18. Mai 2010, 10:52:49 schrieb brook.hong@nokia.com:

...

For the new request types "set_bugowner" and "add_role", the server side is implemented by editing project meta file directly. When running command as --- osc maintainer hello_test -a somebody -r bugowner, no request was generated.

Right, but this works only, if you have write access there aka you are already maintainer. The requests are to set you with a role in projects, where you don't have write access (yet). bye adrian

...

I'm wondering if it is sensible to cover these functions in this command.

---------------- Best Regards, Brook Hong

...
-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Tuesday, May 18, 2010 3:06 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Dienstag, 18. Mai 2010, 08:56:18 schrieb brook.hong@nokia.com:

...
...
...
Looks good to me. Except that the new request types "set_bugowner" and "add_role" are still missing ;) Ok, I'll add code support for these soon.

great :)

...
...
...
And I think we need to fix some other places in osc to support

request in actions better, esp when

...
showing a request. Currently you do not see the entire truth when doing "osc rq show" to a request with multiple actions

That's true, will fix.

also great :)

...
...
Another thing what comes to my mind is that we should be able to cleanup existing code and use your new functions to have one place to create submit request xml for example.

This would have the downside that OBS 1.0 servers can't parse the new request xml anymore (1.5 and later can), but I think this is acceptable with release of OBS 2.0 soon. Then how about keeping the old commands for compatibility?

I am a bit unsure here. Actually I would suggest that we freeze current osc (and build) packages in openSUSE:Tools:1.7 project and cleanup code in new osc instead.

Removed code is best code, because it is bug free and easy to read ;)

Marcus, any opinion ?

...
My user name at www.gitorious.org is brookhong.

I have added you there now, but please wait for a comment from Marcus Hüwe about your patch before pushing.

thanks adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

brook.hong＠nokia.com

19 May 19 May

01:50

...

The requests are to set you with a role in projects, where you don't have write access (yet).

Huh, then it does make sense. But I can't find any code related with those requests in the obs api layer. Does it mean that these requests have NOT been implemented on server side? If it does, we need to figure out the requests' xml presentation. May be like <action type="add_role"> <target project="hello_test" package="hello_people" /> <user name="someone" role="bugowner|maintainer"> </action> And set_bugowner can be covered by add_role. Do we need to add a new request type as "remove_role"? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

07:04

Am Mittwoch, 19. Mai 2010, 03:50:07 schrieb brook.hong@nokia.com:

...

...
The requests are to set you with a role in projects, where you don't have write access (yet).

Huh, then it does make sense. But I can't find any code related with those requests in the obs api layer. Does it mean that these requests have NOT been implemented on server side?

If it does, we need to figure out the requests' xml presentation. May be like

Please check docs/api/api/request.xml and docs/api/api/request.xsd There are these examples inside: <action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="adrian" role="maintainer" /> </action> <action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <group name="security-team" role="reviewer" /> </action> <action type="set_bugowner"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="karl-heinz" /> </action>

...

<action type="add_role"> <target project="hello_test" package="hello_people" /> <user name="someone" role="bugowner|maintainer"> </action>

And set_bugowner can be covered by add_role. Do we need to add a new request type as "remove_role"?

set_bugowner is removing all other bugowner entries (because bugzilla can handle only on bugowner). So I decided to have a special request for this to make it more visible that "set" is removing old entries (while "add" makes the impression just to add more). remove_role could get implemented, but so far I heard no request or need for it. Dunno if we have a usecase where it makes sense (when you are maintainer you can remove your entry anyway without a request). bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

brook.hong＠nokia.com

20 May 20 May

03:40

Ok, here will be the new syntax for createrequest. osc creq [OPTIONS] [ \ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] \ -a delete PROJECT [PACKAGE] \ -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] \ -a add_role PROJECT [PACKAGE] -a set_bugowner PROJECT [PACKAGE] ] There is still another question, when a maintainer who already has write access to some project runs this command, will a request also be created for that? Since the action could be done directly, I suggest that no request will be created while with some warning message printed out to notify user. What do you think it? ---------------- Best Regards, Brook Hong

...

-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Wednesday, May 19, 2010 3:04 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

...
...
The requests are to set you with a role in projects, where you don't have write access (yet).

Huh, then it does make sense. But I can't find any code related with

Am Mittwoch, 19. Mai 2010, 03:50:07 schrieb brook.hong@nokia.com: those requests in the obs api layer.

...
Does it mean that these requests have NOT been implemented on server side?

If it does, we need to figure out the requests' xml presentation. May be like

Please check docs/api/api/request.xml and docs/api/api/request.xsd

There are these examples inside:

<action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="adrian" role="maintainer" /> </action> <action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <group name="security-team" role="reviewer" /> </action> <action type="set_bugowner"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="karl-heinz" /> </action>

...
<action type="add_role"> <target project="hello_test" package="hello_people" /> <user name="someone" role="bugowner|maintainer"> </action>

And set_bugowner can be covered by add_role. Do we need to add a new request type as "remove_role"?

set_bugowner is removing all other bugowner entries (because bugzilla can handle only on bugowner). So I decided to have a special request for this to make it more visible that "set" is removing old entries (while "add" makes the impression just to add more).

remove_role could get implemented, but so far I heard no request or need for it. Dunno if we have a usecase where it makes sense (when you are maintainer you can remove your entry anyway without a request).

bye adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

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

Adrian Schröter

04:51

Am Donnerstag, 20. Mai 2010, 05:40:03 schrieb brook.hong@nokia.com:

...

Ok, here will be the new syntax for createrequest.

osc creq [OPTIONS] [ \ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] \ -a delete PROJECT [PACKAGE] \ -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] \ -a add_role PROJECT [PACKAGE]

We have some more roles beside these two and admins can also define their owns. So, this should not be limitted to these both.

...

-a set_bugowner PROJECT [PACKAGE] ]

There is still another question, when a maintainer who already has write access to some project runs this command, will a request also be created for that?

Since the action could be done directly, I suggest that no request will be created while with some warning message printed out to notify user. What do you think it?

Hm, that might not be expected when you running a script using osc. You may still want to have the request in this case. good morning adrian

...

---------------- Best Regards, Brook Hong

...
-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Wednesday, May 19, 2010 3:04 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

...
...
The requests are to set you with a role in projects, where you don't have write access (yet).

Huh, then it does make sense. But I can't find any code related with

Am Mittwoch, 19. Mai 2010, 03:50:07 schrieb brook.hong@nokia.com: those requests in the obs api layer.

...
Does it mean that these requests have NOT been implemented on server side?

If it does, we need to figure out the requests' xml presentation. May be like

Please check docs/api/api/request.xml and docs/api/api/request.xsd

There are these examples inside:

<action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="adrian" role="maintainer" /> </action> <action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <group name="security-team" role="reviewer" /> </action> <action type="set_bugowner"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="karl-heinz" /> </action>

...
<action type="add_role"> <target project="hello_test" package="hello_people" /> <user name="someone" role="bugowner|maintainer"> </action>

And set_bugowner can be covered by add_role. Do we need to add a new request type as "remove_role"?

set_bugowner is removing all other bugowner entries (because bugzilla can handle only on bugowner). So I decided to have a special request for this to make it more visible that "set" is removing old entries (while "add" makes the impression just to add more).

remove_role could get implemented, but so far I heard no request or need for it. Dunno if we have a usecase where it makes sense (when you are maintainer you can remove your entry anyway without a request).

bye adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

brook.hong＠nokia.com

24 May 24 May

02:26

Hello, When I'm going to make change for backend and api server, I found this feature -- https://features.opensuse.org/308759, and its status was done. Also I found relevant code in api server. So I'll just make change for OSC. Is that okay? ---------------- Best Regards, Brook Hong

...

-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Thursday, May 20, 2010 12:51 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Donnerstag, 20. Mai 2010, 05:40:03 schrieb brook.hong@nokia.com:

...
Ok, here will be the new syntax for createrequest.

osc creq [OPTIONS] [ \ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] \ -a delete PROJECT [PACKAGE] \ -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] \ -a add_role PROJECT [PACKAGE]

We have some more roles beside these two and admins can also define their owns. So, this should not be limitted to these both.

...
-a set_bugowner PROJECT [PACKAGE] ]

There is still another question, when a maintainer who already has

write access to some project runs this command, will a request also be created for that?

...
Since the action could be done directly, I suggest that no request

will be created while with some warning message printed out to notify user.

...
What do you think it?

Hm, that might not be expected when you running a script using osc. You may still want to have the request in this case.

good morning adrian

...
---------------- Best Regards, Brook Hong

...
-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Wednesday, May 19, 2010 3:04 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Mittwoch, 19. Mai 2010, 03:50:07 schrieb brook.hong@nokia.com:

...
...
The requests are to set you with a role in projects, where you

don't

...
...
...
...
have write access (yet).

Huh, then it does make sense. But I can't find any code related with those requests in the obs api layer. Does it mean that these requests have NOT been implemented on server side?

If it does, we need to figure out the requests' xml presentation. May be like

Please check docs/api/api/request.xml and docs/api/api/request.xsd

There are these examples inside:

<action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="adrian" role="maintainer" /> </action> <action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <group name="security-team" role="reviewer" /> </action> <action type="set_bugowner"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="karl-heinz" /> </action>

...
<action type="add_role"> <target project="hello_test" package="hello_people" /> <user name="someone" role="bugowner|maintainer"> </action>

And set_bugowner can be covered by add_role. Do we need to add a new request type as "remove_role"?

set_bugowner is removing all other bugowner entries (because bugzilla can handle only on bugowner). So I decided to have a special request for this to make it more visible that "set" is removing old entries (while "add" makes the impression just to add more).

remove_role could get implemented, but so far I heard no request or need for it. Dunno if we have a usecase where it makes sense (when you are maintainer you can remove your entry anyway without a request).

bye adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

Adrian Schröter

25 May 25 May

08:34

Hi Brook, Am Montag, 24. Mai 2010, 04:26:30 schrieb brook.hong@nokia.com:

...

Hello,

When I'm going to make change for backend and api server, I found this feature -- https://features.opensuse.org/308759, and its status was done.

Also I found relevant code in api server. So I'll just make change for OSC. Is that okay?

Yes, would be great. (I implemented these two requests two weeks ago on server side without touching osc yet). bye adrian

...

---------------- Best Regards, Brook Hong

...
-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Thursday, May 20, 2010 12:51 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Donnerstag, 20. Mai 2010, 05:40:03 schrieb brook.hong@nokia.com:

...
Ok, here will be the new syntax for createrequest.

osc creq [OPTIONS] [ \ -a submit SOURCEPRJ SOURCEPKG DESTPRJ [DESTPKG] \ -a delete PROJECT [PACKAGE] \ -a change_devel PROJECT PACKAGE DEVEL_PROJECT [DEVEL_PACKAGE] \ -a add_role PROJECT [PACKAGE]

We have some more roles beside these two and admins can also define their owns. So, this should not be limitted to these both.

...
-a set_bugowner PROJECT [PACKAGE] ]

There is still another question, when a maintainer who already has

write access to some project runs this command, will a request also be created for that?

...
Since the action could be done directly, I suggest that no request

will be created while with some warning message printed out to notify user.

...
What do you think it?

Hm, that might not be expected when you running a script using osc. You may still want to have the request in this case.

good morning adrian

...
---------------- Best Regards, Brook Hong

...
-----Original Message----- From: ext Adrian Schröter [mailto:adrian@suse.de] Sent: Wednesday, May 19, 2010 3:04 PM To: opensuse-buildservice@opensuse.org Cc: Hong Brook (Nokia-D/Beijing) Subject: Re: [opensuse-buildservice] Working on Fate#309351: osc multiple package submit request

Am Mittwoch, 19. Mai 2010, 03:50:07 schrieb brook.hong@nokia.com:

...
...
The requests are to set you with a role in projects, where you

don't

...
...
...
...
have write access (yet).

Huh, then it does make sense. But I can't find any code related with those requests in the obs api layer. Does it mean that these requests have NOT been implemented on server side?

If it does, we need to figure out the requests' xml presentation. May be like

Please check docs/api/api/request.xml and docs/api/api/request.xsd

There are these examples inside:

<action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="adrian" role="maintainer" /> </action> <action type="add_role"> <target project="openSUSE:10.3" package="kraft.old" /> <group name="security-team" role="reviewer" /> </action> <action type="set_bugowner"> <target project="openSUSE:10.3" package="kraft.old" /> <person name="karl-heinz" /> </action>

...
<action type="add_role"> <target project="hello_test" package="hello_people" /> <user name="someone" role="bugowner|maintainer"> </action>

And set_bugowner can be covered by add_role. Do we need to add a new request type as "remove_role"?

set_bugowner is removing all other bugowner entries (because bugzilla can handle only on bugowner). So I decided to have a special request for this to make it more visible that "set" is removing old entries (while "add" makes the impression just to add more).

remove_role could get implemented, but so far I heard no request or need for it. Dunno if we have a usecase where it makes sense (when you are maintainer you can remove your entry anyway without a request).

bye adrian

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

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

--

Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de

5086

Age (days ago)

5105

Last active (days ago)

List overview

Download

19 comments

4 participants

participants (4)

Adrian Schröter
brook.hong＠nokia.com
Stephan Kulow
victor.liu＠nokia.com