Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [udig-devel] A need for branching uDig and Geotools, and how to merge again 
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 admin@xxxxxxxxxxxxxxx <mailto:admin@xxxxxxxxxxxxxxx> 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 admin@xxxxxxxxxxxxxxx - 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

Back to the top