[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] *Important* Eclipse version question; partial IRC transcript
|
At 10:01 PM 7/21/2003, Mark C. Chu-Carroll wrote:
Folks:
I'm currently working on finishing the non-CLI-based Stellation
client plugin. I've been looking at what's going on in the R3 stream,
and I need to decide whether to target R2 or R3.
<snip>
The question that I'm putting forward is this: is it worth jumping over
to the R3 stuff, even though that will make it harder for some users
until R3 stabilizes? Or should we stick with R2, which gives us the
larger user base, even though some things will have to be omitted for
now, or rewritten when R3 comes out?
If you want to chat about it, I'll be on IRC at Freenode.net #stellation
starting about 9:30 tomorrow morning. If you want to discuss on-list,
please post as soon as you can. I'd like to get a decision on this
quickly. (We've got some demos coming up, and we need to finish some
of this for it, so time is of the essence.)
Mark and I discussed this for a while yesterday on IRC, and my thinking
changed as a result. Here are some transcript excerpts.
<JimW> Briefly, I think we should target R2 for the first non-CLI-based
Stellation client that's solid, while following R3. Reasons to follow --
1. R3 release is "sometime 4Q03". That's probably November/December
(eclipse.org has a good track record of staying pretty much on schedule).
2. We want feedback from people using Stellation. There will be a lot more
potential users (in 2003) using R2 for development.
3. R3 is likely to be pretty bumpy. We will have enough to do getting
Stellation SCM, Chat, Task management working with the current R2 codebase
(which is likely to stay a lot more stable). Tracking R2 in the 6 months
up to its release caused a fair bit of extra work for me.
After the first solid SCM/Task/Chat client is released, we should start
tracking R3 aggressively. And before that, we should still follow R3 to a)
align the Stellation client design with the emerging R3 design, conventions
as much as makes sense; b) avoid reinventing stuff that will be in R3; c)
maybe influence R3 development, feature set.
To recap: watch R3, build and release for R2, get feedback from R2 users,
and target our followup for R3. Thoughts?
<MarkCC> I agree with all the reasons for tracking R3. I'm just still not
sure about spending the time on R2. I think task/chat is largely an
independent issue. The stuff that we use for task/chat is [jw: mostly]
independent of Eclipse version. The backend SCM stuff is where it's somewhat
different.
So we're really just talking about where to target the real pure SCM
operations. And most of the non-trivial outstanding issues in the pure SCM
support are things like the merge/synch views, which are dramatically
different in R3. So, for instance, I don't think it's a good idea to spend
a lot of time building on the non-API synch/merge code in R2. But an SCM
plugin without some kind of serious merge support is crippled. So I'm just
not sure if it's worth the amount of effort required to provide a real
client for R2, when R3 is six months away, and most of the expected early
adopters of Stellation are the type who'd switch over anyway.
<JimW> If we target R3 for the "pure SCM" stuff, we're basically deciding to
defer the release until R3 ships.
<MarkCC> No - we're saying that we're releasing for the R3 milestone builds.
The eclipse folks have been quite good about making sure that when they
label a milestone "stable", it's stable.
<JimW> That means we won't get any significant user input until January 04,
because I don't think we'll get many users willing to do development on R3
pre-release builds.
<MarkCC> I'm not sure about that. I don't know. That's why I'm hoping for
some more input. I had a *very* hard time downloading M2 after it was
announced, because Eclipse.org was absolutely hammered by downloaders.
...<snip>..
<JimW> There's another way to go: design the Stellation core to source
content in a manner that's compatible with R3, and then see how much work it
is to make adapters for the R2 sync/merge viewer. We make it work first
with R3 (where it sounds easier, admittedly) and then back-fit to R2 if it's
a) do-able and b) still worthwhile.
<MarkCC> I think that's probably the best path. But I'd still like to give
anyone interested in commenting an opportunity before we make a decision.
<JimW> Oh, absolutely. Like the little guy in Short Circut: Input! We need
Input! Aside from the sync/merge viewer issue -- do you see any other
significant issues w.r.t. finishing the Stellation non-CLI client?
<MarkCC> No. Seems mostly straightforward.
<JimW> So, except for sync/merge, supporting R2 is a no-brainer
<MarkCC> Yes.
...<snip>..
<MarkCC> The synch view in R3 has been completely rewritten. The new merge
is a part of that, and has adaptor classes to make it easy to supply merge
inputs. But in plain 2.1, the merge view wasn't so easy to provide inputs
to; it was more hardwired into the synch view, which in turn was hardwired
to CVS.
<MarkCC> [For R2], we can do a moderately broken version of merge (i.e., one
that does the job in an ugly, but functional and not-too-painful way) pretty
easily. But it won't use the Eclipse synch view. The ugly-but-functional is
basically marking conflicts b putting a comment with a "TODO" type marker in
front of the users code, and the alternative version from the repos in a
following comment. So, the conflicts will show up on the task list, but
they won't cause compilation errors.
<JimW> If we do the ugly-but-functional R2 (and my working notion of this
was much like yours), we can put the R2 sync/merge viewer work out there for
someone else to do if they're interested. [And if nobody picks it up, it's
probably not that important.]
------------------- end transcript excerpts --------------------
Wrapup -
* We're leaning towards finishing the R2 client with ugly-but-functional
merge support, using inline text as discussed above.
* The "real" Stellation client should (probably) target R3,
using the R3 visual merge support.
* Finishing the 'minimalist' R2 client will allow us to excise the rest of
the CLI code that's given us so much trouble. It should also support
work on a new generation of command-line tools (Jonathan's proposal sounds
great!)
This 'wrapup' reflects where we were at the end of the IRC chat; it's not
anything like a formal decision. We still want input.
Thoughts?
Jim
--------------------------------------------------------------------
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
