On Saturday, June 10, 2017 at 3:29:51 AM UTC-7, Peter Suter wrote: > > On 10.06.2017 11:38, RjOllos wrote: > > > > On Friday, June 9, 2017 at 11:03:57 PM UTC-7, Peter Suter wrote: >> >> On 10.06.2017 03:43, RjOllos wrote: >> > I think it's worth considering to just do a switch to Python 3.5+ in >> > Trac 1.5.1 rather than supporting 2.7 and 3.5+. >> > * Python 2.7 is end-of-life in 2020 (PEP:0373) >> > * Optimistically, Trac 1.6 would be July 2018 >> > * We could continue to support Trac 1.4.x through 2020 >> > * Targeting fewer python versions can increase development velocity on >> > the trunk >> > * We can take advantage of the improvements in Python3 without concern >> > for a six compatibility layer >> > * Backward compatibility for old python versions will likely continue >> > to be less important with the adoptions of containers and other >> > isolated environments >> > >> > I would like to look to the future, improve my proficiency in the >> > latest versions of Python focus and focus on adding features. It feels >> > like we've had an excessive focus on the past (e.g. active development >> > supporting Python 2.5 continues for Trac 1.0-stable) and I think it >> > hinders the project. I can think of some counterpoints, I just don't >> > think any of them are as important as the points I've listed. Django >> > is dropping support for Python2 in the next major release (1). >> > >> > Are there any arguments for needing to continue to have the latest >> > stable release run on Python 2.7 in mid-to-late 2018? It would seem to >> > me that anyone wanting to stay with the latest Trac can spend the next >> > 12-18 months on their migration plan for this tiny web app. >> > >> > - Ryan >> >> Sounds reasonable to me, personally. My impression has also been that >> the project suffers from this "focus on the past". (I would include >> "still using SVN" and "contribution model by patches" here.) >> > > I have on my near-term todo list to writeup steps for contributing when > working from a GitHub fork. It's been discussed in a few tickets over the > past several years. > > I have some experience working with SubGit and the SVN-Git mirroring works > pretty well. If we configured SubGit we could commit directly to Git or > SVN. I'd also be fine with setting Subversion read-only and working > primarily from Git. SubGit is useful for that case as well. There's some > discussion about this in Lynx #41. > > >> [OT: I wonder if it would be possible to create a GitHub bot that posts >> all GitHub issues, PR's and comments to Trac tickets, and a Trac plugin >> that posts Trac replies back to GitHub.] >> > > The Django project has some tooling that might be useful. So far we get > about 1 PR from GitHub per year. > > I'm guessing the ability to accept pull-requests will get us more than > ticket synchronization. I know we can setup SVN-Git mirror with SubGit on > the Edgewall server. I'm unsure whether it would also be possible to mirror > between the Git on Edgewall and Git on GitHub with r/w to both. > > However, just the ability to commit directly to a Git repository would be > a big step forward in that we could easily grab pull requests from GitHub > and commit them. > > The switch to Git seems like biggest potential gain as it would save some > overhead in committing to SVN from a Git repository. > > > (Potentially Trac<->GitHub ticket synchronization could be a "killer > feature" also for other projects that use GitHub for community exposure, > but need some Trac features for coping with tickets. At least I've seen > such requests a few times in discussions of GitHub Issues. But it's just an > random idea probably not worth the huge effort, I don't have much use for > it myself. Personally, I prefer Mercurial and use hggit to interact with > Git repositories.) >
Some work was started on the feature, but nothing recent: https://github.com/trac-hacks/trac-github/issues/75 - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at https://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
