aRts in trunk
charles at kde.org
Fri Jul 29 21:47:56 BST 2005
On Fri, 29 Jul 2005, Scott Wheeler wrote:
> On Friday 29 July 2005 20:52, Charles Samuels wrote:
> > Yes, that's because it works.
> Wait -- you changed arguments. You said you needed it there because you
> wanted to be able to work on it, but then said you don't work on it because
> it doesn't need it.
Ack, let me try again. aRts works: it is currently, as far as I can tell,
the best working solution to media playback for the purposes of Noatun.
If I choose to add a feature that exposes a bug in arts, then I need to
fix that bug, obviously. Or maybe to add a feature.
> 183 open bug reports, most of which have no hope of ever being resolved tells
> a different story.
How much software do you know is perfectly flawless?
> > Cleaning it now, and cleaning it up "in the next few months" is all the
> > same thing. If you don't want it, don't check it out, it doesn't hurt you
> > at all.
> > I'm aware of that, but it's not an option for a lot of my needs anyway,
> > I've discussed that at length on this list. You ignored my complaints
> > anyway.
> Matthias actually did note the concerns that you mentioned and has made an
> attempt to address them in the current API. That's been mentioned here. I'd
> look at the current state of things and see if that's still the case.
> > > If by "you" you mean "pretty much everyone in the KDE community", then
> > > yes, we mostly have. Stefan has said he won't maintain it further.
> > > Matthias has quit using it completely. aRts is dead.
> > I'm still using it. Since I am a member of the set "everyone", you just
> > lied. You are so emotional about hating arts that you don't see how it
> > doesn't change anything at all for you to keep it in there.
> Come on Charles, this is being silly. You can nitpick word choice all you
> want but my point was clear (and I would say the "pretty much" was an
> appropriate qualifier, not that it matters at all).
Ok, I concede, I went a bit far with my reply, but as well, you saying
"pretty much everyone in the KDE community" is a pretty silly argument as
well. The fact remains that it's still a very good solution to various
problems. Even you said that "aRts is more mature than aKode as a
The point is that "pretty much everyone" is wrong because they've been
fudded so much. Arts works just fine for many tasks.
> I don't see where I've been particularly emotional. aRts is not maintained;
> it hasn't been maintained for years. It needs to be maintained and nobody is
> willing to do that. There are alternatives that are maintained.
You want to throw it away the instant you can, for no reason what so ever.
There's no reasonable explanation for that other than your feelings for
arts. It'd be less effort for you to just leave it alone right now, but
you'd rather get into this debate about removing it from trunk, to my
dissatisfaction- this tells me that you want to see it gone now because
you really really dislike it.
> If you're actually volunteering to maintain aRts -- great. I still don't
> expect that the KDE project will ship it with their releases in KDE 4, so
> presumably that'll also include doing releases of aRts independently.
I don't expect KDE will ship it either, but I wouldn't be shocked if
nothing particularly better comes along. This is why I'm saying that it
should be kept. I still need to use and develop noatun, and I cannot do
that without a backend, and until another backend comes along that is
usable, I will need arts, and for that reason alone, it should remain
where it is.
> And note that I haven't discussed removing it from svn -- it will stay there.
> I've discussed removing it from trunk, since I don't expect to see further
Trunk is the correct location for it, at least until I'm sure I don't need
Again, if you don't want it, don't check it out.
> > (1) Yes, Allan, I didn't report them, sorry. It's probably more "by
> > design" than a bug though. If you want to talk about it, we can do it
> > later, currently I'm busy.
> > (2) aRts has been FUDed heavily by KDE developers (more than anyone),
> > which just sickens me.
> > I've heard things about "high latency" which is totally bogus, that it's
> > less stable isn't right either, on the basis that it's as stable as akode
> > is, and at least in that case, it's out of process, so the user will
> > hardly notice if it does crash. You're all so wanting to throw it out that
> > you refuse to admit to even its most tiny advantages. You don't even use
> > it so you don't know how it is.
> aRts is more mature than aKode as a standalone backend. Depending on your
> setup, it often works better than GStreamer. But in the cases where it has
> problems, which are many, there's nobody left that has any interest in fixing
> those and there hasn't been for a few years. There's a future in the other
> systems; there's not in aRts.
I'm not defending it as something to be part of KDE4. I need it now for
development, and I may need to modify it now for development.
> At any rate -- trying to move towards some resolution. What would you say of
> keeping aRts in trunk on the condition of you taking over maintainership of
> it? And by that I don't mean just slapping your name on it -- I mean real
> maintainership. Are you willing to do that? Even though we won't release it
> as part of KDE 4, I don't see any reason to evict it from its present home in
> SVN, but I'd like to see you decide between, "It works, it doesn't need
> anything more" and "I want to work on it". In the prior case I don't see any
> reason for it to be in trunk.
There is really nothing I could do with it right now. It truly does work
perfectly for me. I could say that I'd apply patches if someone sends
them. But most importantly, I am saying that "I /may/ want to work on
it." I've never been hesitant to make commits to it if I needed to and
that won't change. If it stops compiling with GCC 3.14159, then I'll fix
I don't see any point in fixing its 183 bugs it has given that I know that
I likely won't be using it in a year. That one year is the time I'm
So here's a compromise: we leave it as it is, and when an alternative
works throughout all of KDE, then we can move it out.
More information about the kde-multimedia