Re: [rt-pmc] Juno Retrospective

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

well, sure...but your mail to this list following up from ian bull was
exactly that.

"Perhaps a general conversation about what makes the release train
more difficult or of less value to the RT projects would be helpful?
What could be done to change that for the RT community?"

I view you as far more of the 'Eclipse Foundation' then posts on the
cross dev list...though you are correct that since I have been on that
mailing list I do see more of the community effort behind that then I
might otherwise.  Sure you are following up on a mail _about_ the
release train...

And you are right, the RT community could indeed make another effort
in that direction up there is little 'drive' to commit the necessary
resources to do something like that, no one is suffering enough of an
'itch' to do it or lead the effort themselves.  The RT project is made
of diverse projects that rarely need to collaborate, the biggest
exception (that I am a party to) being virgo and jetty which
coordinate on integrations and things like jsp
dependencies...something that would happen regardless of there being
an RT group that both projects where members of.

Also so I am not coming across as some sort of malcontent, all of this
has been discussed on RT pmc called off and on for years now regarding
mission, goals, why we exist and meet...etc.  I just decided to
summarize and respond since you asked :)

cheers,
jesse



--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Wed, Aug 22, 2012 at 9:48 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxx> wrote:
> Jesse,
>
> There is an assumption underlying your answer that needs to be highlighted as just that - an assumption.
>
> When you say "... the organization at large...", you are basically observing the efforts of the community members pulling in a particular direction. In the context of the release train, I assume your talking about the cross-project-list, David Williams' role as release meister, and the like. But from the point of view of the Eclipse Foundation and the EMO, we don't see it that way. If a group of people wanted to do something completely different, we'll support them. There is nothing carved in stone that says that there can be only one release train, or one release train process.
>
> So I disagree that this is "... a systemic issue within the eclipse foundation". It's not systemic. If the RT community decides that they want to do something different, we will figure out a way to support you. But you folks need to decide what that is.
>
>
>> -----Original Message-----
>> From: Jesse McConnell [mailto:jesse.mcconnell@xxxxxxxxx]
>> Sent: August-22-12 10:38 AM
>> To: mike.milinkovich@xxxxxxxxxxx; Runtime Project PMC mailing list
>> Subject: Re: [rt-pmc] Juno Retrospective
>>
>> it is deeper then that with regards to Runtime in general
>>
>> For almost as long as Jetty has been part of eclipse there has been a bit fat '?'
>> over RT on what it represents and why it even exists.
>> Jeff McAffer was attempting to address that somewhat with his attempts at
>> making a product out of the runtime, where there was some compelling
>> story for using the different diverse systems of the runtime project together
>> in some way.  Jetty participated in that with the WebStarter kits that there
>> was a flurry of activity behind for a while there...seems like couple years back
>> at this point.
>>
>> Personally I see it as a systemic issue within the eclipse foundation and its
>> focus on a tricked out editor.  On one hand the eclipse foundation is pushing
>> to be a more general entity that accepts open source projects that care
>> about IP and want to have their whole existence validated and viewed
>> through that spectrum.  This is a nobel goal and one of the reasons that jetty
>> came to eclipse.  However on the other hand it seems the whole focus of the
>> actual organization is to produce this tricked out editor as a core which
>> strategic members can build their products on.  Enter the release train...the
>> core mechanism that realizes this goal.  Now I am not saying this is a bad thing
>> nor that is is not needed....it is just not the primary end goal for a project like
>> jetty.
>>
>> Now, there has been some lip service spent on eclipse (equinox) really being
>> a software stack to build applications on, which jetty supports and would
>> certainly like to be a part of, but this so bound up in the eclipse editor as the
>> 'shining' example that it is hard to separate the two.  Jeff was working
>> towards that goal for a while but it was obviously a side goal and not a
>> mission of the organization at large, which can be evidenced by the effort
>> stalling and basically disappearing once he left.
>>
>> Which brings us back to the RT group...which briefly toyed with the idea of
>> producing a software stack that could do much of what something like Ruby
>> on Rails could do, only in an osgi fashion and leveraging the projects within RT
>> and perhaps a handful of other projects within eclipse.  That never really
>> materialized, so the RT group now basically motors along on auto-pilot.
>>
>> <thomas's mail showed up>
>>
>> I'll paste in and tweak my response to Wayne when he asked me privately
>> this question.
>>
>> - there is no _need_ for jetty to do it, we have no UI components that are
>> remotely critical to or of interest to core jetty developers or users, we had a
>> wtp component that we worked on some but really never got much interest
>> in
>>
>> - the process is bothersome, it takes time to maintain the files (and go re-
>> figure out what we needed to do when the time came), build metadata, p2
>> repositories, release docuware, etc
>>
>> - we don't seem to fit the traditional eclipse project structure, ie we don't live
>> and breathe around the release of the eclipse platform and we get no real
>> benefit from committing resources to making it happen, its ultimately just a
>> distraction, when eclipse releases there is no evidence that we have
>> participated or had an impact on it
>>
>> - the end result of our dropping off the release train is only a net positive for
>> us, we get the occasional hour or three back while equinox and anyone else
>> updates some line in their build to point to a
>> p2 repository...problem solved
>>
>>
>> cheers,
>> jesse
>>
>> p.s. this is probably a good time to get this conversation going again, we have
>> had it off and on in the RT calls but its been a while (though I have missed the
>> last couple by a few minutes :( )
>>
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx
>>
>>
>> On Wed, Aug 22, 2012 at 9:09 AM, Mike Milinkovich
>> <mike.milinkovich@xxxxxxxxxxx> wrote:
>> > Just a suggestion - feel free to ignore.
>> >
>> >
>> >
>> > It seems to me that we have a general issue with EclipseRT and the
>> > release train. More specifically, I think there is a sense that the
>> > release train is of less value to the RT projects. Or that the process
>> > is more burdensome for them. Jetty's recent announcement that they're
>> > not planning to participate in Kepler is a concrete example of this.
>> >
>> >
>> >
>> > Perhaps a general conversation about what makes the release train more
>> > difficult or of less value to the RT projects would be helpful? What
>> > could be done to change that for the RT community?
>> >
>> >
>> >
>> > Of course, it's possible that I am completely out to lunch on this
>> > perception. It wouldn't be the first time :)
>> >
>> >
>> >
>> >
>> >
>> > From: rt-pmc-bounces@xxxxxxxxxxx [mailto:rt-pmc-bounces@xxxxxxxxxxx]
>> > On Behalf Of Ian Bull
>> > Sent: August-22-12 9:49 AM
>> > To: Runtime Project PMC mailing list
>> > Subject: [rt-pmc] Juno Retrospective
>> >
>> >
>> >
>> > Hi everyone,
>> >
>> >
>> >
>> > The planning council is interested in feedback on the Juno Release.
>> > If you have anything (good or bad) that you would like to add to the
>> > Juno Retrospective, please follow up here and I'll pass the comments
>> > along to the planning council.
>> >
>> >
>> >
>> > Also, the Kepler schedule has been finalized. You can see it here [1].
>> >
>> >
>> >
>> > [1] http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule
>> >
>> >
>> >
>> > Cheers,
>> >
>> > Ian
>> >
>> >
>> >
>> > --
>> > R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
>> > http://eclipsesource.com | http://twitter.com/eclipsesource
>> >
>> >
>> > _______________________________________________
>> > rt-pmc mailing list
>> > rt-pmc@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/rt-pmc
>> >
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc