Re: [Python-apps-team] Bug#938682: Future of Trac in Debian
> > if i dont hear anything back withing a week, i'll most likely opening > > those RM bugs, so that we can work on their transitive dependencies. > > Just go ahead. I hope, we can reintroduce Trac in one or two > years, maybe in time for Debian 12 (bookworm), but probably not > for Debian 11 (bullseye). thanks, just filed all those RM bugs. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Future of Trac in Debian
Quoting Sandro Tosi : So Jan 1 arrived, what do you think we should do? i didnt see any progress on the port to python3 upstream; should we start filing RM for trac extensions/plugins and once they are gone, RM src:trac? I don't expect a Python 3 version of Trac before a year from now. Debian, the high speed train, overtakes Trac, the steam train! an initial list of packages for the first pass of RM could be: $ apt-cache search trac- libnet-trac-perl - Perl client library for Trac libtext-trac-perl - module for formatting text with Trac Wiki Style AFAIK, those two are not Python and can use a remote Trac server, so they can stay. All others need to be removed. if i dont hear anything back withing a week, i'll most likely opening those RM bugs, so that we can work on their transitive dependencies. Just go ahead. I hope, we can reintroduce Trac in one or two years, maybe in time for Debian 12 (bookworm), but probably not for Debian 11 (bullseye).
Re: Future of Trac in Debian
Hello Martin, On Fri, Nov 29, 2019 at 6:55 PM Martin wrote: > > On 2019-11-29 18:13, Nicholas D Steeves wrote: > > IMHO one of the Debian Trac uploaders should post to the #12130 Trac > > ticket informing them of our plan. > > I linked to the email of 2019-10-14: > https://trac.edgewall.org/ticket/12130#comment:63 So Jan 1 arrived, what do you think we should do? i didnt see any progress on the port to python3 upstream; should we start filing RM for trac extensions/plugins and once they are gone, RM src:trac? an initial list of packages for the first pass of RM could be: $ apt-cache search trac- libnet-trac-perl - Perl client library for Trac libtext-trac-perl - module for formatting text with Trac Wiki Style trac-accountmanager - account management plugin for Trac trac-announcer - enhanced e-mail notification system for Trac trac-authopenid - OpenID authentication plugin for Trac trac-customfieldadmin - panel for administrating custom ticket fields in Trac trac-datefield - Add custom date fields to Trac tickets trac-diavisview - Renders dia and vdx files in Trac trac-graphviz - Graphs printing plugin for Trac trac-httpauth - Force HTTP authentication from within Trac trac-icalview - Provides iCalendar feeds for ticket queries trac-includemacro - Include external resources in a Trac wiki page trac-jsgantt - displays Trac tickets as a Gantt chart in a wiki page trac-mastertickets - adds inter-ticket dependencies to Trac trac-mercurial - Mercurial version control backend for Trac trac-navadd - add custom items to main and meta navigation bar in Trac webapp trac-odtexport - Export Trac wiki pages as OpenDocument (ODT) files trac-privatetickets - Allows Trac users to only see tickets they are associated with trac-privateticketsplugin - transitional dummy package for trac-privatetickets trac-privatewiki - add private wiki ability to Trac trac-roadmap - enhances the Trac roadmap with sorting and filtering trac-sensitivetickets - Plugin for Trac ticketing system to hide tickets marked as sensitive trac-subcomponents - use multiple layers of components in Trac trac-subtickets - sub-ticket feature for Trac tickets trac-tags - Tagging plugin for Trac wiki and issue tracking system trac-translatedpages - Show translated versions of wiki page in the Trac web application trac-virtualticketpermissions - Extended permissions plugin for Trac ticketing system trac-wikiprint - Make Trac wiki pages printable, exporting to PDF or printable HTML trac-wikitablemacro - SQL Table in Wiki Page for Trac trac-wysiwyg - WYSIWYG style editor for the Trac issue tracking system trac-xmlrpc - XML-RPC interface to the Trac wiki and issue tracking system if i dont hear anything back withing a week, i'll most likely opening those RM bugs, so that we can work on their transitive dependencies. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Future of Trac in Debian
On Fri, 29 Nov 2019 at 18:13:02 -0500, Nicholas D Steeves wrote: > At that upstream issue gwync writes that he might have to drop Trac in > Fedora if there isn't a py3 test release "before Fedora 32 is GA". I'm > not sure what "GA" means Presumably "general availability", i.e. properly released (as opposed to a beta or other prerelease). smcv
Re: Future of Trac in Debian
On 2019-11-29 18:13, Nicholas D Steeves wrote: > IMHO one of the Debian Trac uploaders should post to the #12130 Trac > ticket informing them of our plan. I linked to the email of 2019-10-14: https://trac.edgewall.org/ticket/12130#comment:63
Re: Future of Trac in Debian
On 2019-11-29 16:24, Sandro Tosi wrote: > I know it may sound hard, but is it now time to remove trac from > Debian, and ideally re-introduce it back when it's being ported to > py3k? See also: https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs What would be the alternative? It would be nice to have newer versions (based on Python 2) as backports or sloppy backports for buster, but that will not be possible anymore, as soon as Trac is removed from unstable, right? Btw. Trac development is still active (1.4 released three months ago, but slow, maybe because of lack of developers: "Trac 1.4 is the first major release of Trac in almost 3 years." Trac 1.6 will probably use Python 3. But when? Nobody knows. Cheers
Re: Future of Trac in Debian
Hi, Sandro Tosi writes: > Hello everyone, > i'd like to discuss the future of Trac in Debian. as we all know, Trac > is still python2, and while there are plans to port it to python3 > (https://trac.edgewall.org/ticket/12130) that port is not there yet, > and it may take quite some time to reach a state it can be tested, let > alone released. > > What should we do in the meantime? bin:trac has 30 reverse > dependencies (its plugins/addons) and all of them collectively are > likely forceing several other python2 packages to stay in Debian > because they depend on them. > > I know it may sound hard, but is it now time to remove trac from > Debian, and ideally re-introduce it back when it's being ported to > py3k? At that upstream issue gwync writes that he might have to drop Trac in Fedora if there isn't a py3 test release "before Fedora 32 is GA". I'm not sure what "GA" means, but given their release schedule here: https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html and it looks like they'll be dropping py2 on 2020-01-01, and thus Trac. IMHO one of the Debian Trac uploaders should post to the #12130 Trac ticket informing them of our plan. Is there a concrete plan yet? eg: We intend to remove Python 2 from Debian by 31 January, and because we are a conservative and slow moving distribution we are slowly working are way through thousands of application dependency chains to remove applications that do not support Python 3, rather than breaking everything at once by simply removing the interpreter on New Year's Day. If we were not removing packages now we could not meet this objective. . We would like to continue distribute Software-X in Debian, so is there a Python 3 port we can package that is ready for testing today? -- Which is to say, I think the question of "remove now" is contingent on that question. If there is zero hope of a py3 port in a testable state by py2 EOL, then it's ok to drop now, but we need to do more to maintain good relationships with upstreams. Best, Nicholas signature.asc Description: PGP signature
Future of Trac in Debian
Hello everyone, i'd like to discuss the future of Trac in Debian. as we all know, Trac is still python2, and while there are plans to port it to python3 (https://trac.edgewall.org/ticket/12130) that port is not there yet, and it may take quite some time to reach a state it can be tested, let alone released. What should we do in the meantime? bin:trac has 30 reverse dependencies (its plugins/addons) and all of them collectively are likely forceing several other python2 packages to stay in Debian because they depend on them. I know it may sound hard, but is it now time to remove trac from Debian, and ideally re-introduce it back when it's being ported to py3k? thanks, sandro