On Fri, 2004-10-01 at 12:50 +0200, Matias Feliciano wrote: > Le ven 01/10/2004 Ã 11:36, Paul Nasrat a Ãcrit : > > On Fri, 2004-10-01 at 11:13 +0200, Matias Feliciano wrote: > > > Le ven 01/10/2004 Ã 09:50, Bastien Nocera a Ãcrit : > > That discussion should happen on this list and you'll need to > > work with the maintainer. > > Honestly : No. > See many complains in fedora-test-list about the sound. Then I take some Maintainers aren't guaranteed to be on all lists. In some cases package maintainers may not be full time developers. This is the right forum for config tools as clearly shown here: http://fedora.redhat.com/projects/config-tools/ It's very easy to get caught up in history, particularly across lists. Can I suggest we start over. Maybe if I get time I'll write a system-config contribution FAQ/HOWTO for the docs project... Also before I start, I am NOT intending to criticise you here, merely to try and get people working together. Ultimately your interests/needs may be wildly different and you may want to continue on your own path, that is one of the freedoms of the license. > time to fix audio (not only s-c-sc, see this for example : > http://www.redhat.com/archives/fedora-test-list/2004-September/msg01233.html ) for the "fun" and to contribute as I can. > s-c-sc is not critical to me and now I don't like why all this is going > on. I was initially going to say that I don't have time right now to look at the specifics for this case. However, my concern is that volatile emotions are getting in the way, so I'll spend a little time now, hopefully to try and seed a better working relationship. Just initially glancing at the archive, I'm finding that mail very hard to process, it covers a lot of things and I find it quite hard to read. I personally prefer single issues covered, clearly indicated by subject, with patches attached rather than inlined. Same goes with filing it in bugzilla. If a mail is hard to read I may skip although, so if you are covering multiple things I may have stopped reading. Small chunks mitigates against that risk. I'm going to summarise that mail a little here - feel free to clarify any mistakes I make. My comments are my own and should not be taken as an official redhat statement about s-c-soundcard. I'd welcome it if Bastien could fill out details here as necessary. Also note I'm trying to put some effort into this as I appreciate external contributions to our config tools, and I want to get the balance/process right. Issues with initscripts, alsa and udev interoperability: * "alsactl restore" is done _before_ udev creates device nodes in /dev/snd/. udev is executed _after_ modprobe. The above is a bug in initscripts - it should be reported in bugzilla. Unrelated to us here - so let's ignore that for this discussion. s-c-soundcard use of /etc/asound.conf * You say that asound.conf is for the end-user. Note that the config tools are provided to do configuration, so setting it up is well within the remit for s-c-soundcard. * You make some statements about the use of asound.conf by s-c-soundcard and link to a bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133535 Again this is a problem related to udev, etc. It doesn't seem to flow from your discussion of asound.conf. I appreciate you are trying to tackle the issues head on and have put suggested udev patches in bugzilla. Would you agree the majority of that post you link to is not specifically related to system-config-soundcard, and hopefully you can see that it might be hard to distill > At the begin this is what I want to achieve. But with backward > compatibility in mind (how to test since I only have FC3T2 ?), split in > independents patch ... This is too hard, it will take too much time for > a ~500 lines program. Bear in mind that I'm not looking specifically at your patches right now, and am not sure how you are developing (eg local revision control). patchutils can help with diff management - if you haven't used them I really suggest you play with them. If you don't have time to break it down, but have an explanation of everything you are doing - you may be able to get someone to triage it down and pass it up to Bastien. I can't do this right now, but can you post a NEW post to the list with just a link to your patch set to fedora-patches-list and join #fedora-bugweek on irc.freenode.net to poke people to triage your patches. I'm trying to explain the best process to work with the project. There may be variations, but as: * we are in freeze - http://fedora.redhat.com/participate/schedule/ various things may slip. One think I'm thinking of - which other config maintainers may have opinions on is moving development in freeze to a branch so things can still proceed. We have to keep HEAD available for translations, so non bugfixes can't go on HEAD during that process. > Is not about "hostile". It's about to take care a minimum attention to > contribution. One could also say it's about taking care to pay minimum attention *how* to contribute. One of the things I'm trying to explain is *why* we like to have split patches broken down by bug or individual feature. > Bastion is not hostile. He don't want to spend time with me. Why ? I > don't know and don't want to know now. You have to realise that time is limited - and by asking to split things up and do iterative development rather than big monolithic patches/forks is to try and foster a maintainable and workable process. > He don't read the url I place here (fedora-config-list). Don't read > rc.sysinit whereas I state in many place that modules are not loaded on > demand with udev, .... See above for a discussion of your mail. I reiterate, that I personally found it hard to read. I appreciate that English is not your first language but by smaller directed chunks and slightly different formatting the mail probably would have been easier to digest. > I take the time to read his code, understand what goes wrong, patch, > test, fix any useful reply (avoid loading module, firstboot), lean > python (never use python before!), post some messages here, ... No-one is trying to belittle what you have done. Just how we find it easiest to work > What he does ? Asking you to break down your request into manageable chunks. > For the record, I never asked my patch in FC3 (first post about my > patch) : > Since my version is not close to Fedora, I doubt Fedora want to make it > upstream. > > Here "upstream" mean FC3 in my mind at that time :-) > s-c-sc is a very small programme (less than 500 lines in my version) > it's not the kernel :-). Switching from one branch to another is no a > big deal or risky. True, but if want to improve the program then sure you can fork, but that seems excessive. Hence maybe saying, well I think the feature FOO I added or the bugfix BAR I fixed would be best pushed upstream and pushing those. > btw, who set the maintainer of s-c-sc ? The community ? No. So you can't > compare s-c-sc and Linux on how the project is managed. Sure, it's a slightly different situation. I'm just trying to explain how best to work with the config project. > I will fill some bug reports. Thank you, when you are done why not post a mail summarising the bug numbers here. Paul -- Fedora-config-list mailing list Fedora-config-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-config-list