Re: [opensuse-packaging] New packages for factory
Am Montag 10 August 2009 schrieb Andrew Beekhof:
Since you seem to be the contact person then, can you please give me an update for the two packages I submitted? There are no problems with them. I don't plan to post daily updates for all submitted packages, if there is a problem I'll notify the packager.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, Aug 10, 2009 at 2:28 PM, Stephan Kulow<coolo@suse.de> wrote:
Am Montag 10 August 2009 schrieb Andrew Beekhof:
Since you seem to be the contact person then, can you please give me an update for the two packages I submitted? There are no problems with them. I don't plan to post daily updates for all submitted packages, if there is a problem I'll notify the packager.
Yes, entirely unreasonable of people to want some feedback on their work after two weeks of silence. Good luck building a community with that attitude. Do you really expect people to put up with nonsense like this if they're not being paid to? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday 10 August 2009 16:40:41 Andrew Beekhof wrote:
Yes, entirely unreasonable of people to want some feedback on their work after two weeks of silence.
"two weeks of silence" is a bit strange definition for the timespan of 6.07 days between your earlier submitrequest (16609) and your question (2 of them being weekend). In that 4.07 work days we managed to build and release a milestone 5, checked in 315 packages, several of them new packages. And then you come along and ask for "your two packages" - which is of course completely reasonable to expect everyone to know which "two packages" you refer to and when I go and dig out your submitrequests and tell you that everything is fine about them, you tell me names. Sure, entirely reasonable! [last sentense intentionally left empty] Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2009-08-10T14:27:02, Stephan Kulow <coolo@suse.de> wrote:
In that 4.07 work days we managed to build and release a milestone 5, checked in 315 packages, several of them new packages. And then you come along and ask for "your two packages" - which is of course completely reasonable to expect everyone to know which "two packages" you refer to and when I go and dig out your submitrequests and tell you that everything is fine about them, you tell me names. Sure, entirely reasonable!
I guess this unreasonableness can be somewhat explained by a lack of transparency. To flog that dead horse again, if this was tracked in bugzilla, everyone could see who is looking at the request etc, without needing to flood a mailing list. To be honest, something like suse-dist will _never_ scale to openSUSE; it didn't even scale when we were just a closed company. Regards, Lars -- Architect Storage/HA, OPS Engineering, Novell, Inc. SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag 11 August 2009 schrieb Lars Marowsky-Bree:
On 2009-08-10T14:27:02, Stephan Kulow <coolo@suse.de> wrote:
In that 4.07 work days we managed to build and release a milestone 5, checked in 315 packages, several of them new packages. And then you come along and ask for "your two packages" - which is of course completely reasonable to expect everyone to know which "two packages" you refer to and when I go and dig out your submitrequests and tell you that everything is fine about them, you tell me names. Sure, entirely reasonable!
I guess this unreasonableness can be somewhat explained by a lack of transparency.
To flog that dead horse again, if this was tracked in bugzilla, everyone could see who is looking at the request etc, without needing to flood a mailing list.
Oh right, because we all know that "two weeks of silence" is _nothing_ when it comes to bugzilla. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 11 August 2009 13:31:37 Stephan Kulow wrote:
Am Dienstag 11 August 2009 schrieb Lars Marowsky-Bree:
On 2009-08-10T14:27:02, Stephan Kulow <coolo@suse.de> wrote:
In that 4.07 work days we managed to build and release a milestone 5, checked in 315 packages, several of them new packages. And then you come along and ask for "your two packages" - which is of course completely reasonable to expect everyone to know which "two packages" you refer to and when I go and dig out your submitrequests and tell you that everything is fine about them, you tell me names. Sure, entirely reasonable!
I guess this unreasonableness can be somewhat explained by a lack of transparency.
To flog that dead horse again, if this was tracked in bugzilla, everyone could see who is looking at the request etc, without needing to flood a mailing list.
Oh right, because we all know that "two weeks of silence" is _nothing_ when it comes to bugzilla.
But it would be clear who owns the task and documented what is done so far (if at all). I think the objection here is that his is a black box and people don't know what's happening, transparency should help here, Andreas -- Andreas Jaeger, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi, On Tue, 11 Aug 2009, Andreas Jaeger wrote:
Oh right, because we all know that "two weeks of silence" is _nothing_ when it comes to bugzilla.
But it would be clear who owns the task and documented what is done so far (if at all).
I think the objection here is that his is a black box and people don't know what's happening, transparency should help here,
If hermes were working as designed we would have that. The problem with Bugzilla is that you have to actively enter something to show activity, in addition to the activity itself. So, if coolo looks at a SR and deems it fine, "but not for right now", he would additionally enter comments in random bugzilla entries. Or better, he wouldn't, and rightfully so, because his time is limited. That would lead to the same questions, so bugzilla in itself wouldn't help. Something automatic would help, as repeatedly suggested by various people (hi Lars :) ), but then it doesn't matter anymore if it was called hermes or bugzilla. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 11 August 2009 13:44:36 Michael Matz wrote:
Hi,
On Tue, 11 Aug 2009, Andreas Jaeger wrote:
Oh right, because we all know that "two weeks of silence" is _nothing_ when it comes to bugzilla.
But it would be clear who owns the task and documented what is done so far (if at all).
I think the objection here is that his is a black box and people don't know what's happening, transparency should help here,
If hermes were working as designed we would have that. The problem with Bugzilla is that you have to actively enter something to show activity, in addition to the activity itself. So, if coolo looks at a SR and deems it fine, "but not for right now", he would additionally enter comments in random bugzilla entries. Or better, he wouldn't, and rightfully so, because his time is limited. That would lead to the same questions, so bugzilla in itself wouldn't help.
Something automatic would help, as repeatedly suggested by various people (hi Lars :) ), but then it doesn't matter anymore if it was called hermes or bugzilla.
So, how shall we define the process with proper tools support? Could somebody write this up and define what we need as tool support ? and then let's make a new feature for the Build Service out of it. That way we have something good in the future, Andreas -- Andreas Jaeger, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 2009-08-11T13:44:36, Michael Matz <matz@suse.de> wrote:
Something automatic would help, as repeatedly suggested by various people (hi Lars :) ), but then it doesn't matter anymore if it was called hermes or bugzilla.
Somewhat true, but we use bugzilla for tracking most of the reasons for package submissions. (Ignoring fate for a bit.) That's the only reason why I keep referring to it, it would make the integration easier here - and it is a tool people are already used to, you can have several people watch events etc. We can, of course, build up yet another system. ;-) Regards, Lars -- Architect Storage/HA, OPS Engineering, Novell, Inc. SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag 11 August 2009 schrieb Andreas Jaeger:
But it would be clear who owns the task and documented what is done so far (if at all).
I think the objection here is that his is a black box and people don't know what's happening, transparency should help here, Sure, transparency should help here. Still, if noone looks at the package for 4.07 work days, no process will show anything else than "noone looks at it" and any transparency you want to gain has to work without people doing anything for it, unless you favor transparent "noone looked at it, but updated the status" over intransparent "someone acted".
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Andrew Beekhof <beekhof@gmail.com> [08-10-09 10:43]:
On Mon, Aug 10, 2009 at 2:28 PM, Stephan Kulow<coolo@suse.de> wrote:
There are no problems with them. I don't plan to post daily updates for all submitted packages, if there is a problem I'll notify the packager.
Yes, entirely unreasonable of people to want some feedback on their work after two weeks of silence. Good luck building a community with that attitude. Do you really expect people to put up with nonsense like this if they're not being paid to?
And so you *think* coolo is *paid* to watch over *you*. You must remember that this is free and open source. And that people with many responsibilities and little time must make restraints in order to achieve the maximum. This appears to be one of them. Please have some consideration.
From his statement, it appears "no news" *is* "good news" :^)
-- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8/10/2009 at 14:28, Stephan Kulow <coolo@suse.de> wrote: Am Montag 10 August 2009 schrieb Andrew Beekhof:
Since you seem to be the contact person then, can you please give me an update for the two packages I submitted? There are no problems with them. I don't plan to post daily updates for all submitted packages, if there is a problem I'll notify the packager.
I think the minimum 'feedback' we need finally to get working is hermes acting properly on SR creation / accepting / revoking / declining. Not having any feedback (good or bad) is unfriendly practice. Of course it should not be that besides a proper osc rq accept -m "Thanks for this wonderful package. It has just been accepted to Factory and will appear in the next sync" you have to do any additional steps. Unfortunately, the above does not create a mail to the person that initiated the osc sr create request. (This is not new... but I like mentioning it and being bashed for it). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday 10 August 2009 16:45:33 Dominique Leuenberger wrote:
I think the minimum 'feedback' we need finally to get working is hermes acting properly on SR creation / accepting / revoking / declining.
Not having any feedback (good or bad) is unfriendly practice. Of course it should not be that besides a proper osc rq accept -m "Thanks for this wonderful package. It has just been accepted to Factory and will appear in the next sync" you have to do any additional steps.
Unfortunately, the above does not create a mail to the person that initiated the osc sr create request.
Agreed. Some get mails, some don't. This is something that needs to be fixed in the build service asap. Do you get no mails at all or just some are missing? Because I do not miss any mails (the opposite is true :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8/10/2009 at 14:32, Stephan Kulow <coolo@suse.de> wrote: On Monday 10 August 2009 16:45:33 Dominique Leuenberger wrote: I think the minimum 'feedback' we need finally to get working is hermes acting properly on SR creation / accepting / revoking / declining.
Not having any feedback (good or bad) is unfriendly practice. Of course it should not be that besides a proper osc rq accept -m "Thanks for this wonderful package. It has just been accepted to Factory and will appear in the next sync" you have to do any additional steps.
Unfortunately, the above does not create a mail to the person that initiated the osc sr create request.
Agreed. Some get mails, some don't. This is something that needs to be fixed in the build service asap. Do you get no mails at all or just some are missing? Because I do not miss any mails (the opposite is true :)
:) I assume you get way to many mails... I DO get some hermes mails for SRs created against projects I'm maintainer off (games, home:dimstar, G:S:2.26 and some more). So I do know when people wish to update packages which I have an eye on and which I have some 'responsability' over. What is missing in my opinion (and it was there once) is the notifications if an SR I created against another project was accepted/rejected/whatever. Example work flow (I know people always misunderstand when I talk about 'my submissions'): - I branch a packet from multimedia:libs (random project) (osc branch) - I fix up all the spec, updating blabla... check in into my branch, let it build - Create an SR (osc sr create multimedia:libs -m "My hyper update for you"). -> From here on hermes keeps silence upon me. What I would appreciate if to get a mail when the maintainer of multimedia:libs accepts, rejects, wipes my SR. This is also what I described in https://bugzilla.novell.com/show_bug.cgi?id=505185 Best wishes, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, Aug 10, 2009 at 02:32:04 +0200, Stephan Kulow wrote:
On Monday 10 August 2009 16:45:33 Dominique Leuenberger wrote:
I think the minimum 'feedback' we need finally to get working is hermes acting properly on SR creation / accepting / revoking / declining.
Not having any feedback (good or bad) is unfriendly practice. Of course it should not be that besides a proper osc rq accept -m "Thanks for this wonderful package. It has just been accepted to Factory and will appear in the next sync" you have to do any additional steps.
Unfortunately, the above does not create a mail to the person that initiated the osc sr create request.
Agreed. Some get mails, some don't. This is something that needs to be fixed in the build service asap. Do you get no mails at all or just some are missing? Because I do not miss any mails (the opposite is true :)
I get commit mails for some projects (Subversion), and not for some others (devel:languages:python). The "_mypackages" filter in hermes doesn't work correctly, I guess. But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.) How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On 8/10/2009 at 19:54, Peter Poeml <poeml@suse.de> wrote: But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.) How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Well, the commit diff in a mail would be a nice addition, but you can always use osc rq show <id> --diff This normally serves quite well. Or did you mean something else? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 11. August 2009 schrieb Dominique Leuenberger:
On 8/10/2009 at 19:54, Peter Poeml <poeml@suse.de> wrote:
But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.) How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Well, the commit diff in a mail would be a nice addition, but you can always use osc rq show <id> --diff
This normally serves quite well. Or did you mean something else?
Well, the question is, if it is that easy, what does it take to append this to the notification mail? If something looks obviously fishy, you spare one terminal/MUA turnaround cycle (one less need to carry the <id> around, etc...) Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
[Sorry, I broke cross posting: still awaiting caffeination impact..] Am Dienstag, 11. August 2009 schrieb Dominique Leuenberger:
On 8/10/2009 at 19:54, Peter Poeml <poeml@suse.de> wrote:
But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.) How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Well, the commit diff in a mail would be a nice addition, but you can always use osc rq show <id> --diff
This normally serves quite well. Or did you mean something else?
Well, the question is, if it is that easy, what does it take to append this to the notification mail? If something looks obviously fishy, you spare one terminal/MUA turnaround cycle (one less need to carry the <id> around, etc...) Even from a sr POV, this diff would be nice (when accepted), as I was responsible for a python-qt4 build glitch lately, and this message would have given me a clue, at which point the issue creeped in. Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag 11 August 2009 schrieb Dominique Leuenberger:
On 8/10/2009 at 19:54, Peter Poeml <poeml@suse.de> wrote:
But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.) How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Well, the commit diff in a mail would be a nice addition, but you can always use osc rq show <id> --diff
This normally serves quite well. Or did you mean something else? The problem is that you can'T do show --diff after it has been accepted or something else happened to the original sources - a big problem to me ;(
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Aug 11 10:09 Stephan Kulow wrote (shortened):
The problem is that you can'T do show --diff after it has been accepted or something else happened to the original sources - a big problem to me ;(
Ooops!? Does this mean that I cannot get the differences between any revisions in the past? E.g. to find out what a contributor "johndoe" actally changed several month ago which looked perfectly right at that time but meanwhile I got a bug report and I have the feeling that johndoe's change might cause a subtle side-effect so that I need to know his exact changes to re-verify them? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 11. August 2009 10:42:26 schrieb Johannes Meixner:
Hello,
On Aug 11 10:09 Stephan Kulow wrote (shortened):
The problem is that you can'T do show --diff after it has been accepted or something else happened to the original sources - a big problem to me ;(
Ooops!?
Does this mean that I cannot get the differences between any revisions in the past?
E.g. to find out what a contributor "johndoe" actally changed several month ago which looked perfectly right at that time but meanwhile I got a bug report and I have the feeling that johndoe's change might cause a subtle side-effect so that I need to know his exact changes to re-verify them?
As part of your source log, you see messages like "accepted submit request" and you can still diff it. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Aug 11, 2009 at 08:54:18AM +0200, Dominique Leuenberger wrote:
On 8/10/2009 at 19:54, Peter Poeml <poeml@suse.de> wrote: But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.) How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Well, the commit diff in a mail would be a nice addition, but you can always use osc rq show <id> --diff
This normally serves quite well. Or did you mean something else?
Yes, I meant something else. Code commits, not submit requests. http://producingoss.com/en/vc.html#commit-emails "[...] as it is the most effective way to keep up with what's happening in the project at the code level." Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
Hello, On Aug 10 19:54 Peter Poeml wrote (shortened):
But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.)
How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Any kind of commit diffs is too late because then the other one had already finished his work and all you can do is to accept or reject his work but one cannot do collaboration from the beginning. One needs an information when someone starts to work on a package to have real concurrency control and to be able to do collaboration from the beginning. One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed. Unfortunately - as far as I know - the build service does currently not implement concurrency control. As far as I know the current build service does even not implement real revision control (like e.g. SVN). As far as I know currently revision control and concurrency control happens somehow informal at the very end during commit in the heads of various project maintainers based upon a plain message system but there is neither intrinsic built-in revision control nor concurrency control in the build service. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
Hello,
On Aug 10 19:54 Peter Poeml wrote (shortened):
But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.)
How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Any kind of commit diffs is too late because then the other one had already finished his work and all you can do is to accept or reject his work but one cannot do collaboration from the beginning.
One needs an information when someone starts to work on a package to have real concurrency control and to be able to do collaboration from the beginning.
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt. I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
Unfortunately - as far as I know - the build service does currently not implement concurrency control.
by intention as written above.
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log". bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Tue, 11 Aug 2009 10:50:01 +0200, Adrian Schröter wrote:
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
Hello,
On Aug 10 19:54 Peter Poeml wrote (shortened):
But the largest blocker for me is that I don't get any commit diffs at all. (Not implemented.)
How can I track the work of others, and review it, and how can they follow on what I do, without? So far, I have to rely on good commit messages, or dig out the changes in an elaborate manual process.
Any kind of commit diffs is too late because then the other one had already finished his work and all you can do is to accept or reject his work but one cannot do collaboration from the beginning.
One needs an information when someone starts to work on a package to have real concurrency control and to be able to do collaboration from the beginning.
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
Indeed. The modern SCMs allow concurrent works without locking but rather resolve the conflicts later at the merge time. So does OBS, too.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
Unfortunately - as far as I know - the build service does currently not implement concurrency control.
by intention as written above.
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
While we are at it, another question: can we have a backup of a certain repo with the whole revisions? IIRC, copypac doesn't keep revisions. So, if you remove a repository accidentally, no way to restore it from the user side. This hit me a couple of times... thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8/11/2009 at 10:50, Adrian Schröter<adrian@suse.de> wrote: As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
I think the osc log is getting a bit to few attention. Also, when somebody accepts an SR, there is no log entry created (by default). I think if somebody accepts an SR, this should be marked in the osc log: osc rq accept 12345 (assuming it was an SR against GNOME:Factory/gnome-commander) then I think it might be good if: osc log GNOME:Factory/gnome-commander after shows me in the log: 'vuntz accepted SR 12345 by dimstar', followed by any other commit message 'vuntz' in this case might have added using -m. This info get's currently completely lost. (is similar to the git merge log entries) Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 11. August 2009 11:04:24 schrieb Dominique Leuenberger:
On 8/11/2009 at 10:50, Adrian Schröter<adrian@suse.de> wrote:
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
I think the osc log is getting a bit to few attention. Also, when somebody accepts an SR, there is no log entry created (by default).
This is not true, and it can be actually, since the you can't modify sources on the source server without touching the revision.
I think if somebody accepts an SR, this should be marked in the osc log:
osc rq accept 12345 (assuming it was an SR against GNOME:Factory/gnome-commander) then I think it might be good if: osc log GNOME:Factory/gnome-commander after shows me in the log: 'vuntz accepted SR 12345 by dimstar', followed by any other commit message 'vuntz' in this case might have added using -m.
This is the current comment message: :comment => "Copy from #{src.project}/#{src.package} via accept of submit request #{params[:id]}\nRequest was accepted with message: \n#{params[:comment]}"
This info get's currently completely lost. (is similar to the git merge log entries)
No, we do not remove the request, you can still view it. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Aug 11 10:50 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
I do not understand how a weak synchronization point before blocks other people and slow downs development. The problem with the current build service is not the optimistic concurrency control policy at commit time, the problem is that nobody knows about others who may also work on a package until it is too late to start collaborating. Remember Coolo's mass-changes of packages. All others notice what Coolo did only when it was already done. If there was a "begin of transaction" the others could get at least informed before. But as you wrote - and as other threads here show - mutual information is not really within the scope of the build service but is left to the users of the build service to do it somehow on their own beside the build service via manual mails. In short: The build service is just what it is called, a plain build service but nothing more. This is o.k. for me - I did just misinterpret what it actually is.
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
This is mostly useless for me: jsmeix@nelson:/obs $ osc log openSUSE:Factory cups shows all entries with "unknown" and "<no message>" but I know that I explicitely provided messages while I did "osc commit". In contrast in my own working copy directory jsmeix@nelson:/obs/Printing/cups $ osc log shows more info but still not my "osc commit" messages. In my own working copy directory I do not need such information very much because in my own working copy directory I know well what I did there. In contrast it is crucial to have meningful "osc log" messages when I query whatever package on the server to find out which revisions are of particular interest regarding a particular issue. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
Am Dienstag, 11. August 2009 12:45:57 schrieb Johannes Meixner:
Hello,
On Aug 11 10:50 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
I do not understand how a weak synchronization point before blocks other people and slow downs development.
The problem with the current build service is not the optimistic concurrency control policy at commit time, the problem is that nobody knows about others who may also work on a package until it is too late to start collaborating.
Remember Coolo's mass-changes of packages. All others notice what Coolo did only when it was already done. If there was a "begin of transaction" the others could get at least informed before.
I fail to see how a package locking would help here. It would use by the script, so it would briefly lock the package and than submit it. Not much time in between. Therefore we have the source links and devel projects, one get the changes (either automatically or by manually solving via repairlink).
But as you wrote - and as other threads here show - mutual information is not really within the scope of the build service but is left to the users of the build service to do it somehow on their own beside the build service via manual mails.
We can discuss to have something like a "I am currently working on this package" flag, but I strongly mind to block something.
In short: The build service is just what it is called, a plain build service but nothing more.
This is o.k. for me - I did just misinterpret what it actually is.
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
This is mostly useless for me:
jsmeix@nelson:/obs $ osc log openSUSE:Factory cups
shows all entries with "unknown" and "<no message>" but I know that I explicitely provided messages while I did "osc commit".
osc commit messages go only to your project. openSUSE:Factory does currently not use the build service accept mechanism unfortunatly. So the special Rudi tools would need to get extended to add "request accept" comment. Sounds important ...
In contrast in my own working copy directory
jsmeix@nelson:/obs/Printing/cups $ osc log
shows more info but still not my "osc commit" messages. In my own working copy directory I do not need such information very much because in my own working copy directory I know well what I did there.
huh ? # osc log Printing ---------------------------------------------------------------------------- r170 | autobuild | 2009-07-31 19:04:44 | 8c3f68c5fe8d9e82ec6fb6aa07a8971e | unknown checked in ---------------------------------------------------------------------------- r169 | jsmeix | 2009-07-31 15:22:11 | 5df4c71fb22b1a8ddd1d76ed399d9b79 | unknown Copy from home:jsmeix:branches:Printing/cups via accept of submit request 16211 Request was accepted with message: Fixed major bug bnc#526847 ---------------------------------------------------------------------------- r168 | autobuild | 2009-07-29 17:20:30 | 8c3f68c5fe8d9e82ec6fb6aa07a8971e | unknown checked in
In contrast it is crucial to have meningful "osc log" messages when I query whatever package on the server to find out which revisions are of particular interest regarding a particular issue.
what do you miss exactly ? bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 11 August 2009 15:03:36 Adrian Schröter wrote:
Am Dienstag, 11. August 2009 12:45:57 schrieb Johannes Meixner:
Hello,
On Aug 11 10:50 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
I do not understand how a weak synchronization point before blocks other people and slow downs development.
The problem with the current build service is not the optimistic concurrency control policy at commit time, the problem is that nobody knows about others who may also work on a package until it is too late to start collaborating.
Remember Coolo's mass-changes of packages. All others notice what Coolo did only when it was already done. If there was a "begin of transaction" the others could get at least informed before.
I fail to see how a package locking would help here. It would use by the script, so it would briefly lock the package and than submit it. Not much time in between.
Therefore we have the source links and devel projects, one get the changes (either automatically or by manually solving via repairlink).
But as you wrote - and as other threads here show - mutual information is not really within the scope of the build service but is left to the users of the build service to do it somehow on their own beside the build service via manual mails.
We can discuss to have something like a "I am currently working on this package" flag, but I strongly mind to block something.
In short: The build service is just what it is called, a plain build service but nothing more.
This is o.k. for me - I did just misinterpret what it actually is.
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
This is mostly useless for me:
jsmeix@nelson:/obs $ osc log openSUSE:Factory cups
shows all entries with "unknown" and "<no message>" but I know that I explicitely provided messages while I did "osc commit".
osc commit messages go only to your project.
openSUSE:Factory does currently not use the build service accept mechanism unfortunatly. So the special Rudi tools would need to get extended to add "request accept" comment. Sounds important ...
okay, added. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.31-rc4-1-desktop #1 SMP PREEMPT 2009-07-29 16:01:26 +0200 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Aug 11 15:03 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 12:45:57 schrieb Johannes Meixner:
On Aug 11 10:50 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
I do not understand how a weak synchronization point before blocks other people and slow downs development.
The problem with the current build service is not the optimistic concurrency control policy at commit time, the problem is that nobody knows about others who may also work on a package until it is too late to start collaborating.
Remember Coolo's mass-changes of packages. All others notice what Coolo did only when it was already done. If there was a "begin of transaction" the others could get at least informed before.
I fail to see how a package locking would help here.
I never requested hard locks. A "Begin of transaction" does not require locks. Transaction semantics is "all or nothing", i.e. either all changest between "Begin of transaction" and "End of transaction" are committed or nthing at all. Transaction semantics works well with an optimistic concurrency control policy (i.e. first commit wins). Transaction semantics with optimistic concurrency control would do: 1. Begin of transaction for package foo Remember the current write time stamps for all files of package foo 2. Read whatever files of package foo are needed and change a local copy of them. 3. End of transaction for package foo 3a) Do a hard lock for all files of package foo on the server 3b) Compare if a write time stamp for one of the files which was locally changed did already change on the server and if yes do not change anythjing on the server if no write the locally changed files onto the server and finally release the lock.
It would use by the script, so it would briefly lock the package and than submit it. Not much time in between.
Yes. The hard lock happens only while a transaction is at the end finally in it commit procedure.
Therefore we have the source links and devel projects, one get the changes (either automatically or by manually solving via repairlink).
But as you wrote - and as other threads here show - mutual information is not really within the scope of the build service but is left to the users of the build service to do it somehow on their own beside the build service via manual mails.
We can discuss to have something like a "I am currently working on this package" flag, but I strongly mind to block something.
Exactly what I ask for. I just want to be informed who else works on a package while I am working on it. What I have in mind is a kind of "current workers list" on the server which contains who currently works on a package. 1. Begin of transaction 1a) Lock the current workers list (for read and write) 1b) Test if current workers list is empty 1b1) if empty, continue with step 1c 1b2) if not empty, show me the current workers list and ask me if I like to work on it additionally and wait (on the server) up to 1 minute for my response 1b2a) if response is "no" or if timeout, unlock the current workers list and cancel the transaction 1b2b) if response is "yes", continue with step 1c 1c) Add myself to the current workers list 1d) Send the current workers list to all current workers 1d) Unlock the current workers list 1f) Create local copy (i.e. "Read") 2. Modify local copy 3. End of transaction 3a) Lock 3b) Test if modifications do not conflict (i.e. "Validate") 3b1) if no conflict, write modifications (i.e. "Write") 3b2) if conflict, ignore modifications (loss of work) 3c) Unlock 3d) Remove myself from the current workers list 3e) Send the current workers list to me and all current workers The two kind of "send the current workers list" messages should be processed by hermes (i.e. one can suppress them). Perferably each worker could provide an optional notification which is also stored in the "current workers list" what the reason is why he works on a package like "fixing bnc#12345".
In contrast in my own working copy directory
jsmeix@nelson:/obs/Printing/cups $ osc log
shows more info but still not my "osc commit" messages. In my own working copy directory I do not need such information very much because in my own working copy directory I know well what I did there.
huh ?
When I do "osc commit", there is a commit message which defaults to the differences in the changes file. I leave at least the default but often I add something more.
# osc log Printing ---------------------------------------------------------------------------- r170 | autobuild | 2009-07-31 19:04:44 | 8c3f68c5fe8d9e82ec6fb6aa07a8971e | unknown
checked in ---------------------------------------------------------------------------- r169 | jsmeix | 2009-07-31 15:22:11 | 5df4c71fb22b1a8ddd1d76ed399d9b79 | unknown
Copy from home:jsmeix:branches:Printing/cups via accept of submit request 16211 Request was accepted with message: Fixed major bug bnc#526847 ---------------------------------------------------------------------------- r168 | autobuild | 2009-07-29 17:20:30 | 8c3f68c5fe8d9e82ec6fb6aa07a8971e | unknown
checked in
In contrast it is crucial to have meningful "osc log" messages when I query whatever package on the server to find out which revisions are of particular interest regarding a particular issue.
what do you miss exactly ?
I do not mean the request messages but my "osc commit" messsages. I would like to have the diff of the changes file as the minimum of meaningful "osc log" messages. "osc help log" reads "Shows the commit log of a package" but currently it seems "osc log" does not show a log regarding what has changed inside a package (i.e. its changelog) but a log regarding what happened to a package in the obs i.e. whereto it was submited and if it was accepted and so on but according to my understanding this is not the commit log but a submit log. The use case which I have in mind is: End-user jane runs out there whatever package from the obs. I get a bug report from her. I let her send me "rpm -q --changelog" and therein I find a suspicious entry: * Wed Jan 14 2009 johndoe@somewhere - removed various obsolete stuff Now I want to know exactly what johndoe did at that time. My first problem is to find out the osc revision which matches to this RPM changelog entry. I don't know a direct way to get it. If I had the RPM changelog differences as the absolute minimum in the "osc log" output, I could do an appropriate "osc rdiff" but currently I have no idea - except dumb trial and error - how to get what johndoe did at that time. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
Am Dienstag, 11. August 2009 16:39:43 schrieb Johannes Meixner:
Hello,
On Aug 11 15:03 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 12:45:57 schrieb Johannes Meixner:
On Aug 11 10:50 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
I do not understand how a weak synchronization point before blocks other people and slow downs development.
The problem with the current build service is not the optimistic concurrency control policy at commit time, the problem is that nobody knows about others who may also work on a package until it is too late to start collaborating.
Remember Coolo's mass-changes of packages. All others notice what Coolo did only when it was already done. If there was a "begin of transaction" the others could get at least informed before.
I fail to see how a package locking would help here.
I never requested hard locks. A "Begin of transaction" does not require locks.
Transaction semantics is "all or nothing", i.e. either all changest between "Begin of transaction" and "End of transaction" are committed or nthing at all.
Transaction semantics works well with an optimistic concurrency control policy (i.e. first commit wins).
Transaction semantics with optimistic concurrency control would do:
1. Begin of transaction for package foo Remember the current write time stamps for all files of package foo
2. Read whatever files of package foo are needed and change a local copy of them.
3. End of transaction for package foo 3a) Do a hard lock for all files of package foo on the server 3b) Compare if a write time stamp for one of the files which was locally changed did already change on the server and if yes do not change anythjing on the server if no write the locally changed files onto the server and finally release the lock.
all this is there IMHO, just that usually md5sums are used instead of timestamps.
It would use by the script, so it would briefly lock the package and than submit it. Not much time in between.
Yes. The hard lock happens only while a transaction is at the end finally in it commit procedure.
No need for a lock, we just do it atomar already. And another commit fails if it is not based on the former revision.
Therefore we have the source links and devel projects, one get the changes (either automatically or by manually solving via repairlink).
But as you wrote - and as other threads here show - mutual information is not really within the scope of the build service but is left to the users of the build service to do it somehow on their own beside the build service via manual mails.
We can discuss to have something like a "I am currently working on this package" flag, but I strongly mind to block something.
Exactly what I ask for. I just want to be informed who else works on a package while I am working on it.
What I have in mind is a kind of "current workers list" on the server which contains who currently works on a package.
1. Begin of transaction 1a) Lock the current workers list (for read and write) 1b) Test if current workers list is empty 1b1) if empty, continue with step 1c 1b2) if not empty, show me the current workers list and ask me if I like to work on it additionally and wait (on the server) up to 1 minute for my response 1b2a) if response is "no" or if timeout, unlock the current workers list and cancel the transaction 1b2b) if response is "yes", continue with step 1c 1c) Add myself to the current workers list 1d) Send the current workers list to all current workers 1d) Unlock the current workers list 1f) Create local copy (i.e. "Read") 2. Modify local copy 3. End of transaction 3a) Lock 3b) Test if modifications do not conflict (i.e. "Validate") 3b1) if no conflict, write modifications (i.e. "Write") 3b2) if conflict, ignore modifications (loss of work) 3c) Unlock 3d) Remove myself from the current workers list 3e) Send the current workers list to me and all current workers
What is the timeframe between 1 and 3 ? 3. itself runs already atomar, so I do not see a reason for locking. Do you really thing this is needed, why can other developers with other scms survive without ? I mean, we even have source links and submit requests which allows parallel development, so what makes us so special that we need such a system ?
The two kind of "send the current workers list" messages should be processed by hermes (i.e. one can suppress them).
Perferably each worker could provide an optional notification which is also stored in the "current workers list" what the reason is why he works on a package like "fixing bnc#12345".
A worker is someone else have write access in your project or package, right ? IMHO a submit as often as possible approach would have already this effect, and you can already subscribe to source changes in your package in hermes.
...
In contrast it is crucial to have meningful "osc log" messages when I query whatever package on the server to find out which revisions are of particular interest regarding a particular issue.
what do you miss exactly ?
I do not mean the request messages but my "osc commit" messsages.
I would like to have the diff of the changes file as the minimum of meaningful "osc log" messages.
"osc help log" reads "Shows the commit log of a package" but currently it seems "osc log" does not show a log regarding what has changed inside a package (i.e. its changelog) but a log regarding what happened to a package in the obs i.e. whereto it was submited and if it was accepted and so on but according to my understanding this is not the commit log but a submit log.
Okay, the changelog handling is on our todo list since the begin of OBS. But it is a quite complex task. However, what is important to understand is that the commit log is target for the developer, which the changes file is target for the end-user. So the content of them might complete different. Nevertheless there should be of course a connection to avoid double work.
The use case which I have in mind is:
End-user jane runs out there whatever package from the obs. I get a bug report from her. I let her send me "rpm -q --changelog" and therein I find a suspicious entry:
* Wed Jan 14 2009 johndoe@somewhere - removed various obsolete stuff
Now I want to know exactly what johndoe did at that time.
My first problem is to find out the osc revision which matches to this RPM changelog entry. I don't know a direct way to get it.
You even have more problems, you don't know from which project (or even package) this is build from and you don't know which code version it is exactly (there might be multiple versions with this last changelog entry). Last but not least, you don't know if it is really from this build service instance. We have introduced therefore the disturl tag sicne SLE 11. So please ask your users for the output of it: # rpm -q --qf '%{DISTURL}\n' osc obs://build.opensuse.org/openSUSE:Tools/openSUSE_Factory/8f3b8001f49bc9e991b80cf0d7cfb5c4- osc you can check out the code now via # osc co openSUSE:Tools osc -r 8f3b8001f49bc9e991b80cf0d7cfb5c4 or call rdiff to see the changes since then. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag, 11. August 2009 18:57:17 schrieb Adrian Schröter:
Am Dienstag, 11. August 2009 16:39:43 schrieb Johannes Meixner: ...
* Wed Jan 14 2009 johndoe@somewhere - removed various obsolete stuff
Now I want to know exactly what johndoe did at that time.
My first problem is to find out the osc revision which matches to this RPM changelog entry. I don't know a direct way to get it.
You even have more problems, you don't know from which project (or even package) this is build from and you don't know which code version it is exactly (there might be multiple versions with this last changelog entry). Last but not least, you don't know if it is really from this build service instance.
We have introduced therefore the disturl tag sicne SLE 11. So please ask your users for the output of it:
# rpm -q --qf '%{DISTURL}\n' osc obs://build.opensuse.org/openSUSE:Tools/openSUSE_Factory/8f3b8001f49bc9e991 b80cf0d7cfb5c4- osc
you can check out the code now via
# osc co openSUSE:Tools osc -r 8f3b8001f49bc9e991b80cf0d7cfb5c4
or call rdiff to see the changes since then.
Nevertheless there is an "osc blame" missing of course which could be used to find out the source revisions between this changelog entry and the version before. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Aug 11 18:57 Adrian Schröter wrote (shortened):
Do you really thing this is needed, why can other developers with other scms survive without ?
Of course I survive without it. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
On Aug 11, 09 12:45:57 +0200, Johannes Meixner wrote:
it does, check "osc log".
This is mostly useless for me: jsmeix@nelson:/obs $ osc log openSUSE:Factory cups
shows all entries with "unknown" and "<no message>" but I know that I explicitely provided messages while I did "osc commit".
Buildservice does not forward commit logs. instead of $ osc log openSUSE:Factory PKG you almost always want to run $ osc meta pkg openSUSE:Factory cups | grep devel <devel package="PKG" project="BSDEVELPRJ"/> $ osc log BSDEVELPRJ PKG
In contrast it is crucial to have meningful "osc log" messages when I query whatever package on the server to find out which revisions are of particular interest regarding a particular issue.
No. You learn where the tar-pits are. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Johannes Meixner (jsmeix@suse.de) [20090811 10:37]:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
Impossible to solve by technical means! You have to rely on others with check-in rights communicating with you. No software can help there. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 11 août 2009, à 12:32 +0200, Philipp Thomas a écrit :
* Johannes Meixner (jsmeix@suse.de) [20090811 10:37]:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
Impossible to solve by technical means! You have to rely on others with check-in rights communicating with you. No software can help there.
Well, software can still help... In the GNOME team, we use the "osc gnome" plugin (which you can now use for any project that is related to oS:F, not just GNOME:Factory), and there's a reservation feature in the plugin that is quite helpful. If you have any doubt, just ask anybody in the team :-) The typical example is when a new GNOME upstream release is out, we have a lot of work to do, and we can quickly see when someone is working on a package, so we just take another one. And by all means, it's a weak reservation system: you can ignore the reservation, and reservation automatically expires after 36 hours if it wasn't removed before. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Aug 11 12:32 Philipp Thomas wrote (shortened):
* Johannes Meixner (jsmeix@suse.de) [20090811 10:37]:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
Impossible to solve by technical means! You have to rely on others with check-in rights communicating with you. No software can help there.
Prove that it is impossible! But read the rest of my mail too to avoid that you prove something which is off-topic. Of course transactions are impossible to solve by technical means. Of course no software can help. Never. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi,
I get commit mails for some projects (Subversion), and not for some others (devel:languages:python). The "_mypackages" filter in hermes doesn't work correctly, I gues
Hurrah for Peter because he brought me on the right track with this comment. Indeed the _mypackages filter had a bug: It was just considering the people directly from the _package_ meta file, not these who inherit the permissions through the _project_ meta file. That happened because in one point of time the api stopped to combine this information in the pack meta file :-( I fixed that accordingly and deployed already. Please keep your eyes open if the behaviour is now more logical, predictable etc. and what you expect. Sorry, Klaas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (17)
-
Adrian Schröter -
Andreas Jaeger -
Andrew Beekhof -
Dominique Leuenberger -
Hans-Peter Jansen -
Johannes Meixner -
Juergen Weigert -
Klaas Freitag -
Lars Marowsky-Bree -
Michael Matz -
Patrick Shanahan -
Peter Poeml -
Philipp Thomas -
Ruediger Oertel -
Stephan Kulow -
Takashi Iwai -
Vincent Untz