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.
 

> One big concern for me is Mercurial support. The current MercurialPlugin 
> means Trac and Mercurial must run on the same Python version. And 
> Mercurial has long been very opposed to Python 3 support. This now seems 
> to have changed somewhat, but I think it's still unclear when it will be 
> supported. 
>
> https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support 
> https://www.mercurial-scm.org/wiki/Python3 
>
> Possibly switching to the server-command protocol would help there, as 
> Mercurial could then run on its own separate Python version. 
> https://trac.edgewall.org/ticket/10411 
>

Thanks, that's a significant factor. It's hard to imagine that Mercurial 
would continue to only support Python2 past its end-of-life and still hope 
to stay relevant. Maybe some more research is warranted here, to see if 
there's been additional discussion about the timeline for Python3 support 
beyond what's listed on the wiki.

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

Reply via email to