On 09/30/2010 01:35 AM, Stephan Kleine wrote:
On Thursday September 30 2010 00:39:36 Dave Plater wrote:
On 09/29/2010 09:58 PM, P Linnell wrote:
On Wednesday 29 September 2010 21:17:45 Dave Plater wrote:
Hi, I've been trying to submit an svn derived version of KTrafficAnalyzer to KDE:Extra, the package used to be in the old kde3 community repo and has been around in openSUSE for quite a while. It's been ported to kde4. I've been using the package from the authors home project and it occasionally crashed and lost the usage stats but after my recent update from KDE:Distro:Factory it consistently segfaulted on start up. This is a good thing that enabled me to track down the problem and patch it. It's now stable on a patched svn revision 44 so I decided to submit this very usefull package to KDE:Extra and am quite happy to maintain it as I use it all the time and it's a simple package only to have it rejected on the grounds that it's svn derived. This seems a bit stupid because the released package is unstable and even has a source forge bug against it from an openSUSE 11.3 user. I've had problems submitting a package fix to KDE:Extra before but in that case the maintainers reply was rather rude that issue was simply bad communication and was resolved and that particular maintainer accepted my second submit attempt of KTrafficAnalyzer pointing out that there wasn't a Url: in the spec file and asking me to fix it. I decided to patch the released tarball to svn 44 and submit that along with the fixed spec file but alas the first anti subversion maintainer caught the request and declined it. I was under the assumption that I'm helping to make openSUSE a better distribution but my encounters with KDE:Extra have made me think that that particular repository is an ego circus, it's easier to get a new package into Factory than into KDE:Extra, I've two new packages in 11.3 one of them totally new to openSUSE and one that the previous maintainer didn't have time for so it was dropped so I speak from experience. The point of this email are the questions :- am I flogging a dead horse trying to be a useful member of the community? Why do I get the impression that KDE:Extra is maintained a an exclusive club? Thanks for taking the time to read my rant. Dave P
Hi,
First, I was the one who sent a rejection about the missing URL.. It is more important than a simple single line.
I'm glad you picked it up, I usually use the url in the spec file to visit the home page of a package partially to find out it exists. A Url: in the spec file is a must and you responded to the request in the same manner that I would have. My gripe is about being directed from the first sr which was declined because the packages source tarball "appeared to be derived from svn.
Well, considering that when I looked at my mails today I saw like 10 SRs and revokes from you it doesn't look to me that you are very careful when creating them. Don't take it personally, happens all of us from time to time but makes it difficult from a reviewers perspective when being confronted with them.
That's me trying to do too many things at once but that's a good point, next time I need to submit a new package I need to slow down first.
As a reviewer, I feel _strongly_ I have
an obligation to ensure I and others can verify independently the all source code going into the distro, Factory, Contrib or in popular community repos like KDE:Extras. In fact today I filed an enhancement to automatically check for this in rpmlint used by OBS: https://bugzilla.novell.com/show_bug.cgi?id=642588
What I remind people when they are packaging stuff for the distro, especially when a novice is: "You are taking root, even oh so breifly, on a _lot_ of people's systems... proceed accordingly." Poor packaging is a very quick way to destroy the reputation of the openSUSE community and the distro. Now, OBS is brilliant in that it has automated a good deal of grunt work in the QA department, but still it takes a certain level of skill and applied policy to QA the end esults. Remeber the rule: Garbage In > Garbage Out...
One has to note Debian has a very solid reputation in this regard, even if one can debate some of their policies/techniques... They are _really_ strict about packaging and because of that they have a pretty high level of trust in the open source world.
Now, the second part has nothing to do with ego, but more a commonly agreed policy by the KDE:Extras maintainers, of which I am one, to not put any svn snapshots into Extras, but the place for those is KDE:Playground. Seems to me a sensible rule in general.
Confusing stable with svn is a mistake. The released version of this package is unstable, my patched svn version is stable. The only package that I maintain but don't use is lilypond. My criteria and what should be the main criteria is ensuring that packages published in reputable repos should be stable. The other important criteria is the components that comprise the package are of a consistent make up and the standard used is clearly documented so as the package can be maintained by any competent maintainer if need be, I might drop dead tomorrow and my unmaintained packages wouldn't be noticed until something went wrong. The only way to ensure a stable package is for that package to be used. For that to happen the package either has to be a well known and well used opensource package or it has to be discovered, failing this it needs to be put through it's paces by the person responsible for it's bugs. Sorry about the long winded qualifier of "Confusing stable with svn is a mistake".
That might be true for something like bespin which never did a release but only lives from SVN builds since the first day but considering that the last release of KTrafficAnalyzer was in august and upstream seems to use OBS then please contact upstream and or backport the fix for the crash.
I contacted upstream and commented in the source forge bug but I think it will be a while until I get a reply. Research of a new package prior to submission is essential.
As there is always room for well justified exceptions to rules, in this case, the best way to proceed would have been to mail the kde list or visit #opensuse-kde on IRC, before submitting and ask for an exception and explain the facts as above, as both Raymond, I or others would have most certainly followed up with questions or comments. The way it was presented to us via OBS, was missing this important info, naturally we would reject an SR like that. I've learned that Raymond is also a pretty skilled packager and he has done a ton of work to make the KDE repos really solid and offers end users a wide range of options to run the latest bleeding edge stuff or polished stable stuff.
I've had frustrating time with build service quirks in the osc source validator and long 24 hour publishing delays but maybe the main problem is that I tend to keep to myself. This is a chance for me to introduce myself.
Welcome :) If you have any questions or anything to discuss please just join #opensuse-kde or #opensuse-buildservice and talk to the people. Most of us hang out there at least a few hours a day (yes, we have a private life too ;D)
Also try "osc build" - that way you can try it locally without wasting resources on the server and if it works there it will also work on the server.
ATM my local resources are stretched, no spare space for build system, so online builds are neccessary. I was absent for about a month after 11.3 release and the web ui improvements are good but the osc source validator caused me to take 4 hours to ci the blender 2.54 beta package because I had %{version} in a comment, with a % before it. Also for some reason KDE:Extra ktrafficanalyser links to the home:viras package which caused update chaos for me, I haven't maintainer rights for the package so there's nothing I can do.
I for one would never dismiss your efforts to contribute to the distro. I know you have done a lot of bug fixes all over the place, so no issue there. What we have here is a simple issue of mis-communication or clash of communication styles. nothing more. I suspect you do not visit IRC often as it is another important channel of communication for members to hash out these kinds of things... I hope you can join us there when time allows as well.... We're all a pretty friendly bunch. :)
I'm not that familiar with irc unfortunately and my only serious attempt at communication with the core testing team of which I'm a non practicing member atm was met by either silence or there was some strange quirk in the irc client I was using.
Simply open konversation and join one of the above channels and talk to us ;)
I've just installed konversation, the other irc clients I have are old hope konversation is easy to drive.
I hope that puts some clarity on why things were done the way they were... Nothing evil... just good folks misunderstanding things...
Peter
I was met with miscommunication when I first tried to submit a fixed yawp to KDE:Extra and another policy I couldn't understand, it was rejected because I had included a sub package to be used in case of bugs which are very hard to troubleshoot in plasmoids and these "unittest" binaries would make it a lot easier to find if the bug was kde or yawp related.
As I told you in our private exchange that is not true. While I wasn't that "delighted" to see unit tests packaged I declined it for the following reasons (as I told you so you should know them):
1. Trace logging is IMHO not acceptable for a public package since it - potentially - produces too much crap that just fills the disk.
2. The main reason was that you practically forked the %cmake_kde4 macro instead of using it properly.
Finally you agreed - or that is what I understood - so if there are any open questions please raise them on this list (as I told you before).
The debugutils are small and they enable the configuration and communication aspects of yawp to be tested without plasma. You must have been feeling the same as I did when I started this thread when I first submitted yawp :-)
I'll give the irc a try again but the reason for this message is to promote a discussion about version controlled packages being stable. It gets lonely out here, would be nice if someone visiting Cape Town looks me up, I seem to be the only one with an openSUSE T shirt. Dave P
Last but not least, regarding the "KDE:Extra seems to be some ego trip by a handful of people" remark:
You totally can rest assured that every single one of us has better stuff to do than dealing with those SRs. OTOH we all said to do that to raise the quality of that repo and thereby agreed to play by the rules (e.g. releases only with hand selected exceptions - as said bespin is an example) (FWIW that policy got established after the old KDE4 Community repo got fucked up several times - the last time someone included a new Qt version and thereby fucking up pretty much every user of said repo which lead to rethinking the policy.). Point just being we neither use all the packages in :Extra nor do we have the time and the hardware to test every single SR on all repo combinations so stuff like your issue simply happens.
This is neither meant personally nor to pump up our egos but merely cause that is the current policy.
As said before, if you run into such troubles please simply join #opensuse-kde on IRC @ freenode and talk to us. Probably most stuff can be fixed there.
Thanks for understanding, Stephan
I apologize for the "ego trip outbirst" it was out of line. Hopefully irc opens up a line of communication with build service especially, the mailing list sometimes ignores reports of bugs and I will try and resolve issues with packages on #opensuse-kde and I thought I saw a link to kde packaging conventions somewhere else in this thread. Only plasmoid-yawp and KTrafficAnalyzer are what I consider essential packages for myself so I will continue to maintain them aggressively if they don't work. I share a 50G internet account and use a motor bike for transport, Cape Town has extreme weather :-( Regards Dave P -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org