On Mon, Jul 26, 2010 at 1:47 AM, Takashi Iwai <tiwai(a)suse.de> wrote:
Great. I'd love to merge it to the upstream tree
after code review.
Could you simply post your patch(es) to alsa-devel ML (and Cc to
maintainers)? Then we can check your changes.
Takashi -- I am glad to hear of your interest and thankful for your
consideration. It appears that some of the code-review and testing is
already happening in linux-audio-dev (
http://linuxaudio.org/mailarchive/lad/2010/7/25/172231 ) so I will
submit a more final patch to alsa-devel, once some issues found in
testing&usability get resolved.
At best, please give incremental patches containing
the proper
changelog and your sign-off in the patch comments to be applicable via
git-am.
Now that I understand the correct way to submit ALSA patches, I will
follow instructions from
http://www.alsa-project.org/main/index.php/GIT_Server#Occasional_Developers
for my final ALSA submission.
Also, avoid to change version numbers. If you take
over the whole
project, then yes, it's fine to change the major version number as you
like. But, as long as the upstream is alive, this may bring much more
confusion than needed.
In my defense of being presumptuous to change the version number,
please note that the submitted patch didn't include the autoconf
change that sets the new version number (
http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch ).
The "1.0.0" is in 'configure' for the source distribution (
http://nielsmayer.com/envy24control/envy24control-1.0.tar.gz ) to help
distinguish it from the standard version....
To avoid confusion for the next 1.0.1 release, I'll do something
similar, but I'll change 'configure' in the source distribution to
build "mudita24 1.0.1" rather than "envy24control 1.0.1", using the
same sources. And release as "mudita24-1.0.1" ... Then I'll submit the
final sourcecode to alsa-devel as [PATCH] results, minus the
config/naming changes. I hope this is an acceptable solution.
Thanks,
Niels
http://nielsmayer.com