Hi Joep,
2011/8/14 Joep Suijs <[email protected]> > > > 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? > Should we run some kind of sanboxes in SVN ? (if yes, not in the trunk, not to wake buildbot, and most importantly, to keep code separated from jallib's) > > > - 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? > I'm not against your way to handle this, nor am I on the extreme, I'm just throwing some arguments from the devil's advocate :) > Grant everybody the option to change any library and discuss the > changes afterwards? > Shared authorship ? > 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). > Yes, I agree, it's not wise to allow anyone to make any changes he likes, nor it is wise to object any changes as well. There's a treshold here, that's why it's hard to get a consensus. And that's why I'm throwing rough arguments on the table from the extremes (though I don't mind them), because none of the extreme should be allowed. > 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. > Sure. I've already put a lot in this kind of discussion, I may stay quiet and see what happen :) cheers, Seb -- 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.
