Reproducible w3m bug

[Sitsofe Wheeler]

Martin Olsson <mnemo <at> minimum.se> writes:
> 
> For the first bug I recommend that you upstream it. There is not a lot

That's an extremely useful reply and is the sort of information I could have
done with a few years ago. I won't follow that suggestion at the moment though
as prior to my original post I checked and upstream of w3m is not looking to
healthy -
http://www.sic.med.tohoku.ac.jp/~satodai/w3m-dev-en/200903.month/1112.html .

> of people in the Ubuntu project that fix bugs themselves, most people
> spend their time on packaging and integration (even though some people
> also do upstream work separately from their Ubuntu work). Filing an
> Ubuntu bug is nice for tracking (in case we have time to cherry pick
> it for release or maybe even do an SRU) but the bug report that really
> counts is the upstream one for sure. That said, there is also packages
> that are unmaintained and just as you point out sometimes it's just a
> waste of time; the fix is just to be careful about where specifically
> to invest your time.

That seems very reasonable but in that case can such packages where it is not
worth reporting bugs be marked as such? There's nothing worse than finding a
problem and then tracking it for years... That sort of wastage can be headed off
by a simple "Ubuntu only repackages this particular product - we will not do any
development or passing of issues upstream on it". It raises a question as to
whether it makes sense for those types of product to be in the Ubuntu launchpad
at all (other than for following upstream issues).

> Keep in mind that different packages have different number of users that
> are interested in having it fixed. Suppose Linux has 1% market share and
> that w3m has 1% of share among Linux users, now that's not a lot of people.
> People needs to prioritize between lots of different bugs/work and in that
> case fixing bugs in Firefox/Xorg/kernel (which is used by far more people)
> is probably more useful. It's not that people don't care about your bugs,
> it's just that there is so many of them that choices have to be made and
> priorities have to be set.

That's reasonable too but w3m is installed by default and if it's used by so few
perhaps it shouldn't be there by default - it strikes me as unsafe to be putting
packages that can't be supported on people's systems out of the box. Wouldn't it
be better to migrate to products that were actively maintained? Your comment
clearly stands for rrootage though.

And does Ubuntu really fix Xorg and kernel bugs above others? I had a kernel bug
that remained open for over a year which did not receive much attention -
https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/86099 . For me 9.04
is currently unusable on my EeePC 900 due to a Xorg / kernel issue -
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/349314 which is
currently unresolved. Does Ubuntu have developers doing active (new?)
development to fix it or is Ubuntu in a similar situation to others where it can
only wait for a fix to come from the Intel Xorg folks?

> As for the second bug, learning how to analyze and fix bugs is a long
> and hard process. It's not just about learning the immensely complicated
> ins and outs of gdb, VCS tools and compilers but it's also about learning
> the how the community works. Just as there is a technical learning curve
> there is also a community learning curve where you learn where to file
> bugs, who is the right person to ask, what info to include, which bugs
> are worth your time and so on. Both of these learning curves are in the
> "marathon rather than sprint" department so don't stretch yourself too
> far because you can't win on "strength" alone, you _need_ to be patient.

I've been waiting for years on some bugs. What sort of period is the marathon we
are we talking about taking place?
 
> The best way to do it is to make sure you work on stuff you think it
> _fun_ and interesting to mess around with, otherwise it just won't work.

I guess that's the major point. What I'm trying to say is providing extra
information will help people gauge the fun factor better. Helping to make a
product better seems fun but not getting feedback for years or repeatedly asked
to check whether a well described bug is still there is not fun. If people know
the later is going to happen they will be able to act in a better fashion from
the outset.