On Fri, 2005-07-01 at 08:33 +0100, Ross Gardler wrote: > Tim Williams wrote: > >>Now to the road-map I see for views and the lm-branch: > >>1) Fix all issues with the lm in the lm-branch (there are just minor > >>ones that I am aware of) > >>2) merge all lm related stuff with trunk (branch->trunk) > >>3) merge all view changes into whiteboard trunk (branch->trunk) That > >>step is and should be independent from step 2, it is only after this > >>step because we now have 1 contract that is based on the lm stuff. > >>4) *Stop* and freeze developing the view plugins in trunk!!! > >>5) Open view-branch and start to integrate views into the core > > > > > > I think the only issue with the locationmap branch that I can find is > > FOR-554. With the suggested workaround that I describe below, I think > > we can take that off the list for now and allow the branch to go ahead > > and be merged.
... > > The actual merge is going to be complex though. Why? I will happily merge the stuff. Actually not too much have changed. > When the views were > brought over there was a partial merge of the tree so there and now it > appears that people don't want it to go back into trunk. > Stop. >>2) merge all lm related stuff with trunk (branch->trunk) > >>3) merge all view changes into whiteboard trunk (branch->trunk) It is like this because your are right I merged the whiteboard plugins from trunk to locationmap_branch. That means this plugins need to be treated different from the rest. IMO we need to split the merge into view-merge and rest-merge. That's it. ...and thinking about it, it should be reverted (3 then 2) because then we can merge the rest completely. > I don't want to tackle this until I have a good couple of hours to focus > on it. I doubt that will be until the tail end of next week. > I will prepare a vote. > > 2) I've come to understand that we need a more robust location > > resolution error handling capability (as described in another post > > that apparently wasn't well received). It basically said that we > > should ultimately be reporting in error messages all locations that > > were searched for a resource rather than whatever happens to be in the > > "otherwise" clause. > the "only" thing we need to do is write a sitemap matcher listener to store all tried locations in a bean and the parse it in the stacktrace. ...makes sense? > What do you mean "apparently wasn't well received"? I don't recall any > objections. In our community that means people are either neutral or > like the idea, it means thay have nothing else to add. I'm not sure how > you will do some of the more advanced stuff (like say we checked here, > here and there, at least not without hard coding that info) but I agree > we can do at least improve on what we already have. > > > This, of course, also assumes that everyone agreed that for now we > > should revert the fresh-site dependency on views until they're ready > > to come out of whiteboard. > > Yes, Thorsten says he wants views to go into their own branch. > Yeah, after the merge with the trunk. > > Anyway, as I said, I don't mean to come across pushy on this > > locationmap branch but I think it's ready to merge and shouldn't grow > > moldy. > Yeah, thanks for the headsup. ;-) Was not at all pushy. > You are doing the right thing. Right now there are only the two of us > active on Locationmaps I'm busy with other things for a short while and > so you are left on your own to keep things moving. This is not at all > pushy, but *exactly* what we, as a community want, If we don;t like your > proposal we can always say no. > Actually I am playing with the travesable generator, but have not check in anything yet. I hope to add an example how I understood nicola on the weekend (per dir view feature). He can then correct/enhance/clarify it ;-) > Ross -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
