Re: [proaudio] Question for proaudio devs & team

[Xavier Miller <xavier.miller@xxxxxxxxx>]

Hello Nedko,

How can we contribute ?

To upgrade the pro-audio overlay, we need at least :
- enumerate all packages and versions in the dead overlay
- find the latest versions
- elaborate a priority list (by the needs of the contributors, in my  
case : rt-sources, jack, ...)
- upgrade each ebuild

At my side, I will locally bump all my used packages, then propose  
them for the overlay (which one ?)

If the pro-audio dev teal don't have the time, can we ask to "get the  
keys" and work on the tuxfamily hosted site?
Or ask Gentoo to incorporate pro-audio in a more maintained overlay?


Kind regards,
Xavier Miller.

Quoting Nedko Arnaudov <nedko@xxxxxxxxxxxxx>:

> Content-Transfer-Encoding: quoted-printable
>
> Xavier Miller <xavier.miller@xxxxxxxxx> writes:
>
> > Hello, is there no more maintainer ?
>
> To me, proaudio overlay appears to be inactive. I recently switched to
> gentoo and plan to invest some time in linux audio ebuilds. As wmladi
> (from laditools) was unusable because wmdocklibg is missing, I
> git-svn-ed and created a git branch where i'll push ladi related
> stuff. The repo can be seen here:
>
> http://nedko.arnaudov.name/git/cgit.cgi/proaudio-overlay/
>
> and cloned from here:
>
> http://nedko.arnaudov.name/git/proaudio-overlay.git
>
> my stuff is in the ladi branch, the master branch follows the svn trunk
>
> If proaudio overlay switches to git, more distributed development model
> will be possible. Maintaining master branch probably should remain but
> at least ebuild contributors/maintainers could merge important stuff
> without overhead of a central authority. Don't get me wrong, I'm not
> against proaudio central authoritiy. It is useful entity to provide
> proaudio overlay for users with less or missing packaging skills. It is
> useful to provide somewhat consistent policy. OTOH, I, as an upstream
> developer have some vision on proaudio stuff and it may collide with
> expectations or requirements of some other respectful folks (see
> jackdbus flamewar from May as an example). I prefer the packaging
> approach where user has the choice and packager provides it. This
> matches the gentoo philosophy but in reality ebuilds may give suboptimal
> set of choices.
>
> So there are two good things about distributed development model:
>  * split overlay policy enfororcement from ebuild contribution/maintainership
>  * allow merges between ebuild contributors without participation of the
>    central authority.
>
> As bad things I could imagine:
>  * it is not what is currently used and people may feel pain from
>    svn -> git migration
>  * it reduces the push to central authority to maintain something usable
>    by the users without packager skills.
>
> I have to admit that as a gentoo newbie I may have missed
> something. Especially branching overlays may not be good idea because it
> is alternative to the overlay mechanism itself. Please, tell me if it is
> so.
>
> --
> Nedko Arnaudov <GnuPG KeyID: DE1716B0>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.