Wellmann, Harald wrote: > Thanks for your feedback - I'm glad to hear that we share a view on > the libs bundle and the need to do something about it. Not to worry; I am in the process of shifting jobs so am not really around much this week. > > 2) Working branches will be created in the uDig and Geotools > repositories for my team and myself to do the required > modifications, merging changes from the trunk as often as > possible. If and when our branches have stabilized and the > communities have verified that the results are useful and > correct, the working branches can be merged into the trunk and > die. > > > We would like to meet the members of your team; do they have > commit access at this time etc? > The larger isssue here is that it is kinder for the open source projects (mostly geotools in this case) to be around as you develope the plan - so their is less information to digest all in one go. That said your email was well written and covered pretty much everything - we just have some logistics and timing to work out. > > There's three of us in my team, and so far I'm the only one > working with uDig. When I've tidied up what I've done so far on > our own plugin and when we've found a way of managing all the > repository access and branching issues, I'm planning to let > someone else take over, but probably not before the new year, > seeing that our uDig plugin is just a small subproject of our > regular work and not a top priority one... > Okay that timing gives us something to work with; I would of course like to move more quickly than that. If your team wanted to work on a branch (which seems your suggestion) there are some requirements (reading the developers guide, sending an email etc...) before a geotools PMC member can recommend commit access. This is something that each team member would need to do - we work on trust of individuals around here.
To actually merge the changes into trunk we need make sure your plan is written up as a proposal for the PMC to vote on. Due to the scope we may have to be very clear with the proposal; and revise based on feedback. We should try and plan the work (ie merge) for a time block when others do not have deliveries etc... > > So far, I don't have commit access for uDig, and it would be > helpful if you can set up an account for me, to get a chance of > pushing some trunk-compatible changes back - if you prefer a pull > model, that's fine with me also. > For udig we review a couple patches; make sure you are using the code formatter etc... Any memeber of the udig PSC can do that for you. After that you are in the code base; and we trust (and help clean up as needed). Submitting patches and going through the code review process is a great step to get out of the way now. > > Considering Adrian's feedback from the Geotools perspective and > the fact that they have started using Mercurial anyway, I really > think it would be the best thing for us to work on Mercurial > clones both of uDig and Geotools, until we've reached a > stabilized subset of uDig and Geotools without our dear friend > net.refractions.udig.libs. Until that point, it wouldn't really > make sense to merge any changes back into the uDig repository, > unless you would like to mirror our Mercurial work on a Subversion > branch. > I am thinking of the most likely people for you to interact with on this end (probably Jesse and Myself). It may be easier for us to merge in a branch - I for one have not had a chance to try out Mercurial at this time. > > What about uDig wiki access and editing policies? > Sigh up and start editing. Let me know if you have any permission problems. > > I think it would be useful if I could document our plan and our > progress there. Even if the software changes happen on a > repository clone, at least the documentation should be kept in one > place. > That sounds fine; the HACK space is devoted to just this kind of planning and progress activities. > > We may be able to set up HTTPS for this stuff (we would need to > talk to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> for > details). > > That would definitely make things easier. On the other hand, if > we do work with Mercurial, then it's not that urgent - I could > pull the changes from Subversion to Mercurial at home and push > them to the team repository at work. One of the nice features of > DVCS :-) On the other hand, I think it would be rather hard to > push anything from Mercurial back into Subversion. > Can you send an email to [EMAIL PROTECTED] - I am away from good internet for a bit. > > Then the Geotools libraries will be osgified as outlined in > > http://docs.codehaus.org/display/GEOTDOC/03+GeoTools+and+Eclipse+or+OSGi, > without breaking the META-INF/services mechanism and without > losing the capability of being used as plain old JARs on the > classpath. > > > This is the part that is of interest to me; you may wish to show > up for a geotools IRC meeting and talk to the community about it. > > Sure why not - when is the next one? If it's during office hours > (GMT+1), I'll probably unable to access IRC, again thanks to our > firewall and web proxy. I'd have to find an IRC-over-HTTP service > and hope that the HTTP server is not on the blacklist of our proxy... > If needed you could also try and round up people for a breakout session over skype chat or something. I am just trying to make sure the development community understands what you are about; and has a chance to ask questions. Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
