...

The title pretty much says it all. Is there a reason for disabling GitHub issues on the master project?

Because we're still using Trac for bug reporting.

I would pretty much recommend, you consider migrating from Trac to another (more modern) bug-tracking system that is more responsive and has less problems with modern browsers. For example, I just added a bug-issue to Trac and realized, that it is not really working well: * It takes more than a minute to display an answer-page to my request to create a new ticket. * It then complains about me being a spammer, because I put some external links into the ticket's message. * It still allows me to try to convince it that I am a human by trying to show me some Google-Captcha. However, that captcha and the answer-form is not displayed by any browser I tested, because the captcha is linked via a non-secure HTTP-iframe, while the surrounding page requires HTTPS. * And even if one manages to display and pass the captcha and to HTTP-post the answer to the server (all done by dynamically modifying the displayed webpage using a Dom-editor like Firebug) Trac still thinks one is a spammer (which in that case should be a hacker ;-) ). I quick google-search makes me think that it should not be too hard to migrate from Trac to e.g. Redmine and convert all Trac-tickets into Redmine-tickets. Maybe, that is a viable way to go? Best regards, Deniz

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Louis Dionne Sent: 23 April 2015 17:19 To: boost@lists.boost.org Subject: Re: [boost] [Master project] Switch from Trac to another Bug-tracking-system (was: [Master project] GitHub issues disabled)

Deniz Bahadir writes:

...

...

...

The title pretty much says it all. Is there a reason for disabling GitHub issues on the master project?

Because we're still using Trac for bug reporting.

I would pretty much recommend, you consider migrating from Trac to another (more modern) bug-tracking system that is more responsive and has less problems with modern browsers.

[...]

+1

If the community wants to make a change, I think GitHub issues would be the most appropriate system for this, for obvious reasons since the repos are now hosted on GitHub.

However, there are probably several valid reasons to stay with Trac too, so let's just say I'm expressing a naive wish.

Don't forget that many (good?) libraries use release notes and history that link to Trac #numbers to record bugs and fixes and enhancements. Any new system must continue to provide access the information that these provide. This might be achieved by keeping Trac going (forever?) Conversion sounds non-trivial? Any new system also needs to provide an equivalent mechanism to link to bug fix info. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On Fri, Apr 24, 2015 at 11:46 AM, Deniz Bahadir wrote:

To be honest, I have not used too many different ticket-systems myself. However, as you might have noticed, I have some experience in working with Redmine and my impression is, that it would be a big improvement to using Trac and that a migration and database conversion from Trac to Redmine would be possible.

As Boost is now using Github, wouldn't Github issues make more sense? No separate Trac / Redmine account would be needed, Boost would not have to maintain the issue tracker themselves. -- Olaf

I would like to point out that Django project had this same question posed in 2012. At the time they decided to keep using trac, as Github did not provided enough functionality. The critical conclusion from the core team is summarised here: https://groups.google.com/d/msg/django-developers/eDzFycvjPJo/j42FGl07z-kJ; the main arguments are presented below. Regards, Jorge Aymeric wrote: """ I just looked at it again and here's what I noticed: - there is no workflow, so we lose the ability for the community to triage tickets; - we can't upload patches (which forces every contributor to sign up for GitHub and learn git) or arbitrary files (like logs, screenshots, tracebacks: not everything is a pull request); - there isn't a notion of "component", so there's no way to ask "give me the list of all contrib.auth tickets, so I can find the duplicate quickly"; - we can't put customized flags on tickets (easy, ui/ux) -- there are tags, but the result of the "Keywords" field in Trac shows the limits of unstructured tags; - it's hard to navigate when there are more than 200 open tickets on a project. """ Justin Bronn wrote: """ GitHub's issue tracker is so much worse than Trac I don't know why we're even considering it. I can attest it has NOT gotten better with age, and large projects on GitHub can't use it either. For example, both Chef and Puppet are hosted on GitHub yet use their own ticket solutions (Puppet uses Redmine, Chef uses Jira). The Pinax folks wrote their own issue system rather than using GitHub's! """ On Sat, Apr 25, 2015 at 11:18 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Deniz Bahadir Sent: 24 April 2015 10:47 To: boost@lists.boost.org Subject: Re: [boost] [Master project] Switch from Trac to another Bug-tracking-system

...

...

...

...

Because we're still using Trac for bug reporting.

I would pretty much recommend, you consider migrating from Trac to another (more modern) bug-tracking system that is more responsive and has less problems with modern browsers.

...

...

Don't forget that many (good?) libraries use release notes and history that link to Trac #numbers to record bugs and fixes and enhancements.

Any new system must continue to provide access the information that these provide. This might be achieved by keeping Trac going (forever?) Conversion sounds non-trivial?

Any new system also needs to provide an equivalent mechanism to link to bug fix info.

As long as the release-notes only mention the issue #numbers, it should be enough to make sure, that the new ticket-system assigns the same ticket-numbers to the converted tickets. Probably, this should be possible (as long as the new ticket-system supports migration from Trac, which is a prerequisite anyway). For Redmine I found a wiki-article about migration from Trac to Redmine, which states that ticket numbers stay the same (if the Redmine-database is empty prior to migration). [1]

For the case that some release-notes have direct web-links to Trac, not only issue-numbers, the domain "svn.boost.org/trac/" should still be available and automatically forward the browser to the corresponding address of the new ticket-system. For example (if using Redmine as new ticket-system):

https://svn.boost.org/trac/boost/ticket/11224 ---> https://redmine.boost.org/issues/11224

Some libraries do use the direct web-link to Trac item - it is by far the most convenient for users, so this should continue to work.

...

To be honest, I have not used too many different ticket-systems myself. However, as you might have noticed, I have some experience in working with Redmine and my impression is, that it would be a big improvement to using Trac and that a migration and database conversion from Trac to Redmine would be possible.

This is reassuring - but others have recommended using GIT issues (but without considering any migration tools).

Are you offering to do the migration to Redmine?

(Personally, I have had no problems with Trac - just works for me).

Other views from experienced/disgruntled users?

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

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

I tried a lot of these tools for different projects and through time I learned that: - TRAC is clearly the most flexible of trackers, because of the custom workflows. However it's one of the slowest, apparently less maintained and clearly not up to date on the web-ui side of things. - RedMine is a better TRAC on all fronts except workflows are not as flexible. That being said, it's not really optimized for high performance, but it's certainly the best option when upgrading from TRAC and you don't want to lose everyone. As pointed a few years ago, there have also been a fork of Redmine in the past (I think it was unsuccessful) because of issues with the Redmine author way of working which splitted the team at the time. - JIRA is very good too and apparenly scales better than RedMine. It might be a bit heavy on the UI though and my impressions on the configurations were not stellar. Although it's still good. (Ogre3D team have been using it for some time instead of mantis and seem very happy with it) - github and bitbucket: simple and integrated with their host, but really simplist for big projects. Also I believe there are extensions to TRAC, JIRA and Redmine for linking github/bitbucket with the tracker, so there is no good reason to use github tracker other than when you don't want to manage/configure your tracker and your project is not that big. I tried some others (Mantis, FlySpray, etc.) but I think they are not relevant to boost. Also noticed that some more-than-just-a-bug-tracker kinds of tools might be interesting, in particular if there is a change in how code reviews are done in the future of boost libraries. For example some big companies like Facebook uses Phabricator ( http://phabricator.org/) that might be useful for a big library of libraries like Boost, or not. I didn't try Phabricator yet so can't comment on it (other than their website is quite humoristic).

On Sat, Apr 25, 2015 at 6:04 PM, Rob Stewart wrote:

On April 25, 2015 9:31:56 AM EDT, "Klaim - Joël Lamotte" < mjklaim@gmail.com> wrote:

...

- RedMine is a better TRAC on all fronts except workflows are not as flexible.

What is it can't be done with Redmine?

Last time I checked (4-5 years ago, but from what I read it didn't change yet) the workflow system in Redmine wasn't as flexible as TRAC one because Redmine organise workflows as a state machine (table of relationship between events and states, more or less like boost.msm) while TRAC use a directed graph of states expressed using a dsl in a config file. In most cases you don't see the difference (except TRAC require modifying a file). You see the need if you setup a very complex workflow with custom preconditions for each state, which can happen in some kind of complex organisations but it's not very common.

From what I understand from the current Boost TRAC workflow config, it would not be a required feature at all.

TRAC also have a way to customize the state changes buttons to be displayed action sentences instead of having just combo boxes to change states like RedMine. For example if you have a ticket on state "in-progress" in redmine, you have to open the combo box in the ticket to chose between other states like "fixed" or "wontfix" or "rejected". In TRAC you can make it display actions in a ticket as action sentences like "Mark this bug as fixed. (switch 'fixed' state)", "Reject this bug. (switch to 'rejected' state)", "We will not fix this bug. (switch to 'wontfix')". Long time ago I made a ticket to RedMine to add the same feature (couldn't help with Ruby at the time) but I don't think they did it yet. It's a usability feature which help guiding new users trying to use the tracking system, but it's far from critical. And I would say it would be the only advantage of TRAC compared to other tools as of today, so it's not really a feature to consider.

___ Rob

(Sent from my portable computation engine)

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

Are you offering to do the migration to Redmine?

That was not really what I intended. I have not much experience in being a (sys-)admin. I am a user of Redmine and a few years ago I was co-administrating a Redmine-installation with an experienced sys-administrator. (However, this was an already set-up installation of redmine.) However, if a change to Redmine is really considered by Boost community I would help with doing so or, if nobody else wants to be in charge for that migration, I would even try it by my own. (No success guaranteed.) Help of a sys-administrator for Boost-domain would be very much appreciated (and required, at least for accessing the Trac-database etc.) Deniz

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 25 April 2015 18:55 To: boost@lists.boost.org Subject: Re: [boost] [Master project] Switch from Trac to another Bug-tracking-system (was: [Master project] GitHub issues disabled)

Personally I've been always very happy with TRAC and still am.

Ditto. Never had any trouble with TRAC.

That's not saying that I would object to a change if there was a strong consensus for something different and it was supported by people have a wider experience in this than I do. There is something to be said for not changing something which has been working well enough not to create problems.

If it ain't broke, don't fix it? Just another 2 cents. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On Sat, Apr 25, 2015 at 7:55 PM, Robert Ramey wrote:

Personally I've been always very happy with TRAC and still am.

That's not saying that I would object to a change if there was a strong consensus for something different and it was supported by people have a wider experience in this than I do. There is something to be said for not changing something which has been working well enough not to create problems.

What's your definition of working well enough? Trac seems to come up time and time again.. It's extremely slow, posting a comment can take a minute. Captcha is broken, so some people can't post stuff at all. Who's in charge of Trac? -- Olaf

On 03/05/2015 17:10, Konrad Zemek wrote:

Hey everyone,

2015-05-03 15:00 GMT+02:00 Olaf van der Spek :

...

On Sat, Apr 25, 2015 at 7:55 PM, Robert Ramey wrote:

...

Personally I've been always very happy with TRAC and still am.

That's not saying that I would object to a change if there was a strong consensus for something different and it was supported by people have a wider experience in this than I do. There is something to be said for not changing something which has been working well enough not to create problems. What's your definition of working well enough? Trac seems to come up time and time again..

It's extremely slow, posting a comment can take a minute. Captcha is broken, so some people can't post stuff at all.

I've been able to confirm that, but *only when posting not logged in*. Which of course is what casual bug reporters need to do :( I'm fairly sure the issue is with one of the spam-filtering strategies Trac uses, but I'm not sure which is the culprit, will try to investigate without opening the um.. floodgates. BTW the captcha doesn't show up (at least in IE) because it's a non-secure item in an otherwise secure page. I suspect this is an issue with Trac itself? Maybe we need to upgrade the Trac install, but I have no idea how to go about that. I might experiment switching it to a different captcha. John.

Most other open source projects demand a login to post any content at all.

Logins can come from OpenID, Google, Facebook, StackExchange or a multitude of sources to save the user creating a new account.

But not for TRAC :( Meanwhile.... I think I've solved the captcha issue (at least for IE). We'll have to see whether it results in a flood of spam or not, can't figure out the slow response times though.... and they are *very* bad at present. BTW, while Git issues look rather primitive, they appear to do pretty much everything that the current TRAC system does? How the heck you would migrate from one to the other is a whole other can of worms though.... John.

On Sunday 03 May 2015 20:09:14 Niall Douglas wrote:

The other thing is that I feel hesitant loading all one's crown jewels into github. It is a commercial company which could backfire on those too reliant on it one day.

Although not for its commercial nature, it already did a few times for Russians. There have been a few cases of blocking github by russian internet providers because of some content in github projects.

On 05/03/2015 09:29 PM, John Maddock wrote:

...

Most other open source projects demand a login to post any content at all.

Logins can come from OpenID, Google, Facebook, StackExchange or a multitude of sources to save the user creating a new account.

But not for TRAC :(

Meanwhile.... I think I've solved the captcha issue (at least for IE). We'll have to see whether it results in a flood of spam or not, can't figure out the slow response times though.... and they are *very* bad at present.

BTW, while Git issues look rather primitive, they appear to do pretty much everything that the current TRAC system does? How the heck you would migrate from one to the other is a whole other can of worms though....

Whether one need to migrate is a separate question. Boost.Build has GitHub issues enabled, with Trac issues remaining in Trac. Admittedly, this means Trac issues stand a lower chance of been fixed, but then it feels that the rate of useful issue reports and especially useful patches has increased quite a bit. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

On Mon, May 4, 2015 at 2:06 PM, Michael Ainsworth < michael@michaelainsworth.id.au> wrote:

...

Whether one need to migrate is a separate question. Boost.Build has GitHub issues enabled, with Trac issues remaining in Trac. Admittedly, this means Trac issues stand a lower chance of been fixed, but then it feels that the rate of useful issue reports and especially useful patches has increased quite a bit.

The downloadable version of GitLab (an alternative to GitHub Enterprise) is open source, which I’ve used for multiple projects on two different installation sites. It has:

* A GIT repository per project. * A second GIT repository for the wiki. * A basic issue tracking system.

I’m not familiar with Trac, but it might be worth investigating.

To clarify for people who do not know much about the tools mentionned: GitLab: - repo management - pull-request/code-review management JIRA: - issue tracking - can be combined with other ihntegrated tools from the same company to do review and repo management and wiki (most of the time for free) RedMine: - issue tracking - wiki - forum (very close to TRAC features in general) Phabricator (didn't try it yet, in the process to do so soon): - issue tracking - wiki - repo management - (advanced) code review (pre and post commit) - patch/pull-request management - discussion forum Although if the main issue is sysadmin skills/time, upgrading TRAC first might be less expensive. 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...

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

On 04/05/2015 17:43, Robert Ramey 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 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. Hopefully a lot of this would go a way just by upgrading to the more recent version of TRAC

Maybe not the upgrade alone, the trivial installation (cgi behind Apache) is a huge issue as far as performance are concerned (I have one...). http://trac.edgewall.org/wiki/TracPerformance http://trac.edgewall.org/wiki/TracStandalone Sorry for the noise if it was already pointed out. Regards --- Alain

On Mon, May 4, 2015 at 5:43 PM, Robert Ramey 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-tp4... Sent from the Boost - Dev mailing list archive at Nabble.com.

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

On 4 May 2015 at 22:06, Michael Ainsworth wrote:

...

Whether one need to migrate is a separate question. Boost.Build has GitHub issues enabled, with Trac issues remaining in Trac. Admittedly, this means Trac issues stand a lower chance of been fixed, but then it feels that the rate of useful issue reports and especially useful patches has increased quite a bit.

The downloadable version of GitLab (an alternative to GitHub Enterprise) is open source, which I’ve used for multiple projects on two different installation sites. It has:

Gitlab is fine. However all the free tooling (Travis, Appveyor, Coveralls) does not have Gitlab integration, Jenkins does not have first tier support for gitlab, and all that makes life harder. Trac's single most important feature for us is its security record: http://www.cvedetails.com/vulnerability-list/vendor_id-8372/Trac.html Compare that to Redmine's: http://www.cvedetails.com/vulnerability-list/vendor_id-8599/Redmine.ht ml This is why our ancient Trac (v0.12) still hasn't been compromised, because nobody here is maintaining it. If that were a Redmine install it'd have been smashed to bits years ago. I hence vote to remain on Trac, albeit upgrading to v1.0 would be nice :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/