Ardour - support only for official builds?

[English Guy]

breathtaking

Now it only I could write the breathtaking music that I dream about...

You and me both......

[Michael Willis]

You and me both......

Deal. Let's work on a project together.

Ehh... First I should ask what styles you prefer...

[rghvdberg]

You and me both......

Deal. Let's work on a project together.

Ehh... First I should ask what styles you prefer...

Now this is a thread derailment I thoroughly enjoy

[GuntherT]

I am calling BS here.

The Ardour bugtracker has 2600+ open entries some that are untouched for 10y+ years.
http://tracker.ardour.org/view_all_bug_ ... _number=54

This is not how a healthy open source project looks like. This is not how Professional Support looks like.
I don't think Ardour support is anywhere where it claims to be. The bug tracker is a graveyard & this gives a bad image of the project.

If the particular build is not supported, or if support is only provided to paying subscribers (or against a bounty) - it shouldn't be that hard to manage customers expectations. Choose a support policy, communicate it to your users and apply it.

Not triaging bugs is discouraging for bug reporters, regardless of the support status of the build their are running.
It is also probably not helping visibility for the devs to spot hot issues.

I get that developer time is scarce, and no one likes to do support - fair enough.
But seriously, it doesn't take a genius to clean up a bug tracker: close everything opened up to version N-1 with a polite canned answer.

Example:

Code: Select all

"Dear reporter, the entry you opened affected an older version of Ardour, and we have to assume it is not relevant anymore. 
Therefore we will close the ticket as part of our great autumnal bug tracker cleaning initiative.
Should the issue you reported be still actual, please accept our apologies and open a new report against the current stable/Supported version of Ardour".

Close the stuff that is not going to get fixed, & start fresh.
Take one hour or two to do that once a year (set up a google reminder if that's too difficult), no one gets harmed.

If that's all it takes, why not reach out to Paul and Robin and offer up an hour of your time each year to take care of that for them? I'm sure they'd appreciate the help.

Side note, the developers have chosen a support policy which they apply and communicate to users (over and over and over again), so I don't follow your point there.

[tramp]

I am calling BS here.

The Ardour bugtracker has 2600+ open entries some that are untouched for 10y+ years.
http://tracker.ardour.org/view_all_bug_ ... _number=54

This is not how a healthy open source project looks like. This is not how Professional Support looks like.
I don't think Ardour support is anywhere where it claims to be. The bug tracker is a graveyard & this gives a bad image of the project.

If the particular build is not supported, or if support is only provided to paying subscribers (or against a bounty) - it shouldn't be that hard to manage customers expectations. Choose a support policy, communicate it to your users and apply it.

Not triaging bugs is discouraging for bug reporters, regardless of the support status of the build their are running.
It is also probably not helping visibility for the devs to spot hot issues.

I get that developer time is scarce, and no one likes to do support - fair enough.
But seriously, it doesn't take a genius to clean up a bug tracker: close everything opened up to version N-1 with a polite canned answer.

Example:

Code: Select all

"Dear reporter, the entry you opened affected an older version of Ardour, and we have to assume it is not relevant anymore. 
Therefore we will close the ticket as part of our great autumnal bug tracker cleaning initiative.
Should the issue you reported be still actual, please accept our apologies and open a new report against the current stable/Supported version of Ardour".

Close the stuff that is not going to get fixed, & start fresh.
Take one hour or two to do that once a year (set up a google reminder if that's too difficult), no one gets harmed.

If that's all it takes, why not reach out to Paul and Robin and offer up an hour of your time each year to take care of that for them? I'm sure they'd appreciate the help.

Side note, the developers have chosen a support policy which they apply and communicate to users (over and over and over again), so I don't follow your point there.

@GuntherT
To me it looks right what gimmeapill wrote here. And, I ain't get it as a critic in a negative sense.
Talking for my self, it is indeed encouraging when I would report a bug and see there a endless list of unassigned topics.
The mantis bug tracker is, according to the Ardour dev's, the way they prefer, so a bit maintaining on it wouldn't harm.

[raboof]

The Ardour bugtracker has 2600+ open entries some that are untouched for 10y+ years.

Not triaging bugs is discouraging for bug reporters, regardless of the support status of the build their are running.
It is also probably not helping visibility for the devs to spot hot issues.

I get that developer time is scarce, and no one likes to do support - fair enough.

This is of course obvious - it would be better if issues were triaged more closely, no one would argue with that. But there's only so much time in the day, and I don't think we should be harsh on maintainers because they might not be spending their time on the things you'd like them to spend time on.

But seriously, it doesn't take a genius to clean up a bug tracker: close everything opened up to version N-1 with a polite canned answer.

You seem very opinionated that this is the "correct" way to use a bug tracker, but this is not obvious. It is certainly a valid approach, and if you want to take it for your project that's great. Leaving unresolved issues open, though, can also be a valid approach.

A short bug list can seem satisfying, but if that means each time I have a problem I find my problem in an 'old' issue that was 'closed due to inactivity', that is pretty frustrating as well. Have we really improved in that case? Also, a 'bug tracker' is also commonly used for feature requests. I think it's fine to have a feature request open for a long time that is an interesting idea, but has nobody currently interested in implementing it.

Of course even given this, the Ardour bugtracking could use some more triaging (it's even being plagued by spam..). But I don't think it's fair to be so dismissive of it, and downplay the amount of effort that is needed to do this well.

[gimmeapill]

If that's all it takes, why not reach out to Paul and Robin and offer up an hour of your time each year to take care of that for them? I'm sure they'd appreciate the help.

One hour for someone actively involved with the project.
I already thought about it, but I'm not even an active user at this point (although I did donate somewhere in the past).
Getting to the level where the main devs trust an outsider enough to give him/her the keys of the bug tracker would probably require a few dozen hours of forums and support activity - if not hundreds.
Sorry, but I don't have that kind of time to spend at the moment (this may change in the future, who knows).
No, realistically, such a cleanup would be better done by Number 3 - whoever that is.

It is not to say that my involvement with Ardour is completely nihil though.
I still maintain a pkg build in the Arch User Repository and check out from time to time what is going on (Paul's newsletter is great for that btw).
https://aur.archlinux.org/packages/ardour-git/

So my interest here is actually on the same level as Qtractor
https://aur.archlinux.org/packages/qtractor-git/

(But I won't comment on the support level provided by rncbc, that wouldn't be a fair comparison to Ardour)

Side note, the developers have chosen a support policy which they apply and communicate to users (over and over and over again), so I don't follow your point there.

And does it work?
Obviously, there is some room for improvement if they have to do it "over and over and over again".
This is exactly my point: What was considered ok ten year ago doesn't seem to fly so high nowadays, even by open source standards...

[gimmeapill]

This is of course obvious - it would be better if issues were triaged more closely, no one would argue with that. But there's only so much time in the day, and I don't think we should be harsh on maintainers because they might not be spending their time on the things you'd like them to spend time on.

You seem very opinionated that this is the "correct" way to use a bug tracker, but this is not obvious. It is certainly a valid approach, and if you want to take it for your project that's great. Leaving unresolved issues open, though, can also be a valid approach.

Being harsh does work to some extent. See, we're talking about the elephant in the room already
And sorry, but I still don't consider tickets rotting for ten years a valid approach to support.

[lilith]

Most of the support is done via IRC. The devs are online almost every day at every time and if you have a question it is answered immediately and bugs are also fixed if possible. Most of the problems arise from the current midi implementation which is currently revised.

[milkii]

at least it's not on bugzilla!

possibly the state of the bugtracker might be confusing/scaring off new devs (and confusing users into reporting incorrectly).

delegation is good to speed up things and avoid burnout.

what could be delegated to randoms who wish to help? verifying/acknowledging bugs against the latest build? tagging bugs? more?

might there be call for a "bugtracker manager" role that some 'sensitive' tasks can be delegated to that randoms can't be trusted to help with?

what about the issue submission process? is "don't submit a bug unless you've tested against a nightly build" viable? or best left for someone who is acking bugs?

can something be improved about the structure of the bugtracker itself? to me, the "My View" page has arbitrary and short lists, and deep links to certain search configurations would help get from A to B quicker. maybe making date_submitted a default column on View Items? is the roadmap feature actually abandoned? if so, why have it then? (why on earth is bug 0001240, last updated in 2007 and closed, the top item on "View Issues"?)

[milkii]

like, i want to see just "new, feedback, acked, confirmed, assigned" from just "5.X git, 6.0-pre0", in reverse order of date submitted, but there seems no way to save/bookmark this view for myself, let along copy it to pass to someone else.

it seems no wonder the devs can't keep on top of things there*. is this a pitfall of Mantis, or Mantis with not much thought to incorrectly?

edit after IRC chat: * = by there, i mean on the bug tracker. apologies for not being more specific with my words. inattention to such can so often add fuel to the fire and i really wish to avoid such. n.b. i was also trying to couch my subjective interpretation with "seems", but i edited that in shortly after posting but managed to forget to fix the grammatical flow, which might not have helped.

[fundamental]

The Ardour bugtracker has 2600+ open entries some that are untouched for 10y+ years.
http://tracker.ardour.org/view_all_bug_ ... _number=54

This is not how a healthy open source project looks like.

While neglected issue trackers do drive me a bit nuts to deal with them, there are reasons why things devolve like they do. First and foremost is a lack of time IMO, but to build on that: *why* does it take time to manage issue trackers? When cleaning old issues, you do want to verify if they're resolved or not (it's easy to forget things and it's somewhat irresponsible to close "out-of-date" without at least skimming the issue). Some issues may be related to features which are on the "non-critical, but nice to have list" and those can sit around for ages. Those sorts of issues can be great to keep around for new contributors. Then there are bugs which are talking about mis-features or usability bugs. They shift and change as versions go on, but many times they aren't actually fixed for years. There are bugs which are confirmed, but they have a difficult setup and impact few people, so they go disregarded, but documented. There are issues which are 90% complete, but need to have a last bit which has gotten forgotten due to higher priority tasks. There are major landmark issues which will take years to build up to their completion.

Big open source projects end up with a backlog of a ton of semi-useful/semi-out-of-date/slow-burning issues. It is possible to clean those up by closing the out of date ones, and opening new ones with clarifications on how they impact current versions, but it is a *lot* of time to invest. Time which is hard to justify for core devs. So, I'd say plenty of healthy open source projects do have unhealthy looking issue trackers because there is no one to tend to that particular task with the level of detail that you'd want. Issue tracking and support in general involves a ton of discussion and even when the broader project is working, backlogs happen.

I know Zyn has built up a backlog over the years despite my best efforts and it's slowly getting longer. Unless you have individuals dedicated to only support, this is just what happens.

[rghvdberg]

And now it's time for all the people who subscribe or donate to Ardour and are dissatisfied with support (and somehow keep sending money) to comment on this thread.

I'm waiting.

[ssj71]

I honestly can't believe this! We're discussing the arguably most successful floss audio program on earth. I'd venture they have the largest user base of any floss audio program we use here, and we're condemning the devs because of their use of the bug tracker? Criticizing it, the suggestions are fine, and I'd wager the devs would really appreciate some volunteer to help with bug management, but "calling B.S." and "no wonder the devs can't keep on top of things" is absurd. They find the bug tracker useful in their own way (else they'd just completely stop using it), and in my experience and observation they are more than generous with their support (most typically over IRC).

Just for fun, look at these other "unhealthy" projects:
https://bugzilla.kernel.org/show_bug.cgi?id=61181 bug from 2012!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16016 a bug FROM 2005!?!

UNASSIGNED! UN-TRIAGED! TRAVESTY!
I'm wasting my time.

EDIT: milk pm'd me to point out they meant specifically the bug tracker when they said ardour devs aren't on top of "things." And that's a fair assesment, though again I say its clearly not the ardour dev's priority and I don't think it's their intended primary method of support.

[tramp]

And now it's time for all the people who subscribe or donate to Ardour and are dissatisfied with support (and somehow keep sending money) to comment on this thread.

Ups, so I should better shout up?

Serous, point me to the post were someone wrote that he isn't satisfied with the support the ardour dev's give?
This is a discussion on a very high level, so, please, . . .

When cleaning old issues, you do want to verify if they're resolved or not (it's easy to forget things and it's somewhat irresponsible to close "out-of-date" without at least skimming the issue).

Exact, and that is exactly what happen when reports hanging around, unsigned, longer then 10 years. Better approve, in my view is, delete them, and, if relevant any more, receive a new report. No one will take care of reports from the last decade.