> On May 26, 2017, at 2:24 AM, Adi Roiban <a...@roiban.ro> wrote:
>
> On 25 May 2017 at 01:42, Glyph <gl...@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
<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.
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
