Dirk Stoecker writes:

One very essential thing I missed in your roadmap. This is i18n and l10n.

[...]

I already had some trouble regarding this topic with main distribution and my own packages so I know this is a major topic.

IIRC, you were told that translations of "official" openSUSE packages are managed in a dedicated suse-i18n directory: https://forgesvn1.novell.com/svn/suse-i18n/trunk/packages Otherwise you are right, we must address this for Build Service packages, too. Generally, for upstream translations I recommend to enhance "intltools" (if not already done) to extract the translatable strings from spec.in, merge them into the .pot, and at "make dist" merge the translations from the .po into the .spec. For openSUSE, thus far we do not want to "bloat" the .spec with translations. -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, 2007-16-10 at 23:48 +0200, Pascal Bleser wrote:

Could you please elaborate a little about your thoughts on version control in the OBS ? Currently there's nothing near version control (not even to mention a distributed one).

Personally, I couldn't read anything related to DVCS between the lines.

Revision control looks like a natural fit for (at least) the following: * easy patch generation (branching) of existing packages. And the following should, I expect, be backed by it: * merge request mechanism * creating interface for viewing existing merge requests and select them * merge handling. And distributed revision control in particular looks useful for: * inter build service connection functionality. That's in addition to the benefits of revision control in general, which many attest and are all but self-evident anyway. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, 2007-17-10 at 10:28 +0200, Michael Schroeder wrote:

On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:

...

Do the improvements listed at http://en.opensuse.org/Build_Service/Roadmap#Milestone_Daffodil_.28Version_1... imply distributed revision control? Many people, myself included, want this very much.

Hmm, this is more a tool issue than something we can do on the build service. The build service currently stores the sources pretty much the same way as git does, except that it uses md5 sums instead of sha1 sums to identify a release (this is for historical reasons). I'm thinking about switching it over to sha1 so that it is compatible to git, but I need to find some spare time for this.

If we could use git (with all of its features, of course) in place of "osc diff", "osc commit", etc., that might be OK, although it seems like more work in the long run than just using revision control in the first place. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, Oct 25, 2007 at 09:27:39AM +0200, Klaas Freitag wrote:

...

On Wed, 2007-17-10 at 10:28 +0200, Michael Schroeder wrote:

...

On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:

...

Do the improvements listed at http://en.opensuse.org/Build_Service/Roadmap#Milestone_Daffodil_.28Vers ion_1.0.29.2C_April_2008 imply distributed revision control? Many people, myself included, want this very much.

Hmm, this is more a tool issue than something we can do on the build service. The build service currently stores the sources pretty much the same way as git does, except that it uses md5 sums instead of sha1 sums to identify a release (this is for historical reasons). I'm thinking about switching it over to sha1 so that it is compatible to git, but I need to find some spare time for this.

If we could use git (with all of its features, of course) in place of "osc diff", "osc commit", etc., that might be OK, although it seems like more work in the long run than just using revision control in the first place. I think that's reasonable and would like to have that for the reasons

On Thursday 25 October 2007 01:08, Michael Wolf wrote: that we do not have to maintain git ourselves, that people of all colour continue to ask "do you use a real source control system?" and we can easily answer 'yes' than and finally that we hopefully benefit from existing tools that set up on git. Hopefully, because I have nothing special in mind. Anybody else?

I am sometimes asked, why osc was written in the first place, and why the existing subversion client was not used. The answer is twofold. 1) A subversion client is not compatible to our similar but "reduced" api, it expects a WebDAV server, with extensions even. 2) hacking the massive codebase of a subversion or even maintaining a branch of it to work with the BS seems like a big task. But at least 50% of osc code is code that has nothing to do with version control (and don't fit into svn), and most of the other 50% (version control specific) are too trivially to implement. Of course, the non-version control parts *could* be implemented in a separate tool. I am sometimes asked, why the BS doesn't offer an api which is compatible to WebDAV. Well, it was designed ground up, why not, and grew to a more complex thing later, I personally see the shortcomings but believe that it would have been more work to use something existing. As the question goes, whether to switch to some distributed version control paradigm (whatever its name), I can't see a projected switch as a pure advantage. On the contary, I believe that there are two parties with different interests: one that prefers the distributed paradigm, and one that prefers the centralized paradigm. I personally think that both approaches make sense. But I know for sure that just as there are people who feel severely hindered by a subversion-like approach, there are others that would hate to work with the git "pile of crap". I estimate that the git addicts are a minority -- but who knows? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Thu, Oct 25, 2007 at 08:24:56AM -0600, Boyd Lynn Gerber wrote:

On Thu, 25 Oct 2007, Dr. Peter Poeml wrote:

...

As the question goes, whether to switch to some distributed version control paradigm (whatever its name), I can't see a projected switch as a pure advantage. On the contary, I believe that there are two parties with different interests: one that prefers the distributed paradigm, and one that prefers the centralized paradigm. I personally think that both approaches make sense. But I know for sure that just as there are people who feel severely hindered by a subversion-like approach, there are others that would hate to work with the git "pile of crap". I estimate that the git addicts are a minority -- but who knows?

I use osc and really like it for what it does. I do like git. I do not think I am an addict, but I find it a lot more useful than svn, when many people are working and modifing the same code base. SVN and GIT each have there strengths and weaknesses. I would like to see git used. I think having git and osc should be able to co-exist.

One (general) thing to consider is that the bar shouldn't be set too high for newcomers. I encounter a surprising number of buildservice users, who don't even use osc, but only the web frontend. I assume that many are not proficient users of SCMs. To me it seems that an svn-like approach might be easier for them to get the grasp, then the distributed approach. It might only due to my own ignorance, of course. Anyway, it doesn't mean that I discourage applying a distributed SCM paradigm to the buildservice. The contrary is true, I think it could be a sane way to couple the internal and external buildsystem together (and others). BTW, I would find it a interesting exercise to look at hg (rather than git) in order to find out whether it can be married with osc somehow, or vice versa. But integration with git would also be possible I guess. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Thursday 25 October 2007, Dr. Peter Poeml wrote:

BTW, I would find it a interesting exercise to look at hg (rather than git) in order to find out whether it can be married with osc somehow, or vice versa. But integration with git would also be possible I guess.

Because of what reasons do you think would be hg more suitable for being used in the context of osc, only because it's also written in Python or are there other reasons as well? -- Cornelius Schumacher --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Fri, 2007-26-10 at 14:13 +0200, Dr. Peter Poeml wrote:

On Fri, Oct 26, 2007 at 10:38:40AM +0200, Cornelius Schumacher wrote:

...

On Thursday 25 October 2007, Dr. Peter Poeml wrote:

...

BTW, I would find it a interesting exercise to look at hg (rather than git) in order to find out whether it can be married with osc somehow, or vice versa. But integration with git would also be possible I guess.

Because of what reasons do you think would be hg more suitable for being used in the context of osc, only because it's also written in Python or are there other reasons as well?

1) for integration reasons -- there should be some potential, although I haven't looked into it. hg and osc are both pretty modular I guess, and at least osc can be imported as a python module, so maybe it is possible to add "osc" commands to hg -- or make osc use native hg storage.

I'd be very happy if we could use hg. Its ui seems sane, etc. For similar reasons (ease of use, correctness, written in python, etc), I'd also be happy if you chose bzr.

2) hg has a single and (supposedly) maintainable codebase, whereas git started out as a myriad of independent tools (that may be a thing of the past, I don't know). Calling external tools all the time and parsing their output gets boring pretty quickly... especially if the tools are not stabilized and are still changed all the time, as seems to happen with git.

In spite of whatever impressions I may have given earlier, I'm no fan of git, even if I do think it'd be an advance over the svn-like parts of osc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thursday 25 October 2007, Dr. Peter Poeml wrote:

I am sometimes asked, why the BS doesn't offer an api which is compatible to WebDAV. Well, it was designed ground up, why not, and grew to a more complex thing later, I personally see the shortcomings but believe that it would have been more work to use something existing.

I think it wouldn't be difficult to add WebDAV support to the build service. Not necessarily the support needed for Subversion, but to make it possible to manage source and control file via WebDAV. It basically would mean to implement support for the PROPFIND method to get access to collections. Most of the rest is already there in the current build service HTTP API. The benefit would be that you could browse the build service in your WebDAV enabled file manager, e.g. in Konqueror, and directly edit files there.

As the question goes, whether to switch to some distributed version control paradigm (whatever its name), I can't see a projected switch as a pure advantage. On the contary, I believe that there are two parties with different interests: one that prefers the distributed paradigm, and one that prefers the centralized paradigm. I personally think that both approaches make sense. But I know for sure that just as there are people who feel severely hindered by a subversion-like approach, there are others that would hate to work with the git "pile of crap". I estimate that the git addicts are a minority -- but who knows?

From what I see the git addicts are a rapidly growing "minority". -- Cornelius Schumacher --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2007-10-23 13:46:16 +0200, Dr. Peter Poeml wrote:

On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:

...

Also, is any sort of offline support in the works? --no-init helps in this regard, but you still need to phone home for every build, which is bad for those of us with slow network connections, and worse when the network goes out. I don't want this nearly as badly as I want to use distributed revision control, though.

Adding an offline mode to osc build shouldn't be a problem. It just needs a commandline switch, and a way to store the last retrieved buildinfo and buildconfig in order to use it again. If someone has an idea how to implement this, it would be very welcome.

Hmm I'm not quite sure if such an --offline feature makes much sense. The packagecachedir (where osc stores the downloaded rpms) has to be always in sync with the "latest buildinfo" file. This is no problem when this package only uses rpms from the "standard" repo (which won't get rebuilded) but if this package uses files from its own project it could be a problem. Example: latest buildinfo.xml (which can be stored in the pac/.osc/ dir): <bdep name="xyz" version="2.2.0" release="4.1" arch="i586" project="abc" repository="openSUSE_10.3" /> packagecachedir: xyz-2.2.0-3.1.i586.rpm => fetching this package from the cachedir will fail because it is out of date/the "buildinfo.xml" is too new. In this case it might be better to use build/lbuild manually instead of using "osc build". Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, 2007-23-10 at 13:46 +0200, Dr. Peter Poeml wrote:

On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:

...

Also, is any sort of offline support in the works? --no-init helps in this regard, but you still need to phone home for every build, which is bad for those of us with slow network connections, and worse when the network goes out. I don't want this nearly as badly as I want to use distributed revision control, though.

Adding an offline mode to osc build shouldn't be a problem. It just needs a commandline switch, and a way to store the last retrieved buildinfo and buildconfig in order to use it again. If someone has an idea how to implement this, it would be very welcome.

No, it doesn't sound hard, although I haven't had a chance to give it a go yet.

We'd need to determine whether --no-init should imply such an offline mode. I think it shouldn't, because --no-init is IMO mainly used to shorten build times, not to work in offline mode.

I think that --no-init and (a hypothetical) --offline are orthogonal. In practice I imagine they'd frequently be used in conjunction, but that's no reason to conflate them. Having said that, once --offline exists, it might be worthwile to add another flag, maybe "--fast" or something, that does combine them. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Friday 26 October 2007 21:24:52 wrote Michael Wolf:

On Tue, 2007-23-10 at 13:46 +0200, Dr. Peter Poeml wrote:

...

On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:

...

Also, is any sort of offline support in the works? --no-init helps in this regard, but you still need to phone home for every build, which is bad for those of us with slow network connections, and worse when the network goes out. I don't want this nearly as badly as I want to use distributed revision control, though.

Adding an offline mode to osc build shouldn't be a problem. It just needs a commandline switch, and a way to store the last retrieved buildinfo and buildconfig in order to use it again. If someone has an idea how to implement this, it would be very welcome.

No, it doesn't sound hard, although I haven't had a chance to give it a go yet.

...

We'd need to determine whether --no-init should imply such an offline mode. I think it shouldn't, because --no-init is IMO mainly used to shorten build times, not to work in offline mode.

I think that --no-init and (a hypothetical) --offline are orthogonal. In practice I imagine they'd frequently be used in conjunction, but that's no reason to conflate them. Having said that, once --offline exists, it might be worthwile to add another flag, maybe "--fast" or something, that does combine them.

right... The problem with --noinit (and also with any --offline) is that changed BuildRequires (either changed spec file or changed project setups) will have no effect. It can puzzle someone, if some changes in the spec file have an effect and others do not have ... So, I think --noinit is a better name, since it shows that some part of processing is skipped. --offline would presume that you have 100% of functionality IMHO. 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 Tuesday 23 October 2007 13:49:08 wrote Dr. Peter Poeml:

On Wed, Oct 17, 2007 at 06:53:41PM +0200, Pascal Bleser wrote:

...

One task that is notably missing is the reorganization of the repositories. Right now it's seriously starting to become a mess, I'm afraid :\

Marcus (Rueckert) mentioned on IRC that is was planned for after the 10.3 release rush phase.

Is it considered too little of a task to be listed on the Roadmap ? ;) (if so, I'd strongly disagree ;))

IMO it should be a task on the roadmap: cleanup of what exists, and creation of a policy how to keep the extent of the (unavaidable) mess reasonable in the future.

IMHO not ... We have now all functionalities to protect against random project creation. It is now an ongoing effort to keep it organized, remove obsolete projects and create new ones at a proper point (or to ask people to cooperate in one project). There should be a bugzilla component for tracking this, I need to find out why it did not appeared ... 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Schröter wrote:

On Wednesday 17 October 2007 18:53:41 wrote Pascal Bleser: [...]

...

One task that is notably missing is the reorganization of the repositories. Right now it's seriously starting to become a mess, I'm afraid :\ [...] Note that it also means discussing and finding guidelines about a few things, most notably: repositories and packages by desktop environment (KDE:*, GNOME:*) or by task (client:messaging, multimedia:photo) ? Or some here and some there, as it is now ? (which is quite suboptimal IMO)

Please keep in mind that the organisation of the projects depends on the wanted build enviroment. Packages/versions which can be reused in the build enviroment or not. Additionaly it does also define the group of people with write access to it.

Not sure the build environment is really a criterion in the current grouping of packages into projects as of now, at least not for most of them. I mean, one of the real questions in terms of organization of the projects and packages is whether to group by "desktop environment" or by "purpose" -- e.g. put kftpgrabber into "KDE:something" or in "filesharing" ?. The build environment is hardly a reason to put kftpgrabber into KDE:Community, as it's pretty much the same target build repositories everywhere (openSUSE_10.3, openSUSE_Factory, etc...), with the notable exception of the repos with the latest Apache (e.g. for Subversion). To me, the choice of where to host a package like kftpgrabber (or kbackup or keep, could be in Archiving:Backup as well) is arbitrary and non-deterministic as of now. Is the user who wants to add access to packages asking for "a file transfer client for KDE" or "a file transfer client" ? Of course, we could also have them aggregated into both. Just that it means more files to rsync for the mirrors. Except if pure repository metadata aggregation is feasible and can be implemented. And write access, dunno. Is it really important that a person has access to server:foo but not to client:foo ? Are some categories more "critical" than others wrt that ? Hardly.

It is NOT intended to setup the projects in a away to make it easier to find packages, this needs to be done via different techniques like the software.o.o/search interface.

It definitely needs to be done then, because currently it's quite difficult for a somewhat less experienced user to find his way into the tangle (dare I say "mess" ;)) of existing repositories. But the Build Service roadmap contains half of the items on the Software Portal roadmap anyway so I guess it will be implemented at some point. Why work together one someone else's ideas, right.

...

As an example, gimp is in GNOME:STABLE, gqview is in multimedia:photo; konversation is in KDE:KDE3, irssi in server:messaging. Oh, yeah, and that's one of my pet peeves (Marcus knows about it ;)): there are some obvious repositories/categories that are missing: - client:messaging - client:mail - client:ftp - system:utilities ... (or move *:irc/* into *:messaging ? merge filesharing and client:ftp as filetransfer ? etc...)

hm, maybe all client:* projects can be put into one ? Hm they have disappeared already ;)

Why put them into one ? Then we can drop most of the subcategories for server:* as well, it's exactly the same situation. As said, it's arbitrary and target repository grouping has nothing to do with the vast majority of the packages as far as I can see, as most are just built against the standard repositories. So what's the substance of your reply, keep it as is ? cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHJZear3NMWliFcXcRAsiTAJ9k6SoL/5N6sxU0ZcRADZDXRRGN0wCfejSS Cd72PIDqiQYw8t2b1epN/wo= =c248 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benji Weber wrote:

On 17/10/2007, Pascal Bleser wrote:

...

Would be great to have IRC/XMPP (or possibly email) notifications of build success and failures.

It would be nice if One could subscribe an arbitrary webservice endpoint to have XML notifications of build completions / repository changes.

A generic webservice still doesn't make a client though. By using XMPP, there would be a wealth of clients to choose from (Jabber). - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHFlA1r3NMWliFcXcRAvSEAJ9W96YHi18zDjCNDLza/3XruuoiXACfUWhc DbcCkf+5JpRhnmQRl5DIHa0= =0mYi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wednesday 17 October 2007 19:12:24 Benji Weber wrote:

On 17/10/2007, Pascal Bleser wrote:

...

Would be great to have IRC/XMPP (or possibly email) notifications of build success and failures.

It would be nice if One could subscribe an arbitrary webservice endpoint to have XML notifications of build completions / repository changes. It already works, TODAY.

The build service produces RSS feeds for all rpm based repositories. It just does not work for the debian ones. -- Amilcar Lucas KDevelop.org webmaster --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hello, on Donnerstag, 18. Oktober 2007, Amilcar do Carmo Lucas wrote:

On Wednesday 17 October 2007 19:12:24 Benji Weber wrote:

...

On 17/10/2007, Pascal Bleser wrote:

...

Would be great to have IRC/XMPP (or possibly email) notifications of build success and failures.

It would be nice if One could subscribe an arbitrary webservice endpoint to have XML notifications of build completions / repository changes.

It already works, TODAY.

The build service produces RSS feeds for all rpm based repositories.

Yes, but only on _successful_ builds. This is what users are interested in. But packagers are usually more interested on notifications of _failed_ builds, and there is currently no notification about them except manually checking in the web interface. (No, I don't consider osc log an option because you have to check every build target.) Regards, Christian Boltz --

Wiedervorlage ;-) Mist. Mein bester Trick ist enttarnt. :-) [> Christian Boltz und Ratti in fontlinge-devel]

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Boltz wrote:

on Donnerstag, 18. Oktober 2007, Amilcar do Carmo Lucas wrote:

...

On Wednesday 17 October 2007 19:12:24 Benji Weber wrote:

...

On 17/10/2007, Pascal Bleser wrote:

...

Would be great to have IRC/XMPP (or possibly email) notifications of build success and failures. It would be nice if One could subscribe an arbitrary webservice endpoint to have XML notifications of build completions / repository changes. It already works, TODAY.

The build service produces RSS feeds for all rpm based repositories.

Yes, but only on _successful_ builds. This is what users are interested in.

But packagers are usually more interested on notifications of _failed_ builds, and there is currently no notification about them except manually checking in the web interface. (No, I don't consider osc log an option because you have to check every build target.)

And btw there's "osc results", "osc prjresults" and "osc bl" to have an overview, view the build logs, etc... In terms of "pulling" build results, all the tools are there and it's working nicely. It's really just about enhancing it by having "pushed" notifications. For packagers, not for users. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHGUp2r3NMWliFcXcRAp63AJ9UmflxgQfJwyj1o+1EHW6uPyO7bwCfRlxG fnRlf2qxUo4w0jU6cPFQN/Y= =o5nh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Pascal Bleser escribió:

Would be great to have IRC/XMPP (or possibly email) notifications of build success and failures.

not only for that ;) but also for commits and project/package/build/description metadata changes. -- "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." --Albert Einstein Cristian Rodríguez R, Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org