Howdy, A few things in order to tie up this issue, since people are obviously getting a bit upset about it.
Firstly, we operate a meritocracy here. This is your first patch to CVS, and in order to have a patch to CVS accepted, you need to get approval from one member of the community who currently has CVS access. This is the way it works; there is currently no other way that I can see to ensure that the quality of the code base is maintained, given that we currently do not have a technical architect who is responsible for approving or rejecting patches. Secondly, your patch needs attention in the following areas; - Don't create a patch file that contains changes to whitespace. There should be a switch to cvs diff that allows you to ensure that whitespace is not included. This will make your patch legible, and will mean that people who currently have CVS access will get beyond reading the first two lines. - If you are duplicating existing functionality in some way to make things "better", then people will not feel comfortable replacing some stuff that's already there and thought to be working (more or less). You need to create your patch file in such a fashion that it can be switched on or off to use the "existing" code, and not yours. Again, people may be more willing to accept your patch. In other words, don't patch smsc_at.c; create a new file (smsc_at2.c or something similar) that can be used instead, and create a new smsc definition for the configuration file so that people can experiment more readily. - Finally, before you even started on this effort, I communicated to you that it was inadvisable to use a scheme which relied on SIM storage, as people probably wouldn't like it, and that I was personally concerned about the potential portability problems to other handsets and GSM modems. You proceeded regardless, which is your right, but you shouldn't be all that surprised given my fairly explicit warnings. Finally, open-source software involves a lot of duplication of effort - that is one of the unfortunate weaknesses of this model of software development. There is no way of knowing whether or not your change will be accepted until you've made your change. Other people may make an acceptable change faster than you, or in a slightly better or more palatable way. All of us have had the experience of writing something and then not having it accepted by the community, and while none of us particularly like the feeling of not having our changes applied, it's something we accept before we commence on our efforts. That said, if you still think your stuff belongs in CVS, tidy up the patch as I indicated earlier and the current CVS committers will have another look at it (or a first look at it, given it's current state). > Ask them ! They say they're busy. I don't quite understand myself. It takes > approximately 1 minute to patch the CVS. Yes, but it takes days to make sure that what we're putting in is of sufficiently high quality to ensure that the code base is maintained at an acceptable level. Particularly if the patch is difficult to read. > I am actually really pissed off about this 'cause it takes me close to an > hour to create a new patch for the latest CVS. It shouldn't, if you follow my advice above, and keep your smsc_at changes reasonably separate from the existing code base. That way you won't have to keep adjusting your patch to accommadate the changes that others make. See ya, Nick -- Nick Clarey, System Architect | "Sometimes when you fill a vacuum, 3G LAB | it still sucks." - Rob Pike p +44-1223-478900 fx +44-1223-478901 |
