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.