[Twisted-Python] on adopting projects

[Adi Roiban]

On 25 May 2017 at 01:42, Glyph <glyph at 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