Current situation of amarok, and of latex tools

[Emmet Hikory]

Vincenzo Ciancia wrote:
<...>
> I see that when bad things about ubuntu are pointed out, typically you
> only get defensive answers by users. They all seem not to understand
> that, at least in my case, I usually *do* defend ubuntu against too easy
> critics, just like you. But if the problem exists, I'd like to see some
> developers just admit it. No, I am not asking for a public "apologise"
> as someone might imagine. I am asking a policy on regressions. I will
> probably ask for it in every release until the end of the world, but I
> still am not convinced that things are going well on that side.

    I'm an Ubuntu Developer, and I'm happy to admit that many packages
in Ubuntu are broken, and that there are regressions with every release.
 There's even some policies that discourage brokenness and regressions.
 Some of these policies are enforced strongly enough to cause complaints
from users who have some desire for a feature that was blocked in the
attempt to reduce regressions.

    I don't know the right balance between feature enhancements and
regression protection.  I'm not convinced there exists a correct
balance: each user has different priorities, and many of us have
different priorities for different packages (and sometimes different
priorities for the same package: seeking new features until personal use
cases are addressed, and then wanting the package to be stable from that
point forward).

   I also believe that regardless of what policies are set, they are
only as effective as the enforcement, and can only be enforced as long
as there is common consent amoung all those affected by the policies.
In the case of Ubuntu, where most involved in the process (whether as
bugsquad, or testers, or developers, or whatever) are volunteers, it
becomes a matter of providing a strong enough incentive that it's not
worth violating the policies.  Given the general thirst for new features
(else why bother ever upgrading), attempting to ensure no regressions
can significantly raise the effort required to do anything, which
reduces the self-perceived impact of the time spent by an individual,
which may result in reduced incentive to contribute.  Further, given the
wide range of environments in which Ubuntu is run, it's exceedingly
unlikely that any one person is able to fully test the implications of
any change (although we can try to get close): if the policy is strong
enough, it may even become impossible for someone to upload something
while remaining in compliance, which either means that everyone ignores
the policy, or that Ubuntu doesn't change.

    I do know that the only way we can make sure that Ubuntu works for
our use cases is to be involved.  I became involved with development
because my joystick didn't work with a game, and would encourage anyone
else who finds a problem to do the same.  I don't play that game much
now, but the vast majority of the things I do with Ubuntu happen to work
for me, simply because I spend time every cycle doing them with the
development releases.  I've forgotten to do some things some releases,
and sometimes I get regressions (e.g. in Intrepid, my joystick didn't
work with that game again), but that's a failure on my part, not on the
part of my fellow developers (only one has that joystick, and he doesn't
play that game).

    So for any of us, whether developers or not, if we use some
software, and want to be sure we can upgrade safely to the next release,
we need to be involved in the testing of that release, and we need to
make sure that we are involved in discussions of the solution.  Yes,
there are too many bugs, and yes, sometimes bugs get ignored.  The best
way to make sure that someone looks at your bug is to help make all the
other bugs go away (help mark duplicates or non-bugs, help make sure the
bugs have the right information, help provide workarounds or patches to
fix the bugs, etc.).  For those that have the time, doing a lot of this
will result in being a developer, but that's almost a side effect in the
goal of making sure that one's own bugs are solved.  (note that this is
but one of many reasons people become Ubuntu developers).

    It's also very useful to track the development releases.  Yes, this
*will* cause your system to have issues as large things change, but by
doing so, one can verify that one's critical use cases are all supported
in each release.  It's the only way to do it, really.  For those with a
critical need for their system to work, there are live images released
every few weeks during each development cycle that can be used for
testing most use cases (there are exceptions, like testing the impact of
the realtime kernel, where one must perform an install, but most use
cases can be tested from the live environment).

    Of course, there's lots of people who don't do this: this will
always be true.  And sometimes it's tempting to be amoung that number,
because it's a lot less effort, often for exactly the same results, but
it's only those that do it who make Ubuntu what it is.  Nearly anyone
who discovers Ubuntu Just Works probably has a machine that's a close
match to some user that is involved, and probably has use cases that
match those that are involved.  And of course the best way to make sure
this is a perfect match is to be involved oneself.

-- 
Emmet HIKORY