Hi Joep, guys, Indeed author can object against any changes. Considering this, what is the purpose of running a community project ? I could argue that: - people would just dump their code onto the SVN repository, as a "don't touch this" piece of work. Why putting this in jallib ? A private, personal SVN would be better. - and if a change requires the library to be updated (typically a change within device files), and if author object any changes on his lib, how do we handle this change ? We could be stuck...
I understand how critical some code can be, and how reluctant one could be when some precious production code is running well, after weeks of testing. Clearly, I understand. But, again, that shouldn't be an obstacle to changes (I'm not talking about this case, previous case, or whatever, but in general). And, again, SVN is here to help, by keeping the exact code version that was used to procude the precious production code. Anyone can move back to past revisions in order to find their lib. Cheers, Seb 2011/8/14 Joep Suijs <[email protected]> > Hi Matt, > > > 2011/8/14 mattschinkel <[email protected]>: > > We need a proper, agreeable way to upgrade libraries. > I fully agree - this is why I posted my message. > > > In the case of this library, it is to comply with current SPI standards. > ... > > There are good reasons to update a library: > > 1. Most people agree on the change. > > 2. Comply with a standard. > > 2 is just a shift of the issue, since we'll have to debate the > applicable standards and the libraries they apply to. You demonstrate > this nicely with the remark about SPI standards ;) > > 1 is a call for democracy, but I doubt this is the best way. Many will > be indifferent about a particular change and quite a few conservative. > Also, people might attibute different values to specific aspects. I > use many older 16F pics, so memory efficiency is more important for me > than someone using large chips. Imagine the significance to someone > having an installed base of hundereds of controllers... > Anyway - the two with the strongest opionion will probably be the one > who want to put effort into the change and the creator (who probably > use the library often). > > But most importantly, you ignores any rights the original author has > over the code contributed. Many of us write libraries we use ourselves > in many projects. We comply to the jallib standards and share the code > with the community. In return, you don't have to execute your own > version and distribution control over the files and others help in > finding (and sometimes even fixing) bugs. If at any day someone might > change the libraries in which they require extra effort (or worse), > this might not be such a good deal... > > So if you want to put it in rules: > > 1. libraries won't be changed when the original author objects. > 2. libraries won't be significantly changed (different behaviour, > structure, algorithm,memory/cpu use) without previous aquired > permission from the original author. > 3. if there is no permission and there is still a requirement, a new > library (different name) can be created. (this could be a good way to > prove the new lib is better and get permission later on). > 4. the benevolent dictator can decide to ignore the rules above and > have a lib replaced or - when there is a good, proven alternative > available for some time - have it marked obsolete. > > Joep > > -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
