Re: [boost] [Master project] Switch from Trac to another Bug-tracking-system

Subject: Re: [boost] [Master project] Switch from Trac to another Bug-tracking-system
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-05-04 14:42:44

On Mon, May 4, 2015 at 5:43 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> Klaim - Joël Lamotte wrote
> > On Mon, May 4, 2015 at 2:06 PM, Michael Ainsworth <
> >
> > To clarify for people who do not know much about the tools mentionned:
> >
> > ... snip ..
>
> I found this information very helpful.  FWIW I prefer simpler tools which
> mostly do one thing which can be composed with other simple tools.
> Basically, I prefer de-coupling in general.

I tried both aproaches for different projects and I tend to agree, except
when I have a lot
of libraries to manage.

By the way, wasn't there an effort to setup a review tool for boost few
years ago?

I don't see the alternatives
> offer anything really useful that we don't already have with TRAC.  The
> problems with track seem to be related to implementation details.
>

Well I didn't get into details but the implementation details like
 - performance
 - UX (user experience - efficiency of usage)
can drastically impact the experience, for example, of people wanting
to report issues and provide patches and that have to face something
slow and hard to understand or use.
So I wouldn't consider implementation as something to ignore here, it's
indeed
the main issues reported and have a huge impact (I've seen people forfeit
trying to post anything
in the boost TRAC).
The reason a lot of people would prefer to have everything in github
is that the experience is almost "fluid" for any github user wanting to
quickly
patch something in any library or report anything.

Anyway this is with small number of projects compared to Boost, and I
suppose
that the setup and hardware were radically different, so I don't know the
actual impact
of changing tools. It requires actually trying tools.

> Hopefully a lot of this would go a way just by upgrading to the more
> recent version of TRAC
>
>
I'm a bit surprised that the TRAC devs didn't progress faster in the last
years though.
No idea what is the performance or ux of the very last versions (didn't
have time to try recently).

> > Although if the main issue is sysadmin skills/time, upgrading TRAC first
> > might be less expensive.
>
> This is always a huge issue for boost.  The good tool which is hassle free
> is much preferred to the "best" tool which requires a lot of attention to
> keep running.
>
> > If I remember correctly, TRAC upgrading process is documented in their
> > wiki
> > http://trac.edgewall.org/wiki/TracUpgrade
> > I don't have sysadmin skill and I'm still poor at understanding how linux
> > works, however I did do several upgrades<
> > some years ago and there was'nt any issue I can remember.
> > That being said I didn't have a hundred projects to manage...
>
> Fantastic! we have a volunteer with experience !!!  Let's do this!
>
>
Haha well I would gladly help but I have strong doubts that I would be the
right person.
I'm not super familiar with unix environment and don't know how to make a
clean backup.
That being said, I could try (after you make a backup of course), yes.

> Robert Ramey
>
>
>
> --
> View this message in context:
> http://boost.2283326.n4.nabble.com/Master-project-GitHub-issues-disabled-tp4674622p4675049.html
> Sent from the Boost - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>