15 months without activity, time for a fork?

[MightyCreak]

Hi!

I really like Sonerezh but I see very interesting PRs piling up (notably from @gs11) and there's been no activity for 5 months.

I understand that @atomiix and @lGuillaume124 don't have time to maintain Sonerezh anymore, so I see two solutions: either someone else gets the access rights to maintain Sonerezh, or Sonerezh gets forked.

I'm not trying to troll, but I'm a bit frustrated by this stalling situation and I would like it to change sooner than later.

[gs11]

I agree, preferably access rights would be given for this repo. If not possible it doesn't matter for me who owns the new fork.

I sent an email inquiring about the status to the contact email at https://www.sonerezh.bzh/ a few weeks ago but no response as of yet.

[MightyCreak]

I would prefer that someone gets the access rights as well, I'm not fond of splitting communities :/

We'll wait for an official comment on this before taking any action (or, I hope not, a significant amount of time without comment)

[gs11]

Got a response from one of the devs:

The project is not dead and I check the issues & PR each time I can but I have no time to do anything else for now. We could say that it's a temporary pause. Guillaume and me really want to continue this project.

Feel free to fork our repo if you want to add those PR and add new features ;)

I'll merge my PRs to a new development branch on my repo. Feel free to use that if you'd like. I'll create PRs for all changes to this repo as well.

[MightyCreak]

Would have been nice if they would have give you the access rights though. Don't forget to give your branch name once you've created it, I'll probably use it on my main instance ;)

[MightyCreak]

If you could keep a journal of what you merged on top of the original repo, that would be great!

[gs11]

See the new development branch here: https://github.com/gs11/sonerezh/tree/development-new See changes merged in README.md :)

[MightyCreak]

@gs11 Dude, with the 'Removed slow subquery from albums view' PR, Sonerezh is amazingly faster! Thanks!

[MightyCreak]

Closing this issue since the gentle fork has been done. I hope that the Sonerezh devs won't take too long to port the features back. Thanks again @gs11, your work has already bring Sonerezh to a next level!

[nodiscc]

@MightyCreak I think you should reopen this, it will inform new users who may be wondering about lack of development activity.

I have uninstalled sonerezh for the moment since I don't use it that much and a viable solution has not been found (more manpower between the project). I also have trouble fixing my installation procedure (https://github.com/Sonerezh/sonerezh/issues/231). @gs11's fork looks good but a bus factor of 1 for an Internet facing application worries me a bit. I haven't found any decent alternative - all of them use weird stacks and/or advise piping curl to bash as root for installation (big no-no).

So I'm back to mounting my SFTP share and accessing the files directly (which frankly is not so bad because it allows actual file-level access, tagging, etc...)

I hope Sonerezh can be brought back to life someday. Thanks for all your work so far

[MightyCreak]

Reopening the issue, I thought this project would merge back the changes from the fork more frequently, but nothing's been done for 8 months now.

It is clear that gs11's fork is, right now, the best experience of Sonerezh (I'm using it right now).

So, until the commits from the fork are merged back here, and/or @gs11 gets write access to this repo, please use the fork here: https://github.com/gs11/sonerezh/tree/development-new

[lGuillaume124]

Hi,

The current version of Sonerezh was written when we were students, and we know we've made some annoying mistakes (like the database schema).

And that's why we started to work on a complete rewrite of Sonerezh.

The main idea for the new version is to split a big monolithic block into smaller minimalist projects. We've spent some time to seriously think about how to organize this new project:

1. The core of the new version must be minimalist, robust, and fast. We choose to replace CakePHP with SlimPHP to build a RESTfull API. The core doesn't provide any user interface. Only RESTfull endpoints to manage Sonerezh, and JSON formatted responses.
2. Remove the getID3 library, which is too big for us, and very slow. @atomiix wrote a small PHP library to parse and extract metadata from various audio files. It is more than 10 times faster than getID3 to extract what Sonerezh needs.
3. Use Composer to install and manage Sonerezh and its dependencies.
4. Once the core API is usable and standardized, we can start to build clients, and the community could create their own for various platforms.
5. We plan to use ReactJS or equivalent for the web UI.

By now I'm working on the core API because atomiix isn't available for the moment. The metadata parsing library works pretty well.

Here is a first overview of the API:

Hope it will help you to be patient.

[gs11]

Thanks for the update! The new architecture sounds promising and I like the design choices like modularization, REST APIs and the focus on speed & simplicity.

While UI coding admittedly isn't my strong suit, I could help out with stuff like architecture, DB design, API design, backend coding etc if you're interested @lGuillaume124 ?

[MightyCreak]

Sorry if I seemed impatient, I actually was a little 😐

I know you're investing your time in the next version of Sonerezh, but could you merge all the work done by @gs11? I know it would seem like a waste of time, but I'm sure it would help bring more user to Sonerezh (especially since the current official version doesn't work with PHP 7), and also keep the core users -- like us, and eventually it will help to wait until the next version.

Most of all, thanks for the update @lGuillaume124, it's really appreciated, and it's good to know you're still working on Sonerezh. As @gs11, I also like the new code design. Separating the core and the UI seems like an excellent idea to be able to create web app, as well as Android and iOS apps.

I read the API a little, I think it would be nice to have /albums/{id}/download, so it's possible to download a whole album and not just a track (which would need some kind of cache for the zipped albums).

How open source will it be? Do you already have a repo somewhere? I would honestly be pleased to help and bring suggestion on both the API and the UI. I'm mainly a user, but I also code (even though web dev isn't my strong suite).

Cheers!

[lGuillaume124]

I could help out with stuff like architecture, DB design, API design, backend coding etc if you're interested

Can you send your email address to hey@sonerezh.bzh please?

but could you merge all the work done by @gs11?

I'll see what can I do for it :)

How open source will it be?

Same license.

[gs11]

Cool, check your email! @lGuillaume124

[MightyCreak]

I know you're investing your time in the next version of Sonerezh, but could you merge all the work done by @gs11?

@lGuillaume124: Where are we on this subject? I've been rocking @gs11's fork for more than a year now and it works pretty smoothly on an old Debian 8 server.

Many thanks!

[MightyCreak]

Will be fixed with #339