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
> 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
>> 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
- 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.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk