Re: [stellation-res] *Important* Eclipse version question; partial IRC

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Jim Wright - IBM Research" <jwright@xxxxxxxxxxxxxx>
To: <stellation-res@xxxxxxxxxxxxxxx>
Sent: Wednesday, July 23, 2003 10:07 AM
Subject: 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?
>
From my personal point of view, I would prefer to go with the R3 approach.
The first reason is that visual merge is critical to my comfort zone in
using a SCM and I have become spoiled by the CVS based merge in Eclipse. The
second reason is that I like working with the R3 features in Eclipse. That
said, if you feel that there are compelling reasons to support V2 in the
short term, I won't argue.

Regards

Jonathan Gossage

Personal Email  jgossage@xxxxxxxx
Business Email jonathan@xxxxxxxxxxxxxx