Am 02.08.2013 17:18, schrieb Stephan Barth:
The main issues to stay away from helping are:
Hi Stephan, Thanks for bringing these up. Everything is theory unless you discuss (and even fix) things really bothering.
- I get those emails for factory work and I never touched one of the packages, because I don't know if someone else already started to work on it. I would expect an email that tells me that the information from the previous mail is deprecated and the issue fixed. => a locking mechanism might be helpful here since fixing can take hours
- it is hard to tell what might have caused the breakage with packages that I have never seen before. OBS should help with telling me what has changed and therefore might have caused the breakage. Does anyone want to compare build logs? :) => make transparent what has changed since the last successful build That's has been wished before, but it's often impossible to say even for humans - I try my best in setting the failed comment in the factory
That's actually a very poor excuse as there exists a locking mechanism: write a mail if it takes longer than a couple of minute. If it's quick, your submit request with the fix will be the mail :) All locking mechanisms discussed so far have one weakness: they only make sense if everyone uses them. We have this osc collab server, who offers exactly that but is only used by a small subset. We had people requesting a mail if someone branches "their" package and I think it was even implemented, but that only helps if you have single maintainers and "externals" fixing it. It doesn't help to coordinate maintainers. project status. I try to update them as often as possible, because it's easier to say what changed the day before than having to look at it after weeks. But developing an automatism will be very hard and I'm not sure if it would help in most cases - because in the end it doesn't matter why invalid memcpy fail now and did not before. They were invalid from the beginning and need fixing. If it was glibc or gcc who revealed the bug doesn't *really* matter.
- documentation is not up-to-date, incomplete or missing. For instance rpmlint gives me a lot of errors, but even with hours of googling I wasn't able to fix one of my packages today. As an example this provides less information than the build log error message: http://en.opensuse.org/openSUSE:Packaging_checks#files-duplicate I usually search through my spec files, but this doesn't answer all my questions. => Some best practice spec files would be helpful for stuff like qmake, desktop files, etc.
I would be willing to help with the documentation effort around it, but it is hard to judge where to start and if maybe anyone else is taking the same effort already.
Join #opensuse-factory on freenode, we're a helpful bunch of people and if you volunteer on writing down tips&tricks heard on that channel, even better! Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org