Comment 39 for bug 346095

On Fri, 17 Apr 2009 22:30:51 -0000
jucs <email address hidden> wrote:

> you're absolutely right that I did not use the best way to spread my
> changes. But still, I'm not sure, if it would be such a good idea to
> put this up here openly - even though I think I didn't do any harm
> (such as memory leaks or so), I'm sure the developers would kill me
> if they saw my code.
>
> Maybe I'll find the time to make things at least a little more polish
> (I'd start with giving variables the right names, they still refer to
> top corners). But I'm sure those with little more C knowledge and
> knowledge of that project could do that a big lot better.

Even just a bzr branch would be good, then some of us with less time
that could use a starting point might be able to take five minutes and
look it over. That's better than nothing. :)

> I think I should also say something to your criticism. Of course this
> not a feature (a configuration file doesn't do any harm). But I still
> consider open source software as a present. And actually, I think
> those bubbles aren't done too bad (if we didn't like them, we'd all
> be free to use the old notification daemon).
>
> I don't think it's fair to be so hard on those developers. We've still
> got every possible choice - first, we can avoid their software and
> second, we can just alter the source and do whatever we want.

I do try not to be hard on people. That said, this notify-osd ordeal
has been one issue after another. For example, they made it hard to go
back to notification-dæmon, because they made ubuntu-desktop depend on
notify-osd. That means that "apt-get --purge remove notify-osd" yields
in not having the ubuntu-desktop metapackage, which means that if they
make updates to the set of required software for the desktop, (e.g.,
add new conflicts or anything like that), those updates cannot be
received. Someone had to go out of their way to add that dependency,
and that means that they had to think about it.

I wouldn't be mad at _all_ if the bug report would have been accepted.
I wouldn't be mad at all even if the response was, "You know what, we
can't get to this now, but we'll look at it for Karmic." I wouldn't be
mad if the response would have been anything more than that, either.
However, the initial (and continued) responses have been such that it's
nearly like I don't matter. I realize that I am nearly statistically
insignificant in the sea of Ubuntu users, but the treatment I have
received on this bug report is something that I would expect from a
corporation who doesn't care about its users, not from a company that
is working on open source, community-oriented software and whose goal
is to try to improve the reach and quality of that software.

The problem is compounded by the fact that of late, many real issues
are being summarily rejected---or worse, ignored---even amazingly
stupidly simple issues that _already_ have fixes available for them. I
fixed an issue, for example, in Hardy that only just a day or so ago
was finally pushed into Hardy. I submitted the fix for that a week or
two maybe before Hardy was released, or maybe a week or two after, I
can't remember now. But it was to fix a metapackage that was
uninstallable. Yet again, in Jaunty, the same one is
uninstallable---and it's probably just a single-line change to resolve
the broken dependency in the tree, but it's being ignored.

The quality of the distribution is suffering as a result of this.
These are all problems that a very viable solution was promised for and
never delivered---having a continual-development rolling-release would
lower the bar in terms of requirements for fixing such minor issues and
create a much better turnaround and higher-quality testing in-between
releases. Grumpy Groundhog was supposed to be just that, and that idea
never materialized for whatever reason. But if it had, there'd be a
much larger, more persistent testing base of users who would be able to
report bugs more quickly (closer to when they were introduced into the
system) and when it came time for a release, all that would need to be
done is to have the new release be branched from a stable high-point
in the rolling release. It'd make releases easier to test, because
they'd for the most part _already_ be tested. And stupid issues like
usability issues and packaging bugs would be ironed out long before the
first alpha, if not the first beta.

The (very real) inaccessibility of notify-osd isn't the straw that
broke this camel's back. The treatment as a result of filing the bug,
and seeing the treatment other users that have brought up similar
issues with it have received, _that_ was.

> Oh and I'm sorry for my English ;-)

I was able to understand it, so it wasn't that bad. :)

 --- Mike

--
Emacs is an acronym for Escape Meta Alt Control Shift.