MB development focus and issues

[ijabz]

@reosarevok

In that case, we could do the generation somehow

Yes, sure that would be fine. I totally agree makes no sense to add the same data two times.

@reosarevok

The problem with all this is mostly manpower to both write and maintain this UI

Or is it that focus have moved somewhere else ? I get the feeling the management are more interested in these new (and more peripheral projects) such as CritiqueBrainz and ListenBrainz then the core MusicBrainz product.

[reosarevok]

@ijabz

Or is it that focus have moved somewhere else ? I get the feeling the management are more interested in these new (and more peripheral projects) such as CritiqueBrainz and ListenBrainz then the core MusicBrainz product.

There’s two full time developers exclusively on MusicBrainz (plus more on Picard), so that’s as much as we have ever had Sure, there’s a focus on other projects as well, but I think suggesting MB is been half-abandoned is unfair. There’s just a lot of things we want: work is ongoing on entity attributes, alternative tracklists, and porting the UI away from Template Toolkit.

[ijabz]

@reosarevok

but I think suggesting MB is been half-abandoned is unfair.

That would be unfair and I wasn’t suggesting that. I just have not noticed any major improvements in MusicBrainz for a number of years, the releases seem to be quite small and mainly bug fixes,

Server update, 2018-01-24

Server update, 2018-01-10

Server update, 2017-12-21

Server update, 2017-10-31

yet over the same period a number of completely new projects have been delivered.

[reosarevok]

Fair, although I must say most of that work on ListenBrainz and the like has happened via Summer of Code projects (only recently have we gotten a side-project dev). Sadly, people just don’t seem to want to pick MusicBrainz projects (probably because they’re scared of Perl). Otherwise we’d have genres by now, for example…

There’s a large UI overhaul planned for this year, so there should be more noticeable changes coming Hopefully we can get some classical-related improvements there too.

[ijabz]

@reosarevok

Sadly, people just don’t seem to want to pick MusicBrainz projects (probably because they’re scared of Perl).

The trouble is that Perl is both dull and poor. There is no sensible reason for someone voluntarily bothering to learn Perl now, it would be like learning COBOL. So certainly moving from TemplateToolkit from React.js is a good start, but really Perl needs replacing over time (with Python)

[reosarevok]

I split this into a different topic because it was going too off-topic

@ijabz

really Perl needs replacing over time (with Python)

I don’t necessarily disagree that Perl is getting old and it might make sense to move to something else (although I don’t really agree it’s “dull and poor”) but if you want new features, this is not how we get developer time for new features

[ijabz]

@reosarevok

but if you want new features, this is not how we get developer time for new features

Well, no it isn’t in the short term since it gives existing developers even more work to. But in the long term if it makes it easier for new developers to contribute then it would help. Also a modern programming language would make all development easier and quicker since it would be more powerful and require less code to be written, and would be easier to maintain.

[obtext]

It’s probably true that a Python codebase would attract more volunteers to work on it. But porting it would be a Herculean task. Today there are 1610 *.pm files in the repo totalling 168,240 lines. And I’m not sure how feasible ‘replacing over time’ is for something like this.