On Wed, Aug 1, 2018 at 4:47 PM Robert Ramey via Boost <boost@lists.boost.org> 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