python2.7 throws bus error when issuing `help("modules")'

[John Chivian]

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 <dluke at geeklair.net> wrote:
>> On Aug 24, 2020, at 5:41 PM, Jeffrey Walton <noloader at 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