>> It seems then that you can not get the kind of information you might be looking for >> at the moment from me (alone). > > No, the patch itself speaks. Are we still trying to clarify (only) two possible update steps for this software module? > If you get more reviewed-by from others, it means already it's safer > to apply. Then I can take it. How are the statistics for such tags in the sound subsystem? > But without that, it's obviously no material to take. Thanks for such an explanation of your current view. >> I hope that mailing list readers could offer something. > > Let's hope. Are any additional communication interfaces helpful? >> Did this software module become “too old”? > > Mostly the hardware is too old, Which time frames have you got in mind for acceptable software maintenance? > or the change itself isn't interesting enough. This is another general possibility. >> Can higher level transformation patterns become easier to accept >> by any other means? > > Only if it's assured to work and not to break anything else. Have you got any steps in mind for an improved “feeling” or “assurance”? >> How much does the omission of such an useful development tool >> influence your concerns? > > Can't judge unless I really see / use it. I find that there are some options to consider. >> Would you like to improve the software situation in any ways there? > > I *hope*, but only when it's not too annoying. Under which circumstances are you going to start working with a continuous integration system? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
