[Twisted-Python] Migrating Trac Tickets to GitHub issues

[Glyph]

> On Sep 30, 2017, at 2:15 PM, Adi Roiban <adi at roiban.ro> wrote:
> 
> Hi,
> 
> I would like to re-start the conversation about migrating Trac tickets
> to GitHub issues.
> 
> My main reason for doing this is to make it easier for people to
> contribute to Twisted.
> 
> In CONTRIBUTING there is this info
> 
> `GitHub doesn't provide adequate tooling for its community.`
> 
> I don't know what is missing in GitHub and why overall Trac is better
> than GitHub issues.

The major missing feature, as discussed in the PR thread, is the ability to record the separate workflow state of "needs review" / "needs feedback addressed" as distinct from "open" / "closed".  A bot that could do this would address more or less the entire issue.

> I know that GitHub Issues is simple and you can't save reports.
> 
> What are problems are there with GitHub issues, which are blocking the
> migration?

One issue which I haven't seen raised here is the need to maintain a redirection service, to ensure that the massive amount of information currently recorded in commit messages and emails linking to existing trac issues is not lost.

> Please send your thoughts.
> 
> Why you think that GitHub issues might be worst than Trac tickets :) ?
> 
> --------
> 
> Below are the things that I things we will lose when migrating to
> GitHub Issues and which will require extra work.
> 
> 1. We will no longer get the nice ticket reports.
> 
> I don't know how to get something like this just using GitHub... and I
> think that we will need a separate web page which uses GitHub API to
> create the reports.
> 
> 2. We might lose the owners / authors of some comments as there might
> not be a maping from Trac to GitHub. This might be mititage as we are
> already using GitHub for login.
> 
> 3. There is extra one-time work required to do the actual migration,
> and decide how to translate Trac ticket attributes to GitHub Issue
> attributes.
> 
> We might not get consensus on how to migrate the metadata and this can
> be a blocker.
> 
> 4. We will no longer get the weekly reports and need more work to
> reimplement them based on GitHub.
> 
> 5. Highscores will stop counting the contribution, and it needs more
> work to reimplement it on top of GitHub. I have hacked the highscores
> project and I can change it to work both historic Trac data and new
> GitHub data.
> 
> ----------------
> 
> Below are my arguments for migrating to GitHub issues:
> 
> 1. With Twisted tickets/PR only handled on GitHub you can have
> contributions which are done only by sending a PR, without creating an
> issue. You find a bug, you fix it and send a PR.
> You no longer need to go to Trac and create a ticket and then do all
> the cross-links copy and pasting.
> 
> 2. We no longer have the review history in Trac, and the review
> discussions are split between Trac and GitHub.
> 
> I think that in the future we will move more review discussions in GitHub.
> 
> Having all the discussion in a single place will make it easier to
> search for something.
> 
> You no longer need to search GitHub and Trac tickets.
> 
> 3. With tickets on GitHub we should simplify the infrastructure.
> I feel that lately there was not much time from current Twisted dev to
> take care of Twisted infra.
> From what I can see, the servers are just restarted on an issue, but
> there is no time to investigate what is wrong.
> 
> I think that Twisted dev should focus on Twisted code and not spend
> time with the ticketing infrastructure.

While, in general, I strongly agree with this, and I would personally very much like to operate less infrastructure, there is the fact that the twistedmatrix.com <http://twistedmatrix.com/> website has served as a very important dogfooding resource for us in the past.  We've found and fixed dozens of bugs in Twisted due to our constant, intense use of it.

That said, this is not really an argument against doing this.  Maybe if we didn't have to operate something as old and clunky as Trac we could invest our dogfooding effort in new, cool web toys where the effort was writing and debugging code using Twisted and not shell scripts to restart zombie processes.  I just think it's important to consider how the developer community can continue to use Twisted itself as part of this process.

> 4. With tickets in GitHub, we don't need extra tooling to close a
> ticket when a PR is merged.
> 
> 5. With tickets in GitHub I assume that a lot of contributors will
> only have to care about a single management tool: GitHub.
> 
> They will no longer have to learn about Trac, how Trac keywords work
> for a ticket and how a workflow is implemented in Trac for Twisted.
> From what I can see, we are not using the Trac workflows anyway, just
> a hack to implementing something like a workflow by manually setting
> various attributes of a ticket.
> 
> 
> Thanks,

Thanks for driving this effort forward!  I look forward to hearing Mark pipe up in this thread (hint, hint)...

> PS: For my private project  I am still using Trac for issues and
> GitHub for PR and manage the tools to keep them in sync.
> I am using the Trac ticket workflows with a dedicated state for a
> ticket when it needs a review or when a review was done and it needs
> changes.
> -- 
> Adi Roiban
> 
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20171001/ae0b31bd/attachment-0002.html>