Problem-solving: Moving tickets between rakudo and problem-solving repos is impossible

[AlexDaniel]

It used to be that feature requests and proposed language changes were filed in rakudo/rakudo, but now we have this repo. However, because of the github limitation, it's not possible to move tickets between different orgs.

Is there any good reason for https://github.com/rakudo/rakudo/ and https://github.com/MoarVM/MoarVM repos to be in separate orgs?

Also, there are some inconsistencies. For example:

• https://github.com/perl6/rakudo.org (rakudo website in perl6 org), but
• https://github.com/MoarVM/moarvm.org (moar website in MoarVM org)

Wouldn't it be easier to move everything into perl6 org?

Note that CLA restriction can be kept in place, and it can be implemented with Teams github feature.

[AlexDaniel]

Ping @jnthn :)

[pmichaud]

I would prefer they be kept separate. At least in the original design, MoarVM and NQP have been intended to support more than just Perl 6 and Rakudo. I don't know @jnthn 's intentions in this area, but I still think rakudo, nqp, and moarvm make more sense as separate repos and projects with separate issue queues.

My $0.02,

Pm

[AlexDaniel]

@pmichaud but why do they need to be in separate github organizations?

[pmichaud]

Because they may end up with different committer lists, adminstrator roles, etc.

In general I've always wanted to avoid the sense that Rakudo or Perl 6 in any way "own" NQP and/or MoarVM; putting them all into one GitHub account somewhat defeats that purpose. If we end up with other languages or systems based on these tools, the tools should have their own identities.

Pm

[AlexDaniel]

Because they may end up with different committer lists, adminstrator roles, etc.

This can be done with Teams, at least to some extent.

putting them all into one GitHub account somewhat defeats that purpose

I don't see how it matters for that purpose.

[jnthn]

I agree with @pmichaud on things retaining their identities. Some other things:

• The namespacing organizations offer feels useful; it's easy to see which repos go with MoarVM, Rakudo, etc. We could replicate it with some kind of prefix, but that feels messy.
• I think separate organizations also convey, to a degree, the fact that the various projects are managed in somewhat different ways and have rather different commit policies. For example, the Perl 6 org is very liberal, Rakudo is guarded by CLA + other contributors are happy with the commit bit being given out (we never really formalized the second part of that), and MoarVM's policy is "whoever jnthn feels comfortable having a commit bit". :-)
• Keeping Rakudo and MoarVM as distinct organizations helps maintain the perspective that they're not the official Perl 6 compiler and runtime respectively. Having them under a perl6 org would dilute that.

[AlexDaniel]

it's easy to see which repos go with MoarVM, Rakudo

It's not like there are many repos. Rakudo org only has rakudo and star, and I see no problem with star being perl6/rakudo-star. Moar org has some forks, I'm not sure how I feel about those.

I think separate organizations also convey, to a degree, the fact that the various projects are managed in somewhat different ways and have rather different commit policies.

Having IMO annoyingly different policies is not a great thing.

Keeping Rakudo and MoarVM as distinct organizations helps maintain the perspective that they're not the official Perl 6 compiler and runtime respectively. Having them under a perl6 org would dilute that.

So perl 6 has no official compiler? That's a weird thing to say, especially given that you can download rakudo straight from https://perl6.org/downloads/.

[jnthn]

Ah, and as another consideration, I have little appetite for the churn of moving stuff, and the impact it will have on all downstream things that rely on repository URLs and so forth. Folks seem to reliably underestimate the amount of downstream costs changing the locations of stuff will have. For example, Rakudo's installation layout changes are costing me time/money to deal with. I'm not grumbling much because I think it's worth paying that for relocatable installs. I don't see myself being convinced that the cost of moving stuff around is worth the win this issue seeks.

[jnthn]

So perl 6 has no official compiler?

Correct, as realized by the language being defined by its test suite, not a single implementation.

[pmichaud]

So perl 6 has no official compiler?

Correct, as realized by the language being defined by its test suite, not a single implementation.

And just to amplify @jnthn 's point a bit... "No official or reference compiler for Perl 6" is one of the foundational principles for the language. Perl 6 is defined by its test suite, not by an implementation. That's a big reason why we call the compiler "Rakudo" and not "Perl 6".

There was also a time in the not-too-long-ago past when perl6.org/downloads (or its equivalent) offered links to multiple Perl 6 implementations, including Rakudo. Rakudo might be the most complete implementation, but we should never treat it as the "official" or "master" implementation.

Pm

[AlexDaniel]

There was a more recent discussion about moving rakudo/rakudo (log) and about the CLA (log and more).

Also, here's a question about perl6/doc→rakudo/rakudo transfers.

[AlexDaniel]

I'm not interested in this ticket anymore and I've never seen anybody else raise that concern.