OpenBLAS binary packages

[Artur Szostak]

>> I get and understand your concerns. Consider my comment as giving a data
>> point from real world use in the wild. You already seem to be aware of the
>> trade offs and consequences of technology choice and policy decisions related
>> to package managers and how they are used.
>
> I'm grateful for the feedback, but I don't know what else to say about this.
> The message I'm receiving from you is "fix all the bugs". We'd obviously love to
> do that. If we're not doing so fast enough, it's because we don't have enough
> people looking at the bug reports and fixing them; if you or anybody else can
> provide additional human resources to do that, that would be welcome.

No, that's not exactly the message I am trying to send. MacPorts is a free product
run by volunteers. I fundamentally cannot expect anything. I get what I pay for,
which is nothing, so I cannot just expect bugs to be fixed. It is up to the core maintainers
to decide what kind of product and support they want to provide, since its at their
own cost. I was just trying to point out that at least one subset of end users is having
a worse experience with MacPorts compared to other package managers. If the core
MacPorts team even cares, I suspect that the long term solution is less to do with
technology and more to do with overall policy.


>> As for bug reports: We have made these as and where necessary. However, if
>> you want earlier and better feedback, I can only suggest to make this process
>> trivial for the end users, i.e. the goal would be the equivalent of one click reporting.
>> This is hard to implement properly though, without exposing the project to abuse
>> (e.g. spam etc.) and keeping end user security in mind. If done right however,
>>  I think this could be a significant improvement to the project overall.
>
> Specifics would be more helpful than generalities. What exactly should we be doing
> differently?

As you already indicated: automated report generation. e.g. the following messages
from the port command on error:

Do you want to send a bug report [Y/n]?
Do you want to review the information sent in the report [Y/n]?


> Currently, when a build fails, we print a message telling the user where the build log
> is located and how to report bugs to us. If you are suggesting that a bug should
> automatically be filed at this point, that would only further deplete our limited human
> resources by wasting our time on marking these automatic submissions as duplicates
> of other tickets. We already spend enough time on that with the current manual bug
> reporting system, because users are bad at identifying when their problem has
> already been reported by someone else and doesn't need to be reported again.

I was suggesting exactly that: automation of the bug reporting process. But if I was
going to do it, it would have to be done right, for exactly the problems you indicate.
I believe it can be done right, even if it is a difficult and non-trivial problem. But so is
compiling source code, and yet there are plenty of high quality compilers out there
now days. So these things can be done.
It was just a suggestion. If MacPorts can dedicate some real resources to this I think
it would set the project apart and have long term positive impact. But if it can only
be done half way it will indeed only increase the load on the maintainers and should
not be attempted.


> I don't think bug reports are a process that can usefully be automated. The user is
> expected to do some investigation on their own to discover whether this bug has
> been reported before, to read the notes of those previous reports, try out any fixes
> suggested in those reports, etc. In many cases a build fails not because of a bug in
> the port but because of a misconfiguration of the user's system; only the user can
> identify and correct such problems.

I disagree. I think it can be automated, but requires some engineering effort to get right.
This is an example of the policy decision and consequences I was alluding to. It is a policy
decision to expect the end user to do some investigation. But the consequence is that
this significantly reduces the number (of ideally unique) and quality of the reports. Thus,
reduces the chance of early detection and feedback. Lets face it, human beings are lazy
or many not familiar enough with building software or MacPorts to be able to provide
a useful report. I will take a high quality report from a real diagnostics system over the
average end user any day.