#1934: Some Python programs added to tools/dev
------------------------------+---------------------------------------------
Reporter: mikehh | Owner: jkeenan
Type: cage | Status: assigned
Priority: normal | Milestone:
Component: coding_standards | Version: 2.11.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
------------------------------+---------------------------------------------
Comment(by cotto):
For any non-core language programs included with Parrot as optional
components, we should require that they be licensed under the same terms
as Parrot, but not to make any restrictions on their coding standards.
The most I'd require would be that they contain instructions as to what
the tool is, how it's used and what it needs to be run. I'd recommend
that scripts follow whichever guidelines are most prevalent in that
language's community (e.g. PEP8), but we're not getting into the business
of enforcing coding standards on non-core languages. (By non-core
language, I mean anything that's not one of the major languages used by
Parrot, essentially PIR, PASM, nqp-rx, C, Perl 5, etc.)
Non-core language tools must never be a required part of the build. If
they're in git at all there needs to be a good reason why they can't be
implemented in a core language. In this case gdb only includes Python
bindings, so that's the only option for nicer debugging. We should
consider these kinds of tools an optional and unsupported part of Parrot.
If they work it's nice, but if they're broken they won't mess anything up.
short answer: keep them for now with no guarantees, let them be maintained
as the committer sees fit and if they bitrot and nobody fixes them up, out
they go.
I'll close this ticket after a while if there are no objections.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1934#comment:10>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
