Wine Experimenting With GitLab For Improving Development

[Weasel]

Yuck. Takes exponentially more time to make Merge/Pull requests than to submit patches which can be done with a personal script without even requiring any branches.

[sinepgib]

Yuck. Takes exponentially more time to make Merge/Pull requests than to submit patches which can be done with a personal script without even requiring any branches.

OK boomer.

[alex19EP]

IMHO GitLab is completely unsuitable for people who use a screen reader or have slow internet! If you really support accessibility, it should be your priority...

I am a blind screen reader user. I am also Arch Linux package maintainer. we are using gitlab at Arch Linux and I don't have many problems with accessibility. especially in new versions. yes, they are still far from the convenience of github, but everything is not as bad as you say.

[BratishkaErik]

I am a blind screen reader user. I am also Arch Linux package maintainer. we are using gitlab at Arch Linux and I don't have many problems with accessibility. especially in new versions. yes, they are still far from the convenience of github, but everything is not as bad as you say.

Looks like this is only my problem... This is very good

[alex19EP]

Looks like this is only my problem... This is very good

if you need any help with gitlab with screen reader pleas email me at alex19ep @ archlinux.org

I will be happy to help.

[Weasel]

OK boomer.

You must be one of those who codes in stuff like UE blueprints and thinks he's a hot software developer.

[sinepgib]

You must be one of those who codes in stuff like UE blueprints and thinks he's a hot software developer.

Nah. I don't know what's a UE blueprint, I use Vim. Your comment sounds much more like someone who thinks he's a hot developer really.
I get it, you have your scripts, yadda yadda. Using a web service has many more advantages, and you can script against an API anyway.
The biggest is that it lowers impedance for one time contributions. You have a single GitHub account (I know, here it is a self-hosted GitLab) that you use to quickly create PRs. You don't need to subscribe to mailing lists where you'll receive patches you don't care about, checking now and then on pending patches is easier, etc.
Writing those scripts probably took much longer than creating an account.

[arQon]

I disagree on the only relevant part being how the team uses it. Like it or not, the bug tracker is an interface with end users who are often not as skilled as the team. It needs to be approachable.

It ... really doesn't - at least, not in the way that you seem to be arguing.

Even just within the context of WINE, "this POS doesn't work" has actual value how, exactly? Are you suggesting that a user who can extract the call stack / error message / etc needed to file "useful" a bug in the first place will somehow be utterly stymied by a button that says "Report a bug" just because it's presented *as* an HTML button rather than an animated image with rounded corners? Because that seems unlikely to me.

Rather than us going back and forth saying "You're wrong", "No, you", how about you give me a couple of features from your favorite tracker that bugzilla needs. Or if you prefer, tell me what's "unapproachable" about it that's better handled by something else. Or do you just mean "xyz uses 800MB of CSS and bitmap assets to present exactly the same form, but it's prettier"?

But I digress. I think you've missed my real point, which is that what actually matters is whether or not the dev team is *draining* the tracker, and that's entirely a "social" issue, not a technical one. Very few developers, ever, have been in a position where they can honestly say "You know, we WOULD have fewer bugs, but the tracker just sucks so badly that we can't get to work on them fast enough". OTOH, plenty of teams (or their managers) have *dis*honestly made claims along those lines in an attempt to dodge responsibility for their failure (i.e. the "I don't WANNA fix our bugs, I wanna play with $new_buzzword / watch cat videos / etc" mindset), gone through hugely-upsetting migrations to the Great New Hype, and... well, I'm betting you can guess what the end result of all that actually is.

> Can you explain further here? I don't really understand why you would need to do that.

Umm... because you do. I'm not really sure I understand the question, but:

Say you have a complex bug. It starts with the initial report, with a user saying "thing x doesn't work". QA tries it, says "it works for me", kicks the bug back. User returns with more details, a handful of screenshots, and so on. QA still can't repro it. Time passes, another user manages to run into the same bug, metoos the report, and adds more details, more screenies, and so on. QA comes back to the bug, manages his first repro of it, and kicks it to a developer. The dev can't repro it either, but MAYBE gives the code a quick skim, says he doesn't see any obvious cause in there, but will ask around. You're now already at a dozen pages, and work on actually *fixing* it hasn't even started yet.

Time passes, and eventually the bug *maybe* gets a reliable STR and/or lands in The Hero's hands. The Hero spends weeks digging through it all, painstakingly single-stepping through 8 different threads just to figure out where to *start* looking for the cascade that leads to the problem. But this bug is a total bastard. The first "solution" turns out to be incomplete. The second one turns it into a heisenbug. The third one gets closer, but still doesn't 100% it.

ALL of that is in the tracker, because it's institutional knowledge at this point and The Hero needs it all there just to stop their head from exploding, or for when he gets back from vacation, or in case he gets bused.

Eventually Our Hero figures it all out. Maybe the fix is a dozen lines in what looks like a completely unrelated area. The *commit* is easy: it's basically "do x differently - fixes #2345". But the *code*? The code says "// initialize the wooplickers. this HAS to be done in this exact order or the grikflenchers will fall over when called with via Pritzjink::Jinkworfle after an incomplete thripiong. don't even THINK about touching this code unless you've read and fully understand http://bugzilla.our.com/bug?2345". the underlying cause of the bug is so complicated that any attempt to explain it in detail is far too long to go into the code itself.

When the org moves to the New Hype, only the open bugs at the time are copied over, because who cares about history? If you're lucky, MAYBE the new tracker has added a comment to the bug saying "Imported from bugzilla 2345" that you can find with a text search. Did the screenshots come with it? The next time someone has to deal with that code, there may be no way for them to understand what's going on in there without spending weeks redoing all the investigation the Hero did, and without the guidance of his notes it may even be beyond them entirely.

History matters, and in a well-managed project the tracker represents not just the bulk of that history but every new task etc too. You wouldn't reinitialize your SCCS after each release, would you? You have the current code, so you're "not losing anything" if you do - but projects don't do that, because "history" means "knowledge", and rediscovering that knowledge burns time and resources. Trackers invariably contain more knowledge about some parts of the code than the code itself does, and every time you jump to a new one you at best disconnect that knowledge from the indexes to it, and at worst lost it entirely. Taking on that risk just to chase this year's fad because "oh no, the UI isn't 'modern' enough" is stupid, plain and simple.

> Well, Atlassian tools are known for being a POS.

And yet, a few years ago an enormous number of projects DID jump to it, because of the supposedly "more approachable" UI argument that you made; or because "Look - you can associate a wiki with your project and keep all your documentation there!"; or because in-house infrastructure is "like, soooo 1990s, LOL, all the cool kids are using the cloud". Doesn't matter that it only works in IE, or that a one sentence bug needs to download 800MB of CSS and JS, or that the search function only indexes subjects and not comments, or etc etc: it's NEW, and therefore automatically better! And it's "optimized for mobile", because everyone knows developers don't have access to real computers.

Gimmicks and excuses do not, never have, and never will, make any real improvement to any project. Blog posts about how great the new bug tracker is - look at these cool charts I made with it! - have exactly zero impact on what matters: the quality of the end product. Migration comes at potentially huge costs, and is nearly always driven by NON-technical reasons: as a stalling tactic for an under-performing team; a way to "lose" a few thousand bugs that are making the numbers look bad, and so on.
Projects that are not dysfunctional (thanks to dead weight, poor leadership, etc) in the first place perform at least as well with "primitive / ugly / whateverBS" systems as they do with something that implements whatever this month's collection of buzzwords is, because the backend is what matters.

Again, you can't solve a "social" problem with technology, but especially so when that "technology" isn't anything other than just a fresh coat of paint.

I think you've got a bit of a false equivalence going on. We aren't talking about something meaningful like migrating from CVS to git: this is literally just changing a UI, and in many "modern" cases to something that *removes* meaningful content or functionality the same way shit-UI teams like Google remove features or hide them under 4 layers of menus behind an unrelated icon that needs hand-editing an XML config file to enable at all, because "users are stupid, and words are scary".

Change for the sake of change isn't just not the same thing as addressing a problem, it's an additional cost *on top of* the problem. When the problem is an imaginary scapegoat in the first place, that's a pretty large net negative.