Boost logo

Boost :

Subject: Re: [boost] Trac
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-08-02 08:35:41

On 2 August 2018 at 05:45, James E. King III via Boost
<boost_at_[hidden]> wrote:
> 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.

As an observer of numerous discussions, I find process collecting
agreements frustrating:
- a proposal is discussed, 2, 3, 10, 15, ..? people participate
- agreement is nearly completed
- suddenly, an objection arrives from someone
- whole agreement reached so far collapses
- no one feels like challenging the objection with simple "you've been late",
- steam is out, proposal dies

The majority should be considered within those expressing their vote.
I'm not aware of any formal voting scheme in Boost though.

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

This is what I'm going to do for GIL:
- not migrate of any Trac issues to GitHub, but work to clear them all
as high priority task after Boost 1.68 is out.

Best regards,

Mateusz Loskot,

Boost list run by bdawes at, gregod at, cpdaniel at, john at