[jbosstools-dev] Re: We have branched - Codefreeze and status

[Max Rydahl Andersen]

> Couldn't you just use the "CR" branch for that? (By another name,
> preferably.)  I don't really understand what changes would go into trunk
> but not into the branch.  If the answer is "no changes", then the branch
> is redundant at present, is it not?  Or are you saying there are issues
> which we intend to fix (in trunk) for GA, but not for the the CR?
>    
Yes - https://jira.jboss.org/jira/browse/JBIDE, GA currently have 46+ 
issues for it. Those need to
get reduced though ;)

The branch is not redundant - it is there to give build and QA engineers 
a chance to do builds safely
and to allow progress on GA to continue.
>> Safe string externalisation I'm ok with, I assume you did you *big*
>> change a few weeks back, correct ?
>>      
>
> So far, excluding the "i18n" folder, everything I've done has been
> simple string externalisation, nothing *big*.  Just lots of small
> changes.  Looking at the changesets, I haven't checked in any .java changes.
>
> Even so, it may not be 100% safe, since I had to do most of it by hand
> (no wizards for some things).  As much as possible, I have tried to
> smoke-test them in the GUI, but it's difficult to test every string when
> you don't know the GUI inside out.
>
> Most of the remaining externalisation will be the easier, wizard-driven
> type, except where I have to introduce MessageFormat.  However, once I
> start externalising entire plugins, rather than targeting individual
> strings from the GUI, comprehensive testing will become much more
> labour-intensive.
>    
hmm - I might want to hold back on that till after GA then.
Could you give a status per module/plugin on what you have 
covered/not-covered ?


>> And yes, I'm saying don't make big functional changes or additions in
>> trunk - make bugfixes.
>>      
>
> Is 18n a feature, or are unexternalised strings bugs? :-)
>    
unexternalised strings are bugs, doing l8n in another language than 
english is a feature ;)

/max

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090127/983d6f62/attachment.html