On May 26, 2017, at 2:24 AM, Adi Roiban <adi@roiban.ro> wrote:

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.

I understand the concern. These split-outs have not all been conducted with the greatest transparency, but mainly because communicating everything publicly is a bunch of extra work.

For the most part, split-out projects will just go into the Twisted org anyway, and will have the same compatibility contract. I do not anticipate splitting out anything with a deeply involved portability contract, the reactors will remain on our existing CI for the forseeable future :).

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.

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-compatibility.

(Although perhaps someone should file a PR to remove the word "legacy" there :).)

In short: let's keep an eye on this, if we start to have compatibility drift or issues, then by all means let's add some belt-and-suspenders checks, but I think we can be optimistic about not having compatibility problems.