On 25 May 2017 at 01:42, Glyph <glyph@twistedmatrix.com> wrote:

As we're splitting the project into more parts, we may have to do Github org surgery to move projects around.

In particular, recently, twisted.python.url got split out into a new package called 'hyperlink', which we were initially thinking the Twisted org would adopt. (As it happens a different org will probably adopt it, more on that later.) Adi created a repo to allow Mahmoud to do this, and gave him permissions on said repo.

I just deleted this repo :-). In the future, the right way to do this is to have the owner transfer the repo over to the relevant org (this is in the "danger zone" in the github UI). Creating empty repos to move projects around breaks a whole bunch of github functionality (clones of the original repo can't update, ticket & PR history doesn't transfer over and can't be moved, links to forks get broken) and we should generally not do it.

Thanks Glyph for the info. It might be a bit offtopic, but there is one info / policy that I think that we should adapt when splitting a project. When a project is split, it is deprecated in Twisted in the same time. We should keep all the tests in Twisted until the deprecations deadline is triggered. This should help prevent any API breaks. There is still a risk for things to break, even if we have the tests (as we might not have 100 public api coverage). So maybe, when a new project is adopted there should be a commitment to keep the same API backward compatibility policy for at least one year. After one year the project can go wild and implement whatever quality policy they want... ex commit/release without any review or without tests. What do you think? Maybe I am just paranoid, and there is no risk quality decrease by outsourcing to external projects. Thanks! -- Adi Roiban

On 29 May 2017, at 20:25, Glyph <glyph@twistedmatrix.com> wrote:

Hyperlink is a bit of a weird case, in that its highly general nature meant that a more general org (hyper) made more sense to adopt it, but we are in the process of setting the project up and as I've discussed with Cory and Mahmoud it will probably have commit from most Twisted folks as well. While this one isn't living in the Twisted org, the python-hyper org takes its compatibility contract equally, if not more seriously.

To elaborate on this: ordinarily, when adopting a project, hyper will grant anyone with “write” permission on an original personal repo “admin” on it when it’s migrated (because personal repos don’t allow more than one admin, and this is usually what people want). Additionally, anyone who has committed but has no specific elevated privileges is granted “write” on that repo. Naturally, this is done after ensuring that branches are appropriately protected. However, acknowledging the unique case of a library pulled out of Twisted, an extra step will be taken, which is that all Twisted committers will be invited to hyper and given “admin” on hyperlink. This takes us closest to the original set of owners and permissions while also ensuring that this doesn’t seem like a coup or like Twisted committers will not be empowered to change their minds. If anyone ever feels unsatisfied with the stewardship of hyper, well, you’ll all have admin privileges and be able to move the repo away again. ;)

However, there is at least an unofficial agreement amongst all projects split from Twisted that they will adhere to largely the same compatibility policy as Twisted itself. In the case of Hyperlink, it is specifically documented as going above and beyond: http://hyperlink.readthedocs.io/en/latest/design.html#origins-and-backwards-... <http://hyperlink.readthedocs.io/en/latest/design.html#origins-and-backwards-...>.

We have no plans to change this documentation, which means it’ll remain the policy of the library. Cory