Re: [boost] [trac] new versions of boost

Subject: Re: [boost] [trac] new versions of boost
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-01-12 09:57:41

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener via Boost
> Sent: 11 January 2018 18:39
> To: boost_at_[hidden]
> Cc: Edward Diener
> Subject: Re: [boost] [trac] new versions of boost
> 
> On 1/11/2018 8:29 AM, Stefan Seefeld via Boost wrote:
> > On 11.01.2018 03:07, Raffi Enficiaud via Boost wrote:
> >> Le 02.01.18 à 11:08, Raffi Enficiaud via Boost a écrit :
> >>> Hi there,
> >>>
> >>> Would it be possible to add the next versions of boost to trac/milestones ?
> >>>
> >>> Thanks!
> >>> Raffi
> >> Kind reminder.
> >> Thanks
> >
> > I really do believe we should deprecate trac and encourage everyone to
> > use github. I understand that to some, having a single place to file
> > "boost issues" seems desirable, and for that reason they'd prefer to use
> > trac. But the reality is different: An increasing number of boost
> > projects migrate to github, and thus won't even listen to trac issues
> > any longer. So that boat has sailed already. It's time to acknowledge
> > that, and not make things worse by maintaining multiple trackers.
> 
> I agree with Stefan. But this needs some proactive actions first and
> probably some agreement with the Boost Steering Committee:
> 
> 1) Turn on Issues for every boostorg library in Github
> 2) Make an announcement on the website that all new bug reports should
> be either Issues or PRs on Github.
> 3) Encourage library authors to either clean up what is already on Trac
> or transfer Trac bug reports to Github issues or PRs for eventual handling.
> 4) Turn off Trac, if possible, for adding any more bug reports.
> 5) Announce a cutoff time when Trac will no longer be available for Boost.
> 
> Having two separate places to deal with bug reports for Boost libraries
> is not a good situation and having Github Issues and PRs is a much more
> flexible system for dealing with library changes than Trac.

But don't forget that Trac contains a lot of history of past changes that are still useful info today, so don't think of preventing read-access for many years to come.

And the documentation of each library should provide links to Github Issues and PRs, as 'good' libraries have been doing for their Trac items.  (Otherwise people will very probably never find things in the Github history?) Is anyone doing this yet?  And exactly how? 

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]