On Thu, 2010-07-08 at 16:22 -0300, Bernardo Barros wrote: What it means is: There is a great opportunity for media/sound geeks to get a place in the hall of eternal internet fame by stepping up as package maintainers. :-) -- birger

On 09/07/10 05:10, Niels Mayer wrote: Hi fellow fedora music list users, As you can probably imagine, open source developers and maintainers generally work for free, in their own time. Many Fedora packagers, have lots of packages to look after. Even for those people (like myself) who have only 10 packages, it takes a serious amount of time to package applications to be of a useful quality for Fedora. And that is just to get the packaging technical side done, and doesn't include the detailed QA that could or should be done on actual application operation if there was more manpower. You might like to take a look a Fedora's Bugzapper/ QA process at: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow As you note, many submitted bugz involving audio are still in their "new" state. This really just means that no one has had time to look at them at all yet. For ones I'm interested in, reproducibility is the key problem. Either there is no information on "how" to cause the issue, or when followed, the same bug does not occur. An extra challenge for me working on audio apps is that my new hardware has audio issues during record attempts, that means that even if I do get a crash, it's entirely different from the crash reported ;-) In this case, I can't reliably confirm the crash, nor can I say that it isn't reproducible; with more info or different hardware, it might be... I prefer not to say this isn't a problem (by closing the bug). Where to from here ? People. With time. And you can be one of them ! There are many areas to work on, whatever interests you: - bugzapping 1: take a look at audio bugz filed by other people and try to reproduce the same fault. If you can, move the bug into 'triaged' state. Otherwise comment that with audio hardware X, version Y, this was not reproducible. Make it a personal challenge that for each bug you submit, you also triage another bug ! - bugzapping 2: for a triaged bug, retest with the latest version from -updates-testing or rawhide, is it still reproducible (state the version). Still have time ? Rebuild the package with the latest upstream release version (or even CVS), and retest. Place advice that this is or isn't fixed in the upstream version in the bug, so that the package maintainer can see that version Z specifically resolves this issue. - active packaging: well, we can see that you spend a lot of time playing with audio apps, including compiling from source, or using rpms from other distros. It isn't much of a jump to knocking existing rpm specs into shape (by reading the packaging guidelines, and asking google / questions). Create the package review request, let us know on the music list that you have a package ready to go, and we'll do what we can to take it from there. - active bug fixing: get intimate with the upstream code base, work out whats happening, how to fix it, post patches to the upstream project, test the result. - documentation: add pages within your personal space on the fedora wiki dedicated to specific tasks... Anyway, perhaps some of this has been useful, or even inspirational, and we look forward to many new contributors crossing the small divide from open source consumer into creator / producer ;-) (Sorry if you already have). Cheers, David Timms.

Also tired of "Warning: Unable to create "trees" RDF storage.//Performance can be improved by upgrading librdf" and inspired by Simon's message, I asked about the issue on #kde-fedora there's the possibility of advocating on this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=565329 ("openoffice dependency on old redland / raptor / rasqal versions") as well as in other specific bugs we file on packages part of fedora that could be affected. Note conversation below from #kde-fedora.... lets please help move this issue along by filing bugs, and providing good information on existing ones, and please note the offer made to me and all of us complaining here -- file bugs and make it clear why this is important, and http://fedoraproject.org/wiki/RexDieter ) will be on the case for advocating a fix on this issue for F12. .................... [10:58] <npm> Requesting update to redland 1.0.10 from obsolete/slow 1.0.7: https://bugzilla.redhat.com/show_bug.cgi?id=496323 https://bugzilla.redhat.com/show_bug.cgi?id=562645 https://bugzilla.redhat.com/show_bug.cgi?id=610181 [11:00] <rdieter> npm : you're asking the wrong people, I'm for it, but we need buy-in from others too (like ooo) [11:06] <rdieter> .bug 565329 [11:06] <zodbot> rdieter: Bug 565329 openoffice dependency on old redland / raptor / rasqal versions - https://bugzilla.redhat.com/show_bug.cgi?id=565329 [11:06] <rdieter> npm: ^^ I asked for feedback from ooo maintainer(s) here. we can see what they have to say [11:07] <rdieter> npm: I'm curious, you keep mentioning that an udpate is required for multimedia apps.  do you have details?  which apps, what are the problems?  (and ideally, are these issues being tracked via open bugs ? ) [11:10] <npm> anything that uses plugins uses RDF to describe the plugin: two leading examples: ardour.x86_64     2.8.10-1.fc12 @updates    .... qtractor.x86_64     0.4.6-1.fc12 rpmfusion-free-updates [11:11] * npm wonders if oget has something to say about this [11:13] <rdieter> npm : so... no bugs yet? (hint hint) :) [11:13] <npm> rdieter: in addition to ardour, qtractor, possibly kdenlive [11:14] <oget> npm: the OOo guys don't want to switch to the new redland. They don't consider it stable in F-12. However, for some reason, they consider it stable in F-13. [11:14] <npm> i was trying to figure out a way of listing my apps with the library dependency [11:14] <oget> npm: that's the reason they put in front of us [11:14] <npm> that sounds bogus [11:14] <npm> as reas [11:14] <npm> on [11:14] <npm> just when i thought i had absolurtely no reason to switch to f13 yet :-) [11:14] <rdieter> well, maybe stable enough for f13, but want to play it safer for f12. [11:15] <oget> so far nobody was able to convince them. I tried, Simon Lewis tried, Kevin Kofler tried... [11:15] <npm> interesting ... [11:18] <npm> oget / rdieter : well it's nice to see the kde-side of the house at least trying to handle this kind of stuff... this came up because i'd complained that media-related issues go into /dev/null, except if they're kde related and then at least people acknowledge the bugs [11:20] <rdieter> ok, maybe being clearer about what the problems are, and documenting (via bugs whatever) may help convince them. [11:20] <npm> http://article.gmane.org/gmane.linux.redhat.fedora.music/547/match= [11:20] <rdieter> Until I asked just now, I wasn't aware of the details involved either. [11:22] <npm> i think the rest of fedora ought to be following your model of quickly acknowledging and communicating about bugs.. vs... ones that stay in "new" forever, and end up being my own personal micro-blog about a particular issue [11:23] <rdieter> sure, agreed.  for some pkgs and maintainers, it would seem they have other priorities or need help wrt bug triage. [11:23] <rdieter> heck, we all could use more help when it comes to that [11:24] <Kevin_Kofler> F13 already has a redland with the current sonames (unless upstream bumped them again). [11:24] <npm> they need to be told there is a model that includes "triage" and de-deplicating in the first place, it seems. [11:24] <Kevin_Kofler> Only F12 is affected. [11:24] <Kevin_Kofler> I think we should just update Redland and then tell them to rebuild OO.o or even just do it ourselves. [11:24] <npm> yes [11:24] <Kevin_Kofler> They more or less gave us permission to do that, even though they complained about the plan. [11:25] <rdieter> Kevin_Kofler: if it were anything not as big and visible as ooo, I'd be tempted to do just that [11:25] <Kevin_Kofler> (They said "if you decide to bump the lib, we'll rebuild, we have no other choice anyway, but we don't like it" (paraphrasing).) [11:25] <rdieter> has the redland maintainer commented here at all? [11:25] <npm> it would be nice... the thing is, performant audio and video apps are a "big and visible" just not in an area that redhat may care to invest in [11:26] <rdieter> if we can get a definitive statements something like "redland-1.0.7 is junk, yes upgrade already!", then justifying things will be a lot easier [11:27] <Kevin_Kofler> Uh, who is the primary maintainer? [11:27] <Kevin_Kofler> .whoowns redland [11:27] <zodbot> Kevin_Kofler: thomasvs [11:27] <Kevin_Kofler> Thomas is one of those "almost but not quite AWOL" maintainers. [11:27] <Kevin_Kofler> I don't think he'll reply, ever. [11:27] <npm> i believe i saw the behavior of the very-long wait on redland rdf scan the first time i ran 'gst123' on a computer ... something in gstreamer (memory fuzzy on this) was invoking it, i believe [11:28] <npm> or perhaps it was the app that had plugins... first time, or on change, i think you see a terrible performance hit, as if the app isn't working [11:28] <npm> but in fact if you wait long enough, it starts up, after scanning directories of plugins that use rdf to describe themselves [11:28] <rdieter> npm: ok, make you a deal, document all the badness with various apps using redland-1.0.7 (preferably via bugs) [11:28] <rdieter> and then I'll make the case that an update is crucial [11:28] <rdieter> and work to make it happen [11:29] <npm> excellent. in order to enlist help, can i re-post this conversation to the fedora-music-list ? [11:29] <rdieter> tis ok with me [11:29] <npm> thank you.... you all rock! [11:30] <rdieter> npm : you rock too, sorry your persistence took this long to pay off. :) [11:31] <rdieter> with all the different players and moving pieces, it's hard to see the big picture issue(s) here.  hopefully, we can fill in the blanks, and get everyone on the same page and working together. [11:33] <npm> excellent.... this is the way opensource is supposed to be! [11:33] <oget> rdieter: bugs 565329 and 591841 contain most of the discussion. I don't want to update redland on F-12 without their approval. No need to breed hostility. [11:33] <rdieter> .bug 565329 [11:33] <zodbot> rdieter: Bug 565329 openoffice dependency on old redland / raptor / rasqal versions - https://bugzilla.redhat.com/show_bug.cgi?id=565329 [11:33] <rdieter> .bug 591841 [11:33] <zodbot> rdieter: Bug 591841 Please, please, please update Redland > 1.0.8 - https://bugzilla.redhat.com/show_bug.cgi?id=591841 [11:39] <rdieter> in bug 565329 , luis backported some of the important changes to redland-1.0.7 it seems, maybe we can just use that? .......... Niels http://nielsmayer.com PS: Incidentally, this is not an issue for F13, which may be a reason to ditch the comforts of F12 and into the wilds of F13 ... or it may be a case for running the f13 redlands lib on F12 (??) and uninstalling openoffice and install koffice instead.

On Thu, Jul 8, 2010 at 3:10 PM, Niels Mayer wrote: As David pointed out, most of us are like you guys, working on the project in our free time. There are a couple points you might want want to know: - Becoming a Fedora project contributor does not require programming knowledge other than bash scripting. There are many package maintainers who cannot debug code. - Many package maintainers maintain a large number of packages, and as you would expect some of these packages are not their favorite packages. They don't have the time to deal with all of the bug reports. I personally get all these ABRT crash reports from audio and nonaudio packages that I maintain. I am giving my best effort to keep in contact with the developers and the users to get the issues resolved but I still have many open bug reports, that I didn't get a chance to go over. We are trying the best we could provide, which is obviously not perfect. - I am not particularly happy with this new ABRT mechanism. It seems nice for a user. Click a few buttons, and you submit a crash. It sounds like you did your part of the job. However, the package maintainer might not be familiar with the codebase, might not even know the programming language the software is written with, or simply might not know how to program or debug. Even if the maintainer is a programmer, it will take time to decipher the code and find the source of error. It would be best if these crashes were reported upstream to the software developers, the people who actually wrote the code. Unfortunately, ABRT does not support this. And the way it is set up, I am afraid the users will be more reluctant to contact upstream developers, since they think they already submitted a bug report. - When you report a bug, think about why you are reporting it. There is some dis-functionality that is bugging you. But the bug is still there because it doesn't bug the package maintainer as much as it did you. Now, if this dis-functionality was bugging the package maintainer to the same extent, what would he do? He would contact the software developers and try to get things fixed. Therefore when you are submitting a programming bug, you are expecting the package maintainer to play the middle man, to carry the information back and forth between you and the developer. This is simply inefficient. - My own rule of thumb is, * Submit the bug to upstream developers if the bug is in the code. * Submit it to Fedora bugzilla if it is a packaging bug. * Submit it to Fedora bugzilla if I am not sure if it is a packaging bug or bug in the code, and ask the maintainer if I should submit this bug upstream. - The best bug reports (we don't get these very often but they are very very cool) are, when the user already submitted the bug upstream, and he got a patch that fixes the issue. When patches are submitted to Fedora bugzilla with the upstream reference, they will probably be included in packages very soon. My own couple of cents, Orcan