Since I am not it Prague any more. My POV about the "Release Schedule Discussion".
Basically people mostly cares about his particular work, and not about the distribution as a whole. The work in the distribution as a whole is left to Coolo and few more people. Since what we need is more people to look at it, some problems/things to do:
- Make https://build.opensuse.org/project/status?project=openSUSE%3AFactory the homepage of more people Too many clicks are required to reach the Factory status page. It's like if someone wanted to hide it. Not that I think it actually makes such a difference, but we should try to make it more visible. But the big problem is that it takes 30+ seconds to load it. Sometimes I actually don't look at it just because I don't want to wait. There is nothing that can be done about it? Caching?
Make it fast and visible and more people will know about Factory status. The essential first step to get people to help.
- Make people want to work on the problems Now I already loaded the Factory status page. I look at the list and I usually find two kind of entries: the ones that are so important that I am sure somebody else is already working on it (or is already fixed but lacks a rebuild), and the ones I don't care about.
I mean, yast2-network has been failing to build for 11 days??? It can't actually be true, is it? And if it is for sure it's just because it's a complex problem, but somebody has been working on it for 10 days. I guess something similar is happening with libreoffice.
But "qutim"? Yet another instant messenger? It's the first time I listen about it. I just can't find the motivation to look into it.
For the first problem we need some easy and visible way to see if somebody else already took responsibility to fix a problem. Without this people just doesn't help because they don't think their help is needed. The Factory status page needs an extra column with the name of the person working on the problem.
For the second problem we need a defined policy for dropping packages. If a package doesn't build for a long time and nobody fixes it... well, just drop it. It's clear nobody cares enough. I am sure it could be improved, but let's say: "If a package doesn't build for 30 days mark it for dropping. Announce it, with a list of all the current packages marked for dropping everywhere. Send the announcement to -factory/-packaging. Put it in news.opensuse.org. Have it in the forums so users also now. Perhaps let forum users vote for the packages they actually care. If after 60 days it still fails to build the package gets dropped, with also an announcement."
- Inform maintainers when their update breaks other packages Sure, perhaps the kernel maintainer doesn't care if an out-of-tree module breaks. But some people *may* actually care if their update of a library breaks an application. Let's send an automatic email to them. If they don't care they will just ignore the email, if they care... great! I guess it's not so obvious to automatically know what package broke another one. But we can know the problem was caused by a package in a subset, at the very least "the whole list of modified packages".
Am 23.10.2012 12:09, schrieb Cristian Morales Vega:
Since I am not it Prague any more. My POV about the "Release Schedule Discussion".
Basically people mostly cares about his particular work, and not about the distribution as a whole. The work in the distribution as a whole is left to Coolo and few more people. Since what we need is more people to look at it, some problems/things to do:
the homepage of more people Too many clicks are required to reach the Factory status page. It's like if someone wanted to hide it. Not that I think it actually makes such a difference, but we should try to make it more visible. But the big problem is that it takes 30+ seconds to load it. Sometimes I actually don't look at it just because I don't want to wait. There is nothing that can be done about it? Caching?
It's already cached for openSUSE:Factory - it takes over an hour to gather all the information ;(
And the reason it's hidden - as you say - is exactly the speed issue.
Make it fast and visible and more people will know about Factory status. The essential first step to get people to help.
- Make people want to work on the problems
Now I already loaded the Factory status page. I look at the list and I usually find two kind of entries: the ones that are so important that I am sure somebody else is already working on it (or is already fixed but lacks a rebuild), and the ones I don't care about.
I mean, yast2-network has been failing to build for 11 days??? It can't actually be true, is it? And if it is for sure it's just because it's a complex problem, but somebody has been working on it for 10 days. I guess something similar is happening with libreoffice.
As usually people do not even know the build fails, I wouldn't assume that.
But "qutim"? Yet another instant messenger? It's the first time I listen about it. I just can't find the motivation to look into it.
Fine, but at least someone could ping the maintainer - that someone is coolo too and as the topic is about helping coolo... ;)
For the first problem we need some easy and visible way to see if somebody else already took responsibility to fix a problem. Without this people just doesn't help because they don't think their help is needed. The Factory status page needs an extra column with the name of the person working on the problem.
It's fair, but so far the build service does not have support for that level of collaboration - perhaps it should, basically creating an "issue" (in github terms) for every build failure to discuss and assign.
For the second problem we need a defined policy for dropping packages. If a package doesn't build for a long time and nobody fixes it... well, just drop it. It's clear nobody cares enough.
I already do that - my limit is > 100 days though.
I am sure it could be improved, but let's say: "If a package doesn't build for 30 days mark it for dropping. Announce it, with a list of all the current packages marked for dropping everywhere. Send the announcement to -factory/-packaging. Put it in news.opensuse.org. Have it in the forums so users also now. Perhaps let forum users vote for the packages they actually care. If after 60 days it still fails to build the package gets dropped, with also an announcement."
Sounds like a perfect job for a volunteer - build failure drop police officer? :)
- Inform maintainers when their update breaks other packages
Sure, perhaps the kernel maintainer doesn't care if an out-of-tree module breaks. But some people *may* actually care if their update of a library breaks an application. Let's send an automatic email to them. If they don't care they will just ignore the email, if they care... great! I guess it's not so obvious to automatically know what package broke another one. But we can know the problem was caused by a package in a subset, at the very least "the whole list of modified packages".
Yeah, that would be good to have. That brings us into the "hermes needs closer integration with OBS" topic we had at the "future of OBS" BoF. People should get a mail whenever their package fails in factory with the information of the changeset of depending packages since the last successful build - for example.
Greetings, Stephan
On 10/25/2012 10:40 AM, Stephan Kulow wrote:
I am sure it could be improved, but let's say: "If a package doesn't build for 30 days mark it for dropping. Announce it, with a list of all the current packages marked for dropping everywhere. Send the announcement to -factory/-packaging. Put it in news.opensuse.org. Have it in the forums so users also now. Perhaps let forum users vote for the packages they actually care. If after 60 days it still fails to build the package gets dropped, with also an announcement."
Sounds like a perfect job for a volunteer - build failure drop police officer? :)
I am willing to take on that job, but I will need some training.
Larry
On 25 October 2012 16:40, Stephan Kulow coolo@suse.de wrote:
Am 23.10.2012 12:09, schrieb Cristian Morales Vega:
Since I am not it Prague any more. My POV about the "Release Schedule Discussion".
Basically people mostly cares about his particular work, and not about the distribution as a whole. The work in the distribution as a whole is left to Coolo and few more people. Since what we need is more people to look at it, some problems/things to do:
the homepage of more people Too many clicks are required to reach the Factory status page. It's like if someone wanted to hide it. Not that I think it actually makes such a difference, but we should try to make it more visible. But the big problem is that it takes 30+ seconds to load it. Sometimes I actually don't look at it just because I don't want to wait. There is nothing that can be done about it? Caching?
It's already cached for openSUSE:Factory - it takes over an hour to gather all the information ;(
And the reason it's hidden - as you say - is exactly the speed issue.
Kind of a problem, but OK. Let's pass to the workarounds...
Make it fast and visible and more people will know about Factory status. The essential first step to get people to help.
- Make people want to work on the problems
Now I already loaded the Factory status page. I look at the list and I usually find two kind of entries: the ones that are so important that I am sure somebody else is already working on it (or is already fixed but lacks a rebuild), and the ones I don't care about.
I mean, yast2-network has been failing to build for 11 days??? It can't actually be true, is it? And if it is for sure it's just because it's a complex problem, but somebody has been working on it for 10 days. I guess something similar is happening with libreoffice.
As usually people do not even know the build fails, I wouldn't assume that.
Can someone clear this for me? Right now if a package fails to build in Factory I don't get notified just by this fact? But I will get notified once it fails in the devel project (and I guess... *hope* that this is the case for most people). Now, the devel project probably is building against "snapshot", not against "standard". So people is usually notified after... how often there are snapshots?
But "qutim"? Yet another instant messenger? It's the first time I listen about it. I just can't find the motivation to look into it.
Fine, but at least someone could ping the maintainer - that someone is coolo too and as the topic is about helping coolo... ;)
You are scaring me here. Doesn't people usually get automatically "pinged" when the package starts to fail in the devel project?
For the first problem we need some easy and visible way to see if somebody else already took responsibility to fix a problem. Without this people just doesn't help because they don't think their help is needed. The Factory status page needs an extra column with the name of the person working on the problem.
It's fair, but so far the build service does not have support for that level of collaboration - perhaps it should, basically creating an "issue" (in github terms) for every build failure to discuss and assign.
For the second problem we need a defined policy for dropping packages. If a package doesn't build for a long time and nobody fixes it... well, just drop it. It's clear nobody cares enough.
I already do that - my limit is > 100 days though.
I am sure it could be improved, but let's say: "If a package doesn't build for 30 days mark it for dropping. Announce it, with a list of all the current packages marked for dropping everywhere. Send the announcement to -factory/-packaging. Put it in news.opensuse.org. Have it in the forums so users also now. Perhaps let forum users vote for the packages they actually care. If after 60 days it still fails to build the package gets dropped, with also an announcement."
Sounds like a perfect job for a volunteer - build failure drop police officer? :)
If for Saturday/Sunday nobody has done it before I will try to do a test.
- Inform maintainers when their update breaks other packages
Sure, perhaps the kernel maintainer doesn't care if an out-of-tree module breaks. But some people *may* actually care if their update of a library breaks an application. Let's send an automatic email to them. If they don't care they will just ignore the email, if they care... great! I guess it's not so obvious to automatically know what package broke another one. But we can know the problem was caused by a package in a subset, at the very least "the whole list of modified packages".
Yeah, that would be good to have. That brings us into the "hermes needs closer integration with OBS" topic we had at the "future of OBS" BoF. People should get a mail whenever their package fails in factory with the information of the changeset of depending packages since the last successful build - for example.
There are videos of the BoFs? The conclusion was "needs it" or "needs it, it should be ready in two months"?
On Thu, Oct 25, 2012 at 12:40 PM, Stephan Kulow coolo@suse.de wrote:
the homepage of more people Too many clicks are required to reach the Factory status page. It's like if someone wanted to hide it. Not that I think it actually makes such a difference, but we should try to make it more visible. But the big problem is that it takes 30+ seconds to load it. Sometimes I actually don't look at it just because I don't want to wait. There is nothing that can be done about it? Caching?
It's already cached for openSUSE:Factory - it takes over an hour to gather all the information ;(
And the reason it's hidden - as you say - is exactly the speed issue.
Any idea what the bottleneck is?
Maybe it can be improved.
Am 25.10.2012 18:58, schrieb Claudio Freire:
On Thu, Oct 25, 2012 at 12:40 PM, Stephan Kulow coolo@suse.de wrote:
the homepage of more people Too many clicks are required to reach the Factory status page. It's like if someone wanted to hide it. Not that I think it actually makes such a difference, but we should try to make it more visible. But the big problem is that it takes 30+ seconds to load it. Sometimes I actually don't look at it just because I don't want to wait. There is nothing that can be done about it? Caching?
It's already cached for openSUSE:Factory - it takes over an hour to gather all the information ;(
And the reason it's hidden - as you say - is exactly the speed issue.
Any idea what the bottleneck is?
Yeah, the build service :)
Greetings, Stephan
On Thu, Oct 25, 2012 at 2:08 PM, Stephan Kulow coolo@suse.de wrote:
Any idea what the bottleneck is?
Yeah, the build service :)
Greetings, Stephan
Then it's easy to fix. Just swap it with a faster one.
:)
Hi,
Am 25.10.2012 18:56, schrieb Cristian Morales Vega:
On 25 October 2012 16:40, Stephan Kulow coolo@suse.de wrote:
I mean, yast2-network has been failing to build for 11 days??? It can't actually be true, is it? And if it is for sure it's just because it's a complex problem, but somebody has been working on it for 10 days. I guess something similar is happening with libreoffice.
As usually people do not even know the build fails, I wouldn't assume that.
Can someone clear this for me? Right now if a package fails to build in Factory I don't get notified just by this fact? But I will get notified once it fails in the devel project (and I guess... *hope* that this is the case for most people). Now, the devel project probably is building against "snapshot", not against "standard". So people is usually notified after... how often there are snapshots?
But "qutim"? Yet another instant messenger? It's the first time I listen about it. I just can't find the motivation to look into it.
Fine, but at least someone could ping the maintainer - that someone is coolo too and as the topic is about helping coolo... ;)
You are scaring me here. Doesn't people usually get automatically "pinged" when the package starts to fail in the devel project?
I _think_ people are actually not pinged. And I'm not sure if my Hermes just is configured the wrong way or something else is not as it should be. OBS knows that I'm the maintainer apparently:
wolfi@Hygiea:~> osc maintainer openSUSE:Factory MozillaFirefox bugowner of mozilla:Factory/MozillaFirefox : -
maintainer of mozilla:Factory/MozillaFirefox : wrosenauer
Actually I'm not sure if I get notified since I cannot remember it failing but I filter OBS mails away since I get too many.
I would propose that OBS needs to create a bug @ bugzilla for a failing package in OBS and assign it to the maintainer and a certain other group so they notice if the maintainer does not react.
I'm just not sure if we swamp bugzilla then by strange build issues caused by broken workers but still bugzilla is _the_ system for that stuff.
Wolfgang
On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer wolfgang@rosenauer.org wrote:
I would propose that OBS needs to create a bug @ bugzilla for a failing package in OBS and assign it to the maintainer and a certain other group so they notice if the maintainer does not react.
That would create thousands of bugs. I get regular notifications of OBS-related failures, fixed trivially with a rebuild. Sometimes it's a genuine problem in some dependency, fixed by fixing the offending lib. In most cases, a bug @ bugzilla would be overkill.
On 2012-10-25 19:33, Claudio Freire wrote:
On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer wolfgang@rosenauer.org wrote:
I would propose that OBS needs to create a bug @ bugzilla for a failing package in OBS and assign it to the maintainer and a certain other group so they notice if the maintainer does not react.
That would create thousands of bugs. I get regular notifications of OBS-related failures, fixed trivially with a rebuild. Sometimes it's a genuine problem in some dependency, fixed by fixing the offending lib. In most cases, a bug @ bugzilla would be overkill.
I prefer that OBS a bug report for a failed package, but only for openSUSE:Factory, only once until it's fixed, not every time it fails due to a rebuild. If I look at the page Cristian sent https://build.opensuse.org/project/status?project=openSUSE%3AFactory, that would currently mean about 62 bug reports, if the kiwi build failures aren't included.
Regards,
Joop.
Am 26.10.2012 09:21, schrieb Joop Boonen:
On 2012-10-25 19:33, Claudio Freire wrote:
On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer wolfgang@rosenauer.org wrote:
I would propose that OBS needs to create a bug @ bugzilla for a failing package in OBS and assign it to the maintainer and a certain other group so they notice if the maintainer does not react.
That would create thousands of bugs. I get regular notifications of OBS-related failures, fixed trivially with a rebuild. Sometimes it's a genuine problem in some dependency, fixed by fixing the offending lib. In most cases, a bug @ bugzilla would be overkill.
I prefer that OBS a bug report for a failed package, but only for openSUSE:Factory, only once until it's fixed, not every time it fails due to a rebuild. If I look at the page Cristian sent https://build.opensuse.org/project/status?project=openSUSE%3AFactory, that would currently mean about 62 bug reports, if the kiwi build failures aren't included.
I don't want them to be in bugzilla, so they can be easily auto closed.
Greetings, Stephan
On Fri, 26 Oct 2012 09:52:28 +0200 Stephan Kulow coolo@suse.de wrote:
If I look at the page Cristian sent https://build.opensuse.org/project/status?project=openSUSE%3AFactory,
From my point of view of a "simple" packager without deeper involvement in openSUSE this list is near to ideal. I don't want any further automatic mails.
May be coolo can send a notice maybe 14 (21?) days before the first beta to the maintainers of those packages, that they won't be included in next release if still in that state at release time of first beta (or whatever seeems appropriate). Just drop those that are not important from the next release.
If there are packages on this list important for the distribution there is a more serious problem: a maintainer of critical infrastructure does not care. No bugzilla and no other formalism will solve that.
Detlef
On 2012-10-26 09:52, Stephan Kulow wrote:
Am 26.10.2012 09:21, schrieb Joop Boonen:
On 2012-10-25 19:33, Claudio Freire wrote:
On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer wolfgang@rosenauer.org wrote:
I would propose that OBS needs to create a bug @ bugzilla for a failing package in OBS and assign it to the maintainer and a certain other group so they notice if the maintainer does not react.
That would create thousands of bugs. I get regular notifications of OBS-related failures, fixed trivially with a rebuild. Sometimes it's a genuine problem in some dependency, fixed by fixing the offending lib. In most cases, a bug @ bugzilla would be overkill.
I prefer that OBS a bug report for a failed package, but only for openSUSE:Factory, only once until it's fixed, not every time it fails due to a rebuild. If I look at the page Cristian sent
https://build.opensuse.org/project/status?project=openSUSE%3AFactory, that would currently mean about 62 bug reports, if the kiwi build failures aren't included.
I don't want them to be in bugzilla, so they can be easily auto closed.
Greetings, Stephan
Would it be an option to have a different sender (obs@opensuse.org for instance) for the "broken" factory packages, so it won't be overlooked in the hermes mails.
I would like that the mails in general would be more tunable. When your a member of a project you get mails for all failed packages. When you have broken packages in your home project you'll also get mails for them.
I would purpose that you can select which packages you want to monitor. openSUSE:Factory packages that your the maintainer of are always monitored. Other non home projects can selected to be monitored, when your the dedicated maintainer it's always monitored. Home projects can selected to be monitored, if they are not monitored they won't be rebuild automatically.
Regards,
Joop.
On Fri, Oct 26, 2012 at 6:14 AM, Joop Boonen joop.boonen@boonen.org wrote:
I don't want them to be in bugzilla, so they can be easily auto closed.
Greetings, Stephan
Would it be an option to have a different sender (obs@opensuse.org for instance) for the "broken" factory packages, so it won't be overlooked in the hermes mails.
I would like that the mails in general would be more tunable. When your a member of a project you get mails for all failed packages. When you have broken packages in your home project you'll also get mails for them.
I would purpose that you can select which packages you want to monitor. openSUSE:Factory packages that your the maintainer of are always monitored. Other non home projects can selected to be monitored, when your the dedicated maintainer it's always monitored. Home projects can selected to be monitored, if they are not monitored they won't be rebuild automatically.
Yes, and edge-triggered notifications.
If a package fails to build due to a broken dependency, I may choose not to act immediately, to give the maintainer of that other package time to react. In those cases, getting notified of a successful build can be useful in those cases (to let me know all is ok again, no need to go to obs and check). But if I enable successful build notifications, I will also get hundreds of uninteresting notifications, every time an automatic rebuild is triggered. This makes success notifications useless.
A more effective hermes system would IMHO be better than automatic bug reports.
Also, I'm thinking, whether users' home page in OBS could have a version of the status page, but limited to the user's packages. When I want to check if my projects build, I have to go to the my projects page and click on all the "Monitor" links, manually. It would be far more efficient and attention-grabbing if there was a status page there, with the information handy as in the case of Factory's status page. The performance issue would be sidestepped by only including packages (not projects) of which I have direct maintainership.
Hey,
On 26.10.2012 14:12, Claudio Freire wrote:
A more effective hermes system would IMHO be better than automatic bug reports.
It's open source, kind of unmaintained. Hermes seriously needs your help. Get going :-)
http://en.opensuse.org/openSUSE:Hermes_hacking
Henne
On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
Hey,
On 26.10.2012 14:12, Claudio Freire wrote:
A more effective hermes system would IMHO be better than automatic bug reports.
It's open source, kind of unmaintained. Hermes seriously needs your help. Get going :-)
Just curious if not maintained why aren't we looking for something else that is maintained and fits to the needs.
Togan
On Fri, Oct 26, 2012 at 10:42 AM, Henne Vogelsang hvogel@opensuse.org wrote:
A more effective hermes system would IMHO be better than automatic bug reports.
It's open source, kind of unmaintained. Hermes seriously needs your help. Get going :-)
I'll take a look, but perl's not my strong suit. It's not even my weak suit. I even hate it.
But I'll take a look.
Am 26.10.2012 16:17, schrieb Togan Muftuoglu:
On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
Hey,
On 26.10.2012 14:12, Claudio Freire wrote:
A more effective hermes system would IMHO be better than automatic bug reports.
It's open source, kind of unmaintained. Hermes seriously needs your help. Get going :-)
Just curious if not maintained why aren't we looking for something else that is maintained and fits to the needs.
Like?
Greetings, Stephan
On 10/26/2012 04:35 PM, Stephan Kulow wrote:
Am 26.10.2012 16:17, schrieb Togan Muftuoglu:
On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
Hey,
On 26.10.2012 14:12, Claudio Freire wrote:
A more effective hermes system would IMHO be better than automatic bug reports.
It's open source, kind of unmaintained. Hermes seriously needs your help. Get going :-)
Just curious if not maintained why aren't we looking for something else that is maintained and fits to the needs.
Like?
Don't know if there is something that would do the job. I just had a quick look to the page Henne posted it looks as if it was made to measure for opensuse, which in that case logical for looking out new tailors.
Togan
On Thu, 25 Oct 2012 17:56:26 +0100, Cristian Morales Vega reddwarf@opensuse.org wrote:
Can someone clear this for me? Right now if a package fails to build in Factory I don't get notified just by this fact? But I will get notified once it fails in the devel project
AFAIK, you're only notified if you configured Hermes to do so, no matter if it's factory or devel project.
Philipp
Am 26.10.2012 17:06, schrieb Togan Muftuoglu:
On 10/26/2012 04:35 PM, Stephan Kulow wrote:
Am 26.10.2012 16:17, schrieb Togan Muftuoglu:
On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
Hey,
On 26.10.2012 14:12, Claudio Freire wrote:
A more effective hermes system would IMHO be better than automatic bug reports.
It's open source, kind of unmaintained. Hermes seriously needs your help. Get going :-)
Just curious if not maintained why aren't we looking for something else that is maintained and fits to the needs.
Like?
Don't know if there is something that would do the job. I just had a quick look to the page Henne posted it looks as if it was made to measure for opensuse, which in that case logical for looking out new tailors.
Yeah, but suggesting to switch to alternatives without listing alternatives is kind of a NOP.
Greetings, Stephan
-
Claudio Freire -
Cristian Morales Vega -
Detlef Steuer -
Henne Vogelsang -
Joop Boonen -
Larry Finger -
Philipp Thomas -
Stephan Kulow -
Togan Muftuoglu -
Wolfgang Rosenauer