Re: [mylar-dev] enhancements in Mylar team API

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Eugene Kuleshov <eu@xxxxxxxx> wrote on 12/06/2006
03:13:01 AM:

> Mik Kersten wrote:
> >
> > *** P.S. I believe that in terms of user experience the Platform
there 
> > will be a big cost with the current approach of forcing each
team 
> > provider to implement its own silo of synchronization, change
sets 
> > support, and the corresponding UI. I just don’t buy the current
story 
> > that the Team user experience should only work well for developers
> > having one source repository, because a significant portion of
> > developers check out sources for both their project and the frameworks
> > that they build on. Not having change sets be a part of platform
is 
> > part of the problem, but symptoms of this show up on other reports
as 
> > well:
> >
> > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=146917#c9
> >
> > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=89806
> >
> > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=138583
> >
> > I realize that Platform/Team may not have the resource to do
this, but 
> > I’m wondering if it should at least be discussed as an issue
in case 
> > others in the community are willing to help improve those key
parts of 
> > the Team API.
> >
> I can't agree more with Mik on this. Michael, can you please clarify
> what would it take to make the existing change set code an API? Since
it 
> is already used by at least 3 team providers (CVS, Subclipse and 
> Subversive) we have a story.

I don't really view these as three different cases.
CVS and Subversion are very similar capability wise in this respect (i.e.
neither have the concept of a change set built in). I can see the argument
that the classes be made API so they can be used by other repository providers
that do not have the concept. However, there are repositories out there
that do have the concept and would therefore already have their own implementations.
You motivation fore maming the classes API seems to be so that 3d party
tooling like Mylar can use it. As I have said before, this is a mistake.
Mylar should have API that defines what it requries from change sets but
leave the implementation up to the repository provider.

As to what it would take to make the current classes
API, It's really just a matter of resources. By resources, I mean developers
whose main job is to be a committer on the Team component. There is some
up front work that would need to happen to get the API into good shape
and then there would be ongoing maintenance as well. We barely have the
manpower to keep up with our current level of maintenance so we need to
be careful about introducing anything new that would increase this.

> Also, you said that team working on Platform/Team does not have man
> power for this. On the other hand there is at least 3 commercial vendors
> are currently building team providers (p4, Subversive and 
> Rational/Jazz). Would it be possible to request some man power for
this 
> task from those teams? In a result everybody will benefit from this.

I find that the repository vendors are usually pretty
resource strapped as well (it seems to be a common affliction). However,
if you feel strongly about this, then I would suggest that you contact
these and other repository vendors to see if they are willing to participate.

Michael