Re: [boost] Trac

Subject: Re: [boost] Trac
From: James E. King III (jking_at_[hidden])
Date: 2018-08-02 03:45:36

On Wed, Aug 1, 2018 at 4:47 PM Robert Ramey via Boost <boost_at_[hidden]>
wrote:

> I see 4 alternatives:
>
> a) stay with track and require developers to use trac and only trac
> b) require only github issues and convert all the old trac tickets to
> github.
> c) choose trac for all new issues but leave the old issues in trac so no
> one has to convert them
>
> d) let each library developer select which of the above he wants to do.
>
> I'm not adverse to b, c, or d.  But the current setup of having two
> conflicting working systems is a burden on developers and adds no value.
>
> Robert Ramey
>
>
This issue has come up on the mailing list more than once and it was also
discussed in the
admin project as an issue.  In short, the community is suffering from the
"Too Many Chefs
in the Kitchen" syndrome.  There is a lot of discussion, with many
opinions, but there is no
authority body that can actually make a decision that drives the project
towards improvement,
and therefore things do not happen quickly (if at all).  We will not always
be able to make a
decision that everyone can agree to, but decisions should satisfy a
majority of participants
and also help drive project quality and developer efficiency to improve.
Standardizing on
github for issues will do both.

My two cents on this one are that Trac is ancient and for the majority of
repositories the
contents are ignored.  Having all the issues in github would help increase
visibility.  In many
projects the backlogs are full of issues that have long since been fixed.
We're using github
now for our pull requests.  Pull requests can automatically close issues
when merged if the
issues are in github.  This does not happen if they are in Trac.  Let's
embrace the environment
and provide some consistency to people that consume the project so they can
use a tool
they are already familiar with - a tool practically everyone else is using
these days - and not
a tool that's mostly ignored and mostly unknown to everyone else.

If we leave existing issues in Trac then everyone should also commit to
driving that backlog down
to zero as a priority, and we should also measure this progress so that we
can identify repositories
that need ownership change to remain responsive to the community. The
backlog has been
ignored in too many projects for too long.  If we want to get issues into
github it would be wise to
first scrub what's in Trac and close out things already fixed or no longer
applicable, then do the
conversion.  Either way, repository owners need to step up and manage their
backlogs.

To see one, insert your repository name below:
https://svn.boost.org/trac10/query?status=!closed&component=
<insert_name_here>

Examples:

https://svn.boost.org/trac10/query?status=!closed&component=system - 26
open issues
https://svn.boost.org/trac10/query?status=!closed&component=thread - 62
open issues
https://svn.boost.org/trac10/query?status=!closed&component=test - 31 open
issues
https://svn.boost.org/trac10/query?status=!closed&component=serialization -
76 open issues

The vast majority of these issues haven't even been triaged yet and some
are 10 years old.
I mention these repositories because they are used quite often.  In one
case I've heard the
owner has retired, but ownership hasn't been reassigned.

In your own commercial projects would you let a backlog languish this way
for your critical
infrastructure?  Why do we?

Thanks,

- Jim