Re: audacity-nonfree, normalize: ? maintainership ?
Michael Schwendt wrote:
On Tue, 12 Aug 2008 19:31:47 +1000, David Timms wrote:
> Michael / All,
>
> With regard to audacity-nonfree and normalize, I don't wish to step on
> anyones toes. You are definitely welcome to assume primary ownership of
> both of them if that is your intent. I sure the person who has spent a
> lot of time understanding the software, tracking bugs, etc is going to
> have a much easier and more effective task to maintain them.
>
> Can you let me know ?
Well, Audacity is also in Fedora. It has been sort of upstream for the
Livna package. Except that the Livna package ships two releases in one pkg
to escape from stagnation. It's unclear how long that will be necessary.
Theoretically, the pkg could return to be slightly modified Fedora pkg.
More comaintainers (also testers!) for the Fedora pkg would be
helpful.
I'll request watchcommits, comaintain in fedora. I use it a bit, and
have been trying more recently to record from two sound cards
simultaneously, so when I saw that lack of maintainer for rpmfusion
thought I would put up my hand. Only had a short look at the code a few
years back to consider it as a basis for something I was tinkering with.
My first impression of the -nonfreee package was that it had just the
non-fedora allowed bits, but I see it conflicts/replaced f version.
Seems to be a package that can't dynamically open the 'non-free' bits if
they are present ?
So
far we are two who usually try to agree on whether to upgrade to just
another beta release which [once again] bears the risk of breaking
features in many ways (such as would have been the case with the previous
two beta releases). If Fedora still offered only the more than two years
old stable 1.2.x release, that would be different from other popular
distributions. Users would not understand that. On the contrary, if recent
1.3.x-beta releases are offered, some of the Fedora users with real
interest in Audacity still go and build their own binaries instead of
testing the Fedora rpms.
With Fedora we have a update-testing repo. This might be against policy
for Fedora: Could we build always the latest version and expect to have
it there long term, until a new Beta release or enough feedback says the
package is 'good' or at least better than the last updates package.
I don't remember seeing any similar -testing repo for livna, rpmfusion
{other than devel, which I expect is for use with fedora-rawhide}, have
I missed that ?
Is there a different level of QA here, where the package doesn't get
released at all unless we are really sure it's good to go ?
And "normalize", it's a simple package. It could be
passed on to
any beginner packager with a bit of interest in a review and the
software. Interest in old XMMS could be beneficial.
I'm fairly beginner'ish
myself {just glglobe in fedora, but working on
others}. But perhaps it would be worthwhile leaving it to be an easy way
in for new packagers ?
DaveT.