cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: CForms and Dojo
Date Thu, 21 Aug 2008 12:36:48 GMT
Hi Jeremy,

>> Jeremy, I was thinking about this branch yesterday and I think you 
>> should branch whole 2.1 and commit your work to your branch.
> 
> With your help, I'd be happy to do this.

I've created a branch called "BRANCH_2_1_X-dojo1_1" based on latest version of 2.1 branch.
It's your 
sandbox now and you can safely play around there without any risk of buildings someone's work
or 
block any releases.

The URL for branch is:
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/

> 
> Lets do it !!
> I am getting really close to having all widgets re-written to Dojo 1.1.1 
> APIs, still not quite there yet.
> 
> But as it looks like I have some work coming up that will delay me 
> further, this could be a good time to get it out.

Actually, now it's very easy, just switch your checkout of Cocoon's source code to the branch
and 
commit your stuff there.

Don't know which client for svn you are using, but from cmd line it would be:
svn switch https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/

(https is important here, of course)

I only have one ask to you:
Could you try to commit as small changesets as possible (of course, not to small)? The best

situation would be if one commit reflects one logical change (like migration of one widget
to new 
API or something like that). Rule would be that one commit is big enough to not introduce

intermediate states where state of branch is completely broken. So half-baked commits are
bad idea.

On the other hand, single commit should not contain anything more than is necessary to fulfill

requirement outlined above.

I ask you to split your work into smaller chunks because then it's easier to merge things
in the 
future and it's much easier to follow your work and port it to trunk. However, I'm aware that
when 
one is doing heavy refactorings following this rules is not always possible.

Last thing: descriptive commit messages. Even if that may sound obvious, but they are really,
really 
needed. ;-)
This is especially a case when someone else must keep trunk in sync with your work.

> Apart from my dwindling list or re-writes, there will obviously be a big 
> list of niggles and bugs to fix, specially as none of this is tested on 
> MSIE.

Here I hope that we can count on help of our community.

> Cleaning up samples
> Devising a good scheme for packaging code and i18n
> Waiting for a slew of bug fixes that will come in Dojo 1.2
> Implementing client-side validation based on cforms validators, not just 
> datatypes (as I have now)

Is the last item absolutely necessary for initial release?

> etc. etc.
> 
> There is still a lot to do, but once these last few widgets are written 
> and all legacy samples work again, people will be able to run and use 
> it, criticise, tweak, fix, meaning the slope should be downhill :)

:)

>> Robin, back to your question: I hope that once Jeremy publishes his 
>> work we can all join our forces to push things forward. When it comes 
>> to me, I can help with porting Jeremy's work from 2.1 to trunk.
> 
> That would be great!!

Even there is one caveat: for me September is going to be more or less free month and I plan
to not 
touch computer too much so I could start with porting stuff to trunk in October.

Now, looking forward to your commits!

-- 
Best regards,
Grzegorz Kossakowski

Mime
View raw message