[simonw]

I absolutely loved Trac. Getting a Trac setup as step 1 in starting a new open source project was just an unbelievable amount of friction.

Fun fact: Django is still running on Trac today, and has been for more than 20 years now: https://code.djangoproject.com/timeline

(I was not involved in setting that one up, though it's possible I helped get the private Trac that pre-dated it running, I honestly can't remember!)

[mbreese]

Trac was great.

But, my first issue tracker was bugzilla. Setting that up was a bit of a pain, and it didn’t integrate well with anything, but it was very satisfying to see “Zarro Boogs”.

[bombcar]

Bugzilla was relatively painless to setup but it already had a bit of the Jira going on - in that it had SO MANY OPTIONS!

I remember being interested in MantisBT and a few others (Launchpad for BZR?) mainly because it seemed they made a bunch of decisions for me.

[mbreese]

It's a bit fuzzy, but what I remember was getting it running was painless -- but there was a ton of effort in getting it configured.

In retrospect, it was probably the flexibility of projects like Bugzilla that heralded the "opinionated" approaches to software that followed. In many ways software also follows the patterns of the language they are written in . Bugzilla was written in Perl, so of course there is more than one way to do anything.

I had forgotten about Mantis, but that was the first tracker that the non-programmers in our group were comfortable using. It is a bit funny how quickly we all migrated to Github as a larger community as it became the default for just about everything.

[bombcar]

It's fun when you find these various things still in the wild - they're all still out there!

https://dwarffortressbugtracker.com/my_view_page.php

[theshrike79]

Bugzilla was too big/complex for pretty much every company I ever worked in :D

Trac was perfection. Self-hosted and just the right amount of features.

[vbernat]

I've switched to GitHub from Trac because of spam. Despite using Akismet and bayesian filters, on a small instance, there were still several spam tickets if you didn't require an account (for the details, https://vincent.bernat.ch/en/blog/2011-migrating-to-github). I am a bit amazed that Trac still exists and is maintained today.

[the_mitsuhiko]

Trac is in many ways what motivated me to build out an app in Python rather than in PHP for redistribution. It had a great plugin system!

[noir_lord]

I liked bitbucket, it did its job, it didn’t break for me and I preferred mercurial.

Employers used GH so I switched but even now I use GH as a dumb git endpoint and do all my build/deploy with docker and shell scripts so switching for me is extremely cheap.

For work stuff I’ll use whatever I’m paid to use if I don’t get to make the call just as it was back in the svn days.

[dijit]

Weirdly, I also have fond memories of Trac despite absolutely despising it at the time for “doing too much and excelling at nothing as a result”.

I guess that award goes to Gitlab now, which I will probably also remember fondly.

[saghm]

I like Gitlab fine by ignoring pretty much everything it does other than host the source code and let me view READMEs in the browser (and for work, also merge requests). In general the more I have to use anything other than those, the more frustrated I get, which was also how I felt about Github in the past. I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard. There are an awful lot of tabs on the left any time I look for something through those menus though, most of which I don't know what they do and I would probably not be happy to have to learn.

[dijit]

> I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard.

Honestly, Gitlab's CI is one of its killer features.

I really enjoy Gitlab CI.

But, nearly everything else (kubernetes management, AST, AI "DUO", work items, milestones, snippets, workspaces, "operations", "security dashboards", "value stream managements", "service desk") - ugh, awful.

I guess some of the artifact repository stuff is nice, but like; their terraform repository is probably the worst of all choices, all the downsides of the HTTP state backend and no upside..

It's so hit and miss; but! the CI is actually good..

[saghm]

I don't hate using Gitlab CI once it's set up; I just hate "put shell scripts in YAML to define how this should work". The least annoying experiences I've had with them are when every entry is literally just a single line that invokes an external script; shell scripting is already annoying enough without having to also spend the time to understand a YAML schema for what order they get invoked in and what environmental variables are in scope (not to mention what the implicit inputs are; a few months ago I tried to add a task to run some check on the commit message for an MR, and I found that even on repositories where the merge commit option is disabled in favor of squashing or fast-forwarding, the top commit message is still a merge commit).

[dijit]

Ah, super valid point.

I use the command invocation to run python scripts. I tend to believe that CI is just a controlled way to do things you would do locally.

[saghm]

Somehow most teams I've worked on ended up with the worst of both worlds: lots of stuff in the CI yaml file and then still shelling out to a bash script at the end to run the tests. Neither the config or the script is enough to understand what's going on, and woe to anyone who tries to invoke the scripts locally with the assumption that the scripts don't implicitly depend on the extra scaffolding in the YAML.

[cmrdporcupine]

GitLab's chief problem isn't that it does too much, it's that they really need to work on UX.

Everything is deeply nested. Many things hard to find. And the UI can be strangely slow or awkward in spots.

I recently worked a job where the client migrated to GitLab from GitHub at my suggestion. And while I think there was on the whole satisfaction with that, it did some with its own frustrations as well.

[jamesfinlayson]

> I guess that award goes to Gitlab now

Painfully true - I remember a company I was at replacing GitHub and a bunch of other tools with GitLab because it was better to pay for one tool that does it all. Kind of.