Re: [proaudio] Future/cleanup of proaudio overlay

Good evening everyone!

Wanted to send a quick update about this to everyone.

We've had some chats on #proaudio-overlay on freenode about what to do to fix the proaudio overlay and the consensus was that it made more sense to start from a clean slate than to try to cleanup the existing ebuilds.

So we've gone ahead and started a fresh overlay on GitHub to which we only add ebuilds that we can guarantee we can maintain.

"We" currently consists of 5 people. We've created a new organisation on GitHub https://github.com/gentoo-audio that will maintain this overlay.

There's already a new, pure and pretty empty repo ;) in place which we're working on to add ebuilds to https://github.com/gentoo-audio/audio-overlay

Basic CI and workflow is already in place as well!

We know it'll be a significant amount of work to get enough relevant packages in place but we're also pretty happy and energized because we can finally start fixing the stalemate that has existed for a long time :)

If you have a package you care about and want to maintain it please let use know either here or via #proaudio-overlay and we can add you to the team.

Thanks and have a nice evening!

Simon

On Tue, May 16, 2017 at 12:10 PM, Marc Joliet <marcec@xxxxxx> wrote:

Am Sonntag, 14. Mai 2017, 02:13:49 CEST schrieb Reuben Martin:

> A large portion is obselete junk that could be dropped, or things that have

> since been included with portage, while at the same time there is software

> that doesn’t exist in the overlay that should probably there.

I've noticed this, too. I have a pull-request open on the GitLab fork of the pro-audio overlay that cleans up a bunch of python.eclass usage [0], and another branch (no PR yet) that cleans up a few more things. Both change sets delete various packages that have been dead upstream for a looong (sometimes not quite so long) time. Sadly, I haven't had the time since then to work on it more.

> Also, it might be prudent to move to git.

I very much agree with this. I'm primarily a drive-by contributor, and git lends itself to this more, because the PR based workflows are relatively friction-less (yes, even a little bit of friction can delay me from submitting a change). Even PRs via the ML would be OK for me, albeit a bit painful review-wise. That latter is especially important to me (and is the reason I haven't just merged my own PR on GitLab with my newly-found developer status).

So I'll start hanging out on IRC, although I'll probably only be listening (again, I'm somewhat busy ATM).

[0] https://gitlab.com/proaudio/proaudio/merge_requests/5

Greetings

--

Marc Joliet

--

"People who think they know everything really annoy those of us who know we

don't" - Bjarne Stroustrup