EngineController borked

[Dan Meltzer]

On Tue, Feb 10, 2009 at 1:42 AM, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Mon, Feb 9, 2009 at 3:00 PM, Dan Meltzer
> <parallelgrapefruit at gmail.com> wrote:
>> On Mon, Feb 9, 2009 at 8:59 AM, Mark Kretschmann <kretschmann at kde.org> wrote:
>> But feel free to try fixing it, my head's already exploded twice from
>> touching that code, I'm not all that eager to do it again
>
> The main problem with this is that we simply can't afford such
> horrible regressions any more. To make this clear: I'm not blaming
> anyone here. For all we know I could have caused the regression
> myself, or a gnome hacker, or the tooth fairy. Who's responsible for
> it doesn't really matter.
>
> The thing is just: It needs fixing soon, one way or another. We are
> now working with commercial partners who are partly using Amarok trunk
> (if that is a wise move is debatable, but it's a fact), and that means
> that someone (me) will have to spend the next days almost exclusively
> on fixing this bug, and also the crashing on exit (both are
> unacceptable).

Unfortunatly, there is absolutely no way to make changes to the
enginecontroller without introducing the possibility of regressions,
there are way too many code paths, and way too many backends and way
too many combinations of things that may or may not occur to be able
to know, with any certainty, that a commit makes things definitavely
better or definatively worse.

This is one of the reasons why trunk exists.  To get more testing for
possibly dangerous features before they get released to a wider
audience.  To randomly (and without warning, I might add) change
trunks policies from a place where development happens to a place that
is apparently expected to be as stable (if not more) than the released
version, because it has to work for our "commercial parteners" (which,
I might add, are some huge secret and, to be honest, completely
tangental to the open source development which Amarok works under, I
didn't sign up to do my work for a company, and a company should not
drive the development of Amarok, sorry) is something that at the very
least needs to be discussed in detail on the mailing list before it
happens.

That being said, the only change I currently have left in
enginecontroller land that differs from previously, is removing the
slotPrefinishMarkReached, which was necessary because it resulted in
duplicate statistics.  Reguardless, this bug exists in 2.0.* (as you
know from the bug report) so it's clearly not a trunk regression.

Dan,
>
> In the end I guess I just want to ask you all to be a little for
> careful with your commits. Shit happens, and mistakes happen to the
> best of us, but if possible let's try to prevent doing it too often.
>
> --
> Mark Kretschmann
> Amarok Developer
> www.kde.org - amarok.kde.org
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>