Éric Miclo wrote:
> Le 14 juil. 2010 à 17:17, Richard Gaskin a écrit :
>
>> FWIW, yesterday I read all 153 RQCC reports that come up when
>> searching for "Linux":
>> <http://quality.runrev.com/qacenter/buglist.cgi?quicksearch=Linux>
...
>> Of those 153 reports, only two mention "print" in the subject line,
>> one of which is being investigated by the team as I write this
>> (7017) and the other noted by the submitter as having a simple
>> workaround (8477).
>
> Hello Richard,
Thanks for chiming in here, Éric. After reading all those reports and
finding you'd submitted a good many of them, I was impressed by the
effort you put in and the level of detail offered where it was useful.
Thanks for posting those.
> What makes you say that bug #7017 is under investigation by the team?
I had a correspondence with Kevin about that on Monday, shortly after he
let me know that the team fixed another Linux bug:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=7490>
They really are making a good effort to do what they can on the Linux
engine, even if it's not very visible between releases.
There's not much money coming in to Rev from the Linux community right
now, and relatively few Rev developers even port there, so I believe
it's safe to say that Kevin, Mark, Ben, and the rest of the team are
putting in a disproportionately strong effort to make the Linux engine
as good as they can within the constraints they work in. I can't
reasonably ask for anything more than that.
> It is still unconfirmed since 2 years.
>
> Bug #8477 is unconfirmed too.
True, as well as for #7490, even though it was fixed a couple days ago.
As Jacque has noted here many times, the RQCC is a part of their
workflow process but not all of it. Internally they use different
systems for tracking progress, updating the RQCC in batches as time permits.
You'll notice that every few months Oliver goes through the RQCC and
marks dozens of things fixed in the span of a few hours. It's not that
the team was sitting around drinking for months and then suddenly got a
burst of energy and did everything in one day, but just that the system
that helps them best internally is separate from the public convenience
they provide in the RQCC.
Very few companies provide a publicly accessible database of known bugs
and possible future features, and for good reason: the features feed
competitors, and quite of few of those bugs are experienced by the
majority of Rev developers only by their visibility in the RQCC and here
on this list, but are not actually experienced for themselves in using
the product. So public bug lists can become a noise factory that can
make a product look worse than it is (can you imagine how outraged Mac
users would be if they had access to Apple's internal bug database?).
This thread is a good example: so far, from what I've read only two
users have experienced this issue with copy-and-paste, and thus far
there's been no repeatable recipe which would allow others (such as the
Rev team) to reproduce the bug.
But even though it appears to affect only a few users, every member of
this list has been reading dozens of messages about it. The perception
of the bug far exceeds the actual scope of affected people.
This is not to suggest that we shouldn't have such discussions. Of
course we should, even for things which don't effect most folks, like
the rounding errors discussed here at length some years ago which led to
a new function (statRound) that addressed a long-outstanding HyperTalk
limitation. Same thing with integers as dates, now allowed in large
part because of the productive conversations here.
That's really the key: "productive". As long as a thread sticks to
presenting an issue and exploring ways to arrive at a recipe for it, I'm
a happy reader and an eager participant. But once it strays off into
the weeds of how to run other people's companies, I lose interest pretty
quickly.
I run my shop, Kevin runs his. We both like it like that. Any time we
spend together is done in the spirit of partnership in which we look for
ways our efforts can be coordinated to further our mutual goals. We
don't call each other names, we don't waste each other's time on
distractions. We have work to do, he in his office and me in mine.
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
