On Thu, Feb 14, 2013 at 12:21 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> Philip indicated yesterday on IRC that all local move features
> he wanted to get to implemented for 1.8 now have code written.
> So now we're all waiting for the "local moves" yellow light on
> roadmap.html to turn green.
That is good to hear. I saw Ben committed some tests as well. I did
see him declare victory anywhere though, so I am assuming he still
plans to add more?
> I think we're at the point where we need testing by real users.
> We've got some test coverage in our test suite that indicates things
> are all well. But the test suite is somewhat removed from the actual use
> cases which local moves are supposed to improve. For instance, we
> haven't yet seen a single off the mill Java developer hit the 'refactor'
> button in an IDE and then update the working copy.
>
> I expect that there are bugs lurking in the implementation of local
> moves, and I also expect that we can still improve the user interface
> a bit. But to get there we need some feedback from the outside world
> about what does and what doesn't work.
>
> I think now is the time where we should either start cutting 1.8 alpha
> releases from trunk, or branch 1.8 and then start issuing alpha releases
> from the branch. In either case we should ask the community to build
> binaries and ask our user base to help test them. (I don't expect alpha
> builds to be used in IDEs, however many users could try to update
> refactored working copies with the command line client and report back.
> This would also be a good test for the 'svn upgrade' code.)
>
> What do you all think?
I am not a huge fan of alphas in general just because I do not think
many people really try them and in a disconnected communications
environment like we are in, it can lead to a lot of time wasted
waiting on feedback that never comes. That is not to say that I do
not think we should cut one or two. If we get some early feedback
that would be great. Mainly, I would just be concerned that we take
our foot off the gas while we wait for people to tell us it works or
does not work.
I think one possible advantage to staying on trunk a bit longer,
besides the simpler process, is that maybe it will keep people from
holding off on work for post-1.8 a little longer. I would be a little
concerned if we branched right now that some work on new 1.9 features
might start landing on trunk before we even get 1.8 released and this
might just complicate the backport process. Obviously it would be
even worse if some of that stuff happened BEFORE we branch, but I
think branching is kind of a signal that trunk is open for next
release stuff.
Anyway, it is great to see the progress. I am not against either
option, just throwing some more ideas out there for consideration.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-02-14 18:50:34 CET