The maintainers of MacPorts cannot and should not be expected to maintain and fix bugs in projects!  That is the job of the project maintainer, not the team that voluntarily provides ports of the open source software.

If you want the ability to audit software control and accountability, so that you can hold someone else's feet to the fire, go and pay the big money for a commercial product with a legally binding support contract, and make sure you get those clauses written in before you sign it.

If you insist on using open source software for free, regardless of who provides it, then you have the ultimate responsibility for making it work properly in your environment, and fixing (or hoping the project maintainer will fix) any issues that you might uncover and report.

Yes, the audits people have to go through are decidedly real, but you as the auditee cannot deflect the consequences of your own choices to someone else.

Just my 2cents

On 8/24/20 5:32 PM, Jeffrey Walton wrote:
On Mon, Aug 24, 2020 at 6:13 PM Daniel J. Luke <dl...@geeklair.net> wrote:
On Aug 24, 2020, at 5:41 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
It's also super-silly to expect that MacPorts is taking "responsibility" for 
all upstream projects.
How so?

It is a standard audit item.
please cite what "standard" you believe you are auditing MacPorts under.
Sorry, I have no idea what standard processes Macports adheres to. I
assume there's something in place (other than, "It compiles on my Mac
Intel, ship it").

If you would like to see an example, then try FIPS SP800-53A, item
SA-12. Or just search the document for "supply chain". ISO also has
similar processes and audits.

Please explain what the enforcement mechanism is if MacPorts fails this 
imaginary audit (ie, do you get something other than a refund of the $0 you 
paid?). How does this audit compel volunteers to fix an issue for you for free?
$0 means nothing.

There are no enforcement mechanisms. You could plead to the developer
hoping they will take pride in their workmanship. It is hit or miss
whether it works.

Sometimes we find gems, like Botan and cURL, but they are few and far
between. Folks like Jack and Daniel are constantly improving their
processes. When someone finds a gap they try to address it. They don't
say "go talk to someone else" when it affects their project.

I'm also curious what imaginary audit wouldn't first point out that python2.7 
was sunset on January 1, 2020.
No, the audits folks have to go through are real.

A finding on Python 2.7 is irrelevant. What is the point?

You don't get to claim you are using
software X and any problems are someone else's responsibility.
I'm pretty sure I can claim whatever I want ;-)
You certainly can.

The most curious responses often come from folks who have never been
exposed to project management, development lifecycles or SDLCs. They
are literally the group that does not know what they don't know.

If you
don't want to be responsible for software X, then you don't use it.
Ok, so I guess you are also responsible for MacPorts and all of the software 
that ports exist for because you use it.

MacPorts is a community-sourced collection of build recipes. It also hosts some 
mirrors for files referenced in those build recipes and the cached results of 
those build recipes.

It's all done by volunteers and if you paid someone for access to them, you 
should follow-up with whomever you paid.
The only thing super silly is not taking responsibility for it and
then pushing it onto unsuspecting users.
I think you misunderstand what MacPorts is. Please re-read the sentence: "MacPorts 
is a community-sourced collection of build recipes."
I don't believe I have a misunderstanding. Macports is a supplier of
software for OS X. Macports is responsible for the software they
provide.

Jeff


Reply via email to