[opensuse-buildservice] ANN: osc release
Hi, I released a new osc package yesterday. The main change is a rewritten internal HTTP handling, which doesn't only make the code cleaner (no more extra methods for PUT and DELETE), but also brings about a performance improvement. The delay which was caused by repetitive iChain authentication in the background is virtually eliminated, by keeping the session cookie on disk. Operations which do a series of HTTP requests, like "osc update" in a project directory, were 5 times faster in my tests. Note that the package builds are not finished for all targets yet, because the buildservice is still quite busy. The next thing I'm targetting is a cleanup of the commandline handling, which should make further work on osc significantly easier. Which is why I'm deferring other small changes until that has been accomplished. Be assured that patches and ideas contributed to this list are not forgotten! Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development
On Friday, 20. April 2007 12:14:09 Dr. Peter Poeml wrote:
but also brings about a performance improvement.
Just wanted to say: I love it. :-) Bye, Steve --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
on Fri, Apr 20, 2007 at 12:14:09PM +0200, Dr. Peter Poeml wrote:
The next thing I'm targetting is a cleanup of the commandline handling, which should make further work on osc significantly easier. Which is why I'm deferring other small changes until that has been accomplished. Be assured that patches and ideas contributed to this list are not forgotten!
And here's the next release. Yesterday, I tackled the commandline handling. It is now powerful enough to make extensions real easy. Commands, options and their documentation are defined in a single place. I already added some new features. rebuildpac got a --failed option. status got a -v option. -H enables HTTP debugging, which remains crucial for myself anyway. But the most significant (for some people at least) user-visible change is that osc is now easier to work with when using alternative API servers. The configured server can be overriden with -A <url> on the commandline. "apisrv" in the config also takes a URL now, so the variable "scheme", which was needed before, becomes obsolete. For backward compatibility, a hostname (and scheme variable) are accepted like before. Likewise, the auth sections in the config take a URL now, or a hostname:port to keep old config working. HTTP or HTTPS scheme is determined from the URL. Credentials must be configured in .oscrc. Further thoughts: It would be trivial now to implement a copy subcommand which could copy packages from one buildservice instance to another one. I am thinking about allowing to use an alternative syntax for commands which take PROJECT and PACKAGE as arguments, so one could write PROJECT/PACKAGE. This would make copy and paste much easier. This could be extended to use (pseudo-) URLs even, like http://apisrv/PROJECT/PACKAGE. This again would be handy when implementing copy or diff across buildservice instances. Would this seem useful to anyone? Thanks. Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development
On Wednesday 25 April 2007 6:52 pm, Dr. Peter Poeml wrote:
But the most significant (for some people at least) user-visible change is that osc is now easier to work with when using alternative API servers. The configured server can be overriden with -A <url> on the commandline. "apisrv" in the config also takes a URL now, so the variable "scheme", which was needed before, becomes obsolete. For backward compatibility, a hostname (and scheme variable) are accepted like before. Likewise, the auth sections in the config take a URL now, or a hostname:port to keep old config working. HTTP or HTTPS scheme is determined from the URL. Credentials must be configured in .oscrc.
It would be nice if osc could store the api server when checking out a project. That way you would only have to specify it on checkouts, like CVS or Subversion. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
James Oakley wrote:
It would be nice if osc could store the api server when checking out a project. That way you would only have to specify it on checkouts, like CVS or Subversion.
You were faster than me :-). I would love such feature. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Apr 26, 2007 at 03:48:10PM +0200, Michal Marek wrote:
James Oakley wrote:
It would be nice if osc could store the api server when checking out a project. That way you would only have to specify it on checkouts, like CVS or Subversion.
You were faster than me :-). I would love such feature.
Excellent suggestion :-) This also calls for a 'switch [--relocate]' subcommand, similar to what svn offers, I guess. Thanks, Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development
Hello, on Mittwoch, 25. April 2007, Dr. Peter Poeml wrote:
I am thinking about allowing to use an alternative syntax for commands which take PROJECT and PACKAGE as arguments, so one could write PROJECT/PACKAGE. This would make copy and paste much easier.
Indeed. I'd like to add another feature request: if PROJECT and PACKAGE are not given, the values should be determinated from the current directory. Example / usecase: I'm in the directory where I checked out package foo from project bar - which is known to osc when doing "osc up" or "osc commit". Now I want to edit the metadata of this package and call "osc editmeta". The result is "missing argument". Instead, I have to type "osc editmeta bar foo" Expected behaviour: take the project and package name from the current directory (as already done with "up" and "commit"). This would save lots of needless typing. Regards, Christian Boltz -- ...........why use Windows, if there is a door............. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Apr 26, 2007 at 11:13:48PM +0200, Christian Boltz wrote:
I'd like to add another feature request: if PROJECT and PACKAGE are not given, the values should be determinated from the current directory.
Example / usecase:
I'm in the directory where I checked out package foo from project bar - which is known to osc when doing "osc up" or "osc commit". Now I want to edit the metadata of this package and call "osc editmeta". The result is "missing argument". Instead, I have to type "osc editmeta bar foo"
Expected behaviour: take the project and package name from the current directory (as already done with "up" and "commit"). This would save lots of needless typing.
I have been thinking about this several times, but didn't come to a conclusion yet. It wouldn't fit all subcommands equally well. A disadvantage would be, that for some subcommands, which take more than those two arguments, like osc rebuildpac PROJECT [PACKAGE [PLATFORM [ARCH]]] it will become (at the least) confusing, if osc has to guess what to do. Of course, the current inconsitencies of subcommand implementation need be fixed. For example, osc results [PACDIR] which requires a checked out package, versus osc rebuildpac PROJECT [PACKAGE [PLATFORM [ARCH]]] which works purely remote. I think what I fancy most is to put server-only subcommands into a separate command, named e.g. osc-remote. That command would principally require a project and package argument, and behave identically otherwise. I think this would be more convenient than adding commandline switches that modify the behaviour. Would that be reasonable? svn makes this distinction based on whether URLs or local paths are given as arguments. I'm not sure we want to do the same, I find to <prj> <package> arguments easier to use than a full url. Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development
Hello, on Freitag, 27. April 2007, Dr. Peter Poeml wrote:
On Thu, Apr 26, 2007 at 11:13:48PM +0200, Christian Boltz wrote:
I'd like to add another feature request: if PROJECT and PACKAGE are not given, the values should be determinated from the current directory.
Example / usecase:
I'm in the directory where I checked out package foo from project bar - which is known to osc when doing "osc up" or "osc commit". Now I want to edit the metadata of this package and call "osc editmeta". The result is "missing argument". Instead, I have to type "osc editmeta bar foo"
Expected behaviour: take the project and package name from the current directory (as already done with "up" and "commit"). This would save lots of needless typing.
I have been thinking about this several times, but didn't come to a conclusion yet.
It wouldn't fit all subcommands equally well.
A disadvantage would be, that for some subcommands, which take more than those two arguments, like osc rebuildpac PROJECT [PACKAGE [PLATFORM [ARCH]]] it will become (at the least) confusing, if osc has to guess what to do.
Not if you _always_ assume that a command is for the package in the current directory ;-) - but I see the problem. Another idea: You could at least allow the syntax osc rebuildpac . which would take project and package from the current directory. Not perfect, but it would save typing until you splitted osc and osc-remote.
Of course, the current inconsitencies of subcommand implementation need be fixed. For example, osc results [PACDIR] which requires a checked out package, versus osc rebuildpac PROJECT [PACKAGE [PLATFORM [ARCH]]] which works purely remote.
I think what I fancy most is to put server-only subcommands into a separate command, named e.g. osc-remote. That command would principally require a project and package argument, and behave identically otherwise. I think this would be more convenient than adding commandline switches that modify the behaviour.
Would that be reasonable?
Sound like a good idea - but osc should still offer these commands for checked out packages. So: - osc rebuild [PLATFORM [ARCH]] for the (checked out) package in the current directory (or project if the current directory contains a whole project) - osc-remote rebuild PROJECT [PACKAGE [PLATFORM [ARCH]]] for all other cases Regards, Christian Boltz -- Das terrorsicherste Verkehrsmittel ist ganz klar das Automobil. Einzeln verpackte Verkehrsteilnehmer in Stahlhülle mit großen Abständen. :) [Kristian Köhntopp auf http://blog.koehntopp.de/archives/1376-Mach-mir-den-Rail-Marshall.html] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Christian Boltz -
Dr. Peter Poeml -
James Oakley -
Michal Marek -
Stephan Binner