Re: [boost] Issues without Trac [was boost.org https certificate expired 4 month ago]

Subject: Re: [boost] Issues without Trac [was boost.org https certificate expired 4 month ago]
From: Fletcher, John P (j.p.fletcher_at_[hidden])
Date: 2015-08-14 12:35:44

On a related issue, when I started to be a maintainer of Phoenix at the beginning of 2014, I requested a password for Trac to be able to change the status of issues as they were resolved.  I followed the requested procedure and never received an answer.  This was after the change to github for the files, so I have a password for that.

If there is a new system could we get the password system sorted as well?

Thanks

John

________________________________________
From: Boost [boost-bounces_at_[hidden]] on behalf of Robert Ramey [ramey_at_[hidden]]
Sent: 14 August 2015 16:46
To: boost_at_[hidden]
Subject: Re: [boost] Issues without Trac [was boost.org https certificate expired 4 month ago]

On 8/14/15 6:45 AM, Stefan Seefeld wrote:
> On 14/08/15 09:33 AM, Glen Fernandes wrote:
>> What else do we use Trac for now besides bug reporting? Is there a plan to
>> move to something else? (I couldn't find the thread that discussed a move to
>> Github issues).
>
> I think it might be best if such a decision didn't have to be taken for
> all of Boost at once. Why can't individual project maintainers decide
> for themselves (and their respective communities) what tools to use ?
> For example, I'm actively encouraging new Boost.Python issues to be
> filed on github, and I have documented that in the Boost.Python website
> (http://boostorg.github.io/python).
> I find that github makes it easy to set up project-specific websites,
> issue trackers, and wikis. (The only thing missing are mailing lists.)

This is a natural evolution of the boost modularization effort.  In my
view their is not reason why all libraries need to use the same issues
database.  This was one of the proposals which I made at my Boost 2.0
presentation at C++Now.  The www.blincubator.com libraries page presents
as prototype of how this would work. The library page presents a common
facade which has pointer to the library's issues database and other
information.  Something like this could present a common interface for
boost libraries while still permitting library authors to select the
most appropriate solution.

Robert Ramey

PS - slightly off topic - I believe that a more recent version of TRAC
can support keeping issues in both githup and the local trac database.
So an upgrade here would be very helpful.

RR


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost