Re: [boost] Boost Trac, random, No-Maintainer?

On 08.10.2017 22:14, James E. King, III via Boost wrote:

On Sun, Oct 8, 2017 at 1:18 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost wrote:

...

Then there's your answer. If project maintainers that have admin rights don't enable issues then they don't want it. Rather than speak in generalities I think it would be more productive to talk about specific authors and specific projects. For example, I suspect that Chris does not want Issues enabled here: https://github.com/boostorg/asio

But would rather see them here: https://github.com/chriskohlhoff/asio

We should enumerate all of the libraries which have Issues disabled and evaluate them one by one.

As a consumer of boost, it would make a lot more sense for me to go to one place for issues. Can you elaborate what you mean by "customer of boost" ? Boost contains > 100 libraries, so I think qualifying yourself as a "boost customer" isn't very helpful, and neither is it practical to have a single hub for interactions between "boost" developers and users.

If I go to the official repository for a boostorg library and issues are not enabled, I find that odd. Further if some have issues enabled and some do not, I find that even more odd.

I agree. This is why I think we need a canonical way for each library to document how to submit issues.  The "Search the bug database" link on http://www.boost.org/development/bugs.html just isn't cutting it any longer (if it ever has).

It makes a lot more sense to me as a consumer of boost that if I have an issue from a github repository I have pulled from, that's where I should submit issues.

It also does not make sense that some repositories would prefer to have issues on personal forks. I think it's high time to admit that individual libraries are maintained by individual maintainers / communities. Each should provide clear instructions on how to submit issues, etc. Then you can take it up with each library individually if you don't agree with their choice of issue

I think the first step for you "as a customer" is to be aware of which library / libraries you use, and for each have a way to provide feedback (submit issues, etc.). The fact that "boost" has been trying hard to appear as a single entity doesn't help. But at least I think we can fix that. tracker, communication channel, rather than try to resolve differences on this list.

As a consumer of boost, if I cannot find the issue in github issues for that repository, I might assume the issue is not known. Taking the example of asio, which has no readme, how would I possibly know to go to chriskohlhoff's repository to submit an issue? I'm there right now and I have no idea where to submit an issue. If I poke around enough I might find my way to trac (as a ocnsumer). I agree; I can feel your pain. Boost's website needs a lot of attention to make it easier for maintainers to document how they prefer to be reachable.

I'm looking at the official github page for the official boost library asio, why are issues somewhere else?

My observation in the libraries I've wandered into is that issues in trac do not get a lot of attention. The backlog in many projects in trac today is littered with things that have valid patches but sit open literally for years.

Let's take this to the most extreme incarnation of what people have suggested - allowing maintainers to decide:

Imagine the confusion from a consumer of boost, if each boostorg repository had its own completely separate way of recording and tracking issues. I would find that quite frustrating, whereas if I can always go to one place (the issues tab in the *official* repository) to look for known issues, just like I can go to one place to look for open pull requests, that makes more sense.

It may make sense for someone who believes to be a "boost consumer". But that term is ill-defined, as "boost" isn't really a well-defined entity, as far as development is concerned. You really need to understand what boost *libraries* you are using (or "consuming", if you really have to use that term). And once you know that, you should be able to figure out where to look for and report issues.

My personal preference would be to require github issues be enabled and used for all official boostorg repositories, and that trac be deprecated and accept no new issues. This is what end users who consume boost expect. This will make it easier for issues to be reported and dealt with. Isn't that what we want? We should not make it difficult to submit issues on boost libraries to make it easier for maintainers. We should make it easier for consumers and encourage them to want to use more libraries.

While I personally agree, I don't think this is a choice anyone can impose on the people who have to maintain the individual boost libraries. We may encourage library maintainers to use a particular issue tracker, but ultimately the choice is theirs. Stefan -- ...ich hab' noch einen Koffer in Berlin...