Re: Future of Trac in Debian

2020-01-03 Thread Martin

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

2020-01-02 Thread Sandro Tosi
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

2019-11-30 Thread Simon McVittie
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

2019-11-29 Thread Martin
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

2019-11-29 Thread Martin
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

2019-11-29 Thread Nicholas D Steeves
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