GHDL, a GitHub organization

[eine]

Now GHDL as a project comprises:

• Monolithic git repo hosted at github.com/tgingold/ghdl
  • Sources
  • Build/ci scripts/configs
  • Libraries
  • Test suites
  • Documentation sources and build config
• Hosted continuous integration services:
  • Travis CI for gnu/linux and macos builds, tests and releases: https://travis-ci.org/tgingold/ghdl/
  • AppVeyor for windows builds, tests and releases: https://ci.appveyor.com/project/tgingold/ghdl
  • Read the Docs (RTD) for the documentation: http://ghdl.readthedocs.io

It is not a great deal to have everything in a single repo. Indeed, it is easier to handle. However, there are several enhancements that can start making it uncomfortable. These are not expected to be added in the near future, but we neither expect them to take years:

• GitHub Pages as a replacement, update or redirect to http://ghdl.free.fr/ (proposed in #477)
• Repo to gather configs, examples, prototypes to use GHDL with/in GUI editors (proposed in #111)
• A repo for (each) package manager (proposed in #497)
  • jorisvr/ghdl_debian (already forked by tgingold/ghdl_debian and starred by Paebbels)
  • Alexpux/MINGW-packages (already starred by Paebbels, but not forked yet)
  • aur.archlinux.org/ghdl (not forked yet)
  • launchpad.net/~pgavin/+archive/ubuntu/ghdl is so out-of-date.
  • admin.fedoraproject.org/pkgdb/package/rpms/ghdl is already quite up-to-date. I just installed (dnf install gdhl) a package which reports version 0.34dev-0.20170926git685526e.0.fc26, but responds to ghdl --version with GHDL 0.35-dev (tarball) [Dunoon edition] Compiled with GNAT Version: 7.2.1 20170915 (Red Hat 7.2.1-2) GCC back-end code generator Written by Tristan Gingold.. Just as a note: might be worth letting the maintainer know how to get rid of tarball and have relevant data instead (related to [build-system] do not require git in the Makefile #480).
• tgingold/ghdlsynth-beta ?

Furthermore, the current master branch requires 33.5MB: sources (10.1MB), testsuite (18.7MB) and libraries (3.9MB). If a refactorization is considered, it might be reasonable to move the test suites and the libraries to separate repos:

• Test suites:
  • vests (13.7MB) is mostly a raw copy of the source.
  • gna already mixes reproduction examples from multiple sources (bug, issue, ticket, sr, perf...)
  • These test suites are useful not only for GHDL, but for any software project to test VHDL support.
  • Other test suites can be added, such as 1138-4EB/ghdl-tools/blob/master/vhdl08testsuite/ghdl08.md
• Libraries:
  • These are not used during the build process, but are 'external' dependencies to run the test suites.
  • These are now shipped in GHDL tarballs (both sources and pre-built).
  • If split, distribution needs to be rethought. We can still make it behave as it does now. Or we can distribute libraries as separate releases. We can also do both.

---

An organization would allow the following structure:

• A specific repo for GitHub Pages of the organization: ghdl.github.io.
• github.com/ghdl/ghdl can be an alias to github.com/tgingold/ghdl, or the other way round. No need to make it a fork.
• github.com/ghdl/libraries
• github.com/ghdl/testsuites
• github.com/ghdl/ghdl_debian
• github.com/ghdl/MINGW-packages
• github.com/ghdl/gui

---

I see that github.com/ghdl is a user with no history at all. Does it belong to any of you? If not, we might consider either writting to GitHub or using any other (say ghdl-org).

[tgingold]

I am not sure it is a good idea to separate ghdl, libraries and testsuites. It is much simpler to clone a single repo rather than multiple ones. If we can't get the ghdl organization, let's forget about that plan. Using another one would create confusion.

[Paebbels]

While I like a lot of repositories and Git submodules, I'm not sure if such an approach fits for GHDL.

But if possible, I would also suggest to create a "ghdl" organisation to maintain GHDL and the related repositories e.g. for packaging.

I would not suggest to split GHDL yet or in the next 1-2 years.

@1138-4eb Are you going to contact GitHub?

[eine]

@1138-4eb Are you going to contact GitHub?

Well, I can ask. But, shall a 'formal request' be required, it should be done by a project maintainer. There are two possible changes here:

• Claim 'ghdl' as an org.
• Set the redirection.

@tgingold, what do you think about the redirection/alias?

[Paebbels]

As far as I know from VUnit, a redirection is not needed. All URLs from tgingold/ghdl will continue to work.

[eine]

Actually, VUnit is redirected (301 Permanent Redirect) from LarsAsplund/vunit to VUnit/vunit.

Anyway, if ghdl/ghdl is just a fork of tgingold/ghdl, no redirection is required. Yet:

• ghdl/ghdl won't show the 'issues' tab. Users will have to know that they need to go to tgingold/ghdl to collaborate.
• There is a risk for the repos to go out-of-sync, specially when it relates to releases. Releases should be disabled in the fork, leading to possible confussion.

[eine]

So fast! github.com/ghdl is ours!

You are in luck — we have classified the "ghdl" account as inactive and released the username for you to claim, as per our Name Squatting Policy: https://help.github.com/articles/name-squatting-policy

Please be quick as the username is now publicly available! Should you wish to rename your account directly.

Then, I created it. I am currently the only member, and owner. I invited @tgingold , @Paebbels. Visit github.com/ghdl to accept the invite, and let me know here, in order to change your roles.

GitHub expected us to either convert an existing account or rename an existing organization. Either of those options would have set redirects automatically. However, this is a new organization with no repos. Therefore, I wrote them back to ask which is the procedure to set the redirect.

@tgingold, please let me know if you want ghdl/ghdl to be an alias of tgingold/ghdl (which would somehow opposite to the normal flow), or if we should move everything to ghdl/ghdl and make tgingold/ghdl be the alias.

It is easier than expected: https://help.github.com/articles/about-repository-transfers/
@tgingold, just go to repository settings and transfer the repo to the org. After doing so, make sure that you "never" create tgingold/ghdl again. That would break the redirects: If you create a new repository under your account with the same name as the transferred repository, existing redirects to the transferred repository will break. Instead, use a different name for the new repository.

Also, note that you should wait until @Paebbels and you are members of the organization, in order to preserve issue assignees: If you transfer a repository from a user account to an organization, issues assigned to members in the organization remain intact. All other issue assignees are cleared. Only owners in the organization are allowed to create new issue assignments.

[tgingold]

Wonderful. Let's make tgingold/ghdl an alias of ghdl/ghdl

[eine]

@tgingold you should have received an e-mail. Follow it to accept the invitation and become an owner of the org.

[Paebbels]

So, we need a logo, right? ;)

[eine]

@tgingold , since both or you are owners of the organization now, you can make the transfer safely whenever you want.

@Paebbels, that'd be great!

[tgingold]

@1138-4eb Before transferring the ghdl repo, I wonder if I should be the only owner of the ghdl organization (so that I am the only one that can delete it). Does it make sense ?

[eine]

@tgingold, sure. You can remove/change me whenever you want. However, you should keep @Paebbels as a member at least (not owner), in order to keep assignees in the issues. In the future, you have these options:

• Add collaborators to a single repo (not members of the organization). The same you did until now.
• Outside collaborators can never create repositories in the organization.
• (Optional) Allow members to create repositories for this organization.
• (Optional) Allow members to delete or transfer repositories for this organization.
• (Does not apply to GHDL) Allow members to change repository visibilities for this organization.
• Choose the default permission level for organization members. The default repository permission only applies to organization members, not to outside collaborators.
  • Admin
  • Write
  • Read
  • None

You can change these options here: https://github.com/organizations/ghdl/settings/member_privileges

[tgingold]

Done. I will transfer the ghdl repo soon. (And then we have to deal with docker too!)

[tgingold]

First message from ghdl/ghdl!

[eine]

Awesome! Thank you once again for being so open and responsive to new proposals!

Shall we add a couple of notes to let users know that, although not compulsory, it'd be desirable to change the remote urls of their local clones? I think it can be added to the 'News' section in the home of the docs, and to the README.

[tgingold]

Well, thank you for pushing this effort.

Yes, we now have to update all the urls in the doc, and add an entry in NEWS.md

[eine]

Most of the url updates are done in #503. There are still two pending issues: travis and appveyor are configured with tgingold/ghdl, so the shields corresponding to these are not changed.

[Paebbels]

Hmmm, I was not allowed to directly comment on #503. I needed to add me and Tristan to the group of assigned reviewers to write a comment.

GitHub displays my role as "Member" is this more or less than before (old: Collaborator)?

[eine]

Yes, the 'Member' role is more or less the same as the old 'Collaborator', but the first applies to every/any repo in the organization and the latter to a single repo. See https://help.github.com/articles/repository-permission-levels-for-an-organization/ It's a pitty that we cannot see our own privileges if we are not owners. I mean that, being members, we can have only read, read/write or admin permissions. No way for us to know it now. (I wrote to GitHub to ask about this).

Actually, I think that any user is allowed to create a comment in any issue/PR, unless we explicitly disable/close it. However, you did not create a comment, but a review for the PR.

Althought it is not clear to me where is the limit to be able to create reviews (see https://help.github.com/articles/requesting-a-pull-request-review/), I am allowed to create a review in any issue right now (say #436, which already has a review; or #434, without any existing review). Can you check those?

[eine]

Travis is failing now, because tgingold/ghdl no longer exists and ghdl/ghdl has never existed. Seems that we need to set up travis releases again with travis cli. @tgingold, if you want, tell me when you will tackle this, and we will configure it along with dockerhub.

[eine]

Travis is renamed and it is working again: #504.

[tgingold]

I am trying to deal with appveyor...

[tgingold]

Appveyor is now working.

[eine]

@tgingold , appveyor badges are still pointing to https://ci.appveyor.com/project/tgingold/ghdl . The title is 'ghdl-old', so I believe you created a separate 'new' project, but I can't find the URL. What is it?

[tgingold]

Try: https://ci.appveyor.com/project/tgingold/ghdl-psgys Not sure how it was computed!

[eine]

That seems to be up to date. However, I can't see the Badges tab of the project settings, as explained here: https://www.appveyor.com/docs/status-badges/ Would you mind checking it and posting the corresponding token here?

Alternatively, https://ci.appveyor.com/api/projects/status/github/ghdl/ghdl seems to work, but I think it is preferred to use the unique token.

BTW. I think that we can close this issue after we fix these badges. Or, do you want to keep it open until we configure dockerhub?

[tgingold]

I have updated the badge url, will push soon.

BTW. I think that we can close this issue after we fix these badges. Or, do you want to keep it open until we configure dockerhub?

Ok for me to close this issue.