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 [email protected].
To post to this group, send email to [email protected].
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