> > > > Should we: > > 1. just say "ha ha - fooled you" for the people doing rendering > (and > > other modules) on 2.1.x. This pretty much means we're calling > 2.1.x a > > fork. > 2.1 is a branch. The moment work not related to bug fixes (is > optimization a bug fix?) started it became a fork. I have said all > along that I have been very very uncompfortable with the level of > development work happening on 2.1.x but the people doing that work > assured me they were happy to keep 2.1 and 2.2 synch. These same > people now seem to be very un-happy keeping that level of effort up. > I can recall no commitment from 2.2 developers to make life easy for > 2.1 developers other than ensuring that code written against 2.1 > would > work on 2.2. (I can well imagine that this is not holding true and > if > so needs to be addresed urgently) Yes, I agree, I too have been scared by the amount of work that's not just bug fixes going on in 2.1.x. I don't even think that optimizations should really be considered bug fixes. I've been advocating for awhile for trunk being stable, and using branches for anything that's unstable. We've been doing this more, but the second thing we need to do is actually release the trunk more. We should be making much more rapid releases, so that gaping changes don't develop between the stable branch and the trunk. Trunk being stable does not actually work if no one actually uses it as if it's stable. I sort of feel we should just put a 2.2 out now. Then when complex merges in, put 2.3 out. Then when coverage comes in, 2.4. Even changes that are smaller than those.
> > PS. And *please* don't auto-format code anymore! > I have to agree with that, idealy we should all follow the > conventions and use jalopy before commiting code. BUT if that does > not happen DO NOT go refomating other peoples code, there is little > more anoying that tracking down changes when there are none. (Though > diffing with ignore white space switched on can be a life saver!) I actually think it's more than valid to auto-format code if you do it completely in it's own commit. With this you can get all the code diffs, no problem. The only time it sucks is when someone formats in the same commit as a code change. If you don't want your code auto-formatted, then commit it with the proper formatting in the first place. If people can just commit code in any format and it won't get changed, then why even have the standard in the first place? Though I think we originally left the details of this question up to the module maintainers. They can choose the specifics of how much to enforce code formatting on their particular module. Within the general guideline that geotools has a specific format that we want everyone to follow. It's just up to them to implement how that happens. Chris > > James > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
