Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving tickets between rakudo and problem-solving repos is impossible #46

Closed
AlexDaniel opened this issue Jun 20, 2019 · 12 comments
Closed
Assignees
Labels
fallback If no other label fits

Comments

@AlexDaniel
Copy link
Member

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:

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 AlexDaniel added the fallback If no other label fits label Jun 20, 2019
@AlexDaniel AlexDaniel self-assigned this Jun 20, 2019
@AlexDaniel
Copy link
Member Author

Ping @jnthn :)

@pmichaud
Copy link

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
Copy link
Member Author

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

@pmichaud
Copy link

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
Copy link
Member Author

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
Copy link
Contributor

jnthn commented Jun 20, 2019

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
Copy link
Member Author

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
Copy link
Contributor

jnthn commented Jun 20, 2019

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
Copy link
Contributor

jnthn commented Jun 20, 2019

So perl 6 has no official compiler?

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

@pmichaud
Copy link

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
Copy link
Member Author

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fallback If no other label fits
Projects
None yet
Development

No branches or pull requests

3 participants