Hi Seb et al, 2011/8/14 Sebastien Lelong <[email protected]>: > Hi Joep, guys, > Indeed author can object against any changes. Considering this, what is the > purpose of running a community project ? That's the other extreme. That's why we have rule 4 ;)
> 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. To have the functions available for the community? > - 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... It is quite unlikely an author objects to changes required to stay compatible with jallib, to fix bugs, minor improvements and extensions. The discussions so far have been about changes that result in significant different code. > 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. What I suggested was a way to deal with this recurring issue. You argue against it, but I don't understand how you suggest to handle this. Leave it as is and have this discussion about each occurrence? Grant everybody the option to change any library and discuss the changes afterwards? The point is SMART criteria are difficult, since (absence of) reliability can only be determined afterwards, resource use vs functionality is highly dependent on the nature of ones project and the value of specific arguments is often personal preference too. I can only imagine the one with the most arguments, most messages or longest messages wins ;) Well, except for the majority vote like Matt suggested of course... Like you, I see the interest of the community. But I don't think it is wise to allow anyone to make any change he likes (as opposed to the author to object to any change). But most importantly, I hope we can agree on some general rules (guidelines) how to deal with this kind of situations and avoid these long discussions in the future. 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.
