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

Subject: Re: [boost] Boost Trac, random, No-Maintainer?
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-10-09 03:10:05

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_at_[hidden]> wrote:
>
>> On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost
>> <boost_at_[hidden]> 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.

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.

> 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
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...