Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Common Build Infra (was Re: Bjorn "Knuckles" the Ganymede Enforcer asks a question about STP...)

Thanks Nick. I've passed this onto one of my incubating projects.

> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-
> project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
> Sent: Wednesday, June 11, 2008 4:45 PM
> To: eclipse.org-planning-council
> Cc: Cross project issues
> Subject: [cross-project-issues-dev] Common Build Infra (was Re: Bjorn
> "Knuckles" the Ganymede Enforcer asks a question about STP...)
> 
> http://wiki.eclipse.org/Modeling_Project_Releng
> 
> Gaff, Doug wrote:
> > Hi Nick,
> >
> > Can you accommodate the lazy among us and provide a pointer to your
> > build docs? I spent 17 seconds on the EMF site and wiki looking. ;)
> >
> > +1 for a sourceforge project with all the bits.
> >
> > Doug
> >
> >
> >> -----Original Message-----
> >> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> >> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf
> Of
> >> Nick Boldt
> >> Sent: Wednesday, June 11, 2008 4:07 PM
> >> To: Cross project issues
> >> Cc: eclipse.org-planning-council
> >> Subject: Re: [cross-project-issues-dev] Re: [eclipse.org-planning-
> >> council]Bjorn "Knuckles" the Ganymede Enforcer asks a question
about
> >> STP...
> >>
> >> +1 for a revisit to Portland, for Build Summit ][, to explore steps
> >> toward an Eclipse.org-hosted build farm.
> >>
> >> +10 if all the people asking for a build farm are willing to
provide
> >> staff to do it. I'm all for this idea, but AFAIK the Eclipse
> >>
> > Foundation
> >
> >> isn't hemorrhaging money, so it comes down to the usual "money
where
> >> mouth is" problem, as it did two years ago for the first Summit.
> Great
> >> idea, but who wants to actually do it, and pay for it? :)
> >>
> >> <aside>
> >> FWIW, my setup (for 25 builds all running on emft.eclipse and/or
> >> emf.torolab, including one GEF from Tools, not Modeling), is pretty
> >> heavily documented and stress-tested. If more projects move to this
> >> system, we'd be all the closer to a common infrastructure -- since
> it
> >> doesn't matter on which server you run it, so it can be distributed
> >> across multiple vservers at eclipse.org. And to assuage some fears
> >> about
> >> yet another black box, it's really just PDE Build +
> releng.basebuiler
> >>
> > +
> >
> >> some extra script candy + web UI eye candy. All the hard work was
> done
> >> ages ago by the PDE & platform releng folks.
> >>
> >> If the foundation was allowed to distribute a Linux distro on its
> >> servers (GPL issues, I'm guessing), then this could be extended to
> >> include not just the code, but the server config too. We could have
> >>
> > the
> >
> >> whole "build server in a box" idea, running either on peoples' own
> >> machines, copied to the root of a vserver, or even inside a VMWare
/
> >> virtualbox client. EMO: is that possible? Or would such an animal
> have
> >> to live at, eg., sourceforge?
> >> </aside>
> >>
> >> So, really, I see the issue here as being that everyone
acknowledges
> >> that releng is important, but everyone wants to pass the hot potato
> >>
> > off
> >
> >> to someone else to worry about it. Until everyone invests time in
> >> sharing the potato, it'll just keep getting passed around.
> >>
> >> $0.02,
> >>
> >> Nick
> >>
> >> Gaff, Doug wrote:
> >>
> >>> Strong +1 on a common build infrastructure. I would go further by
> >>> saying that build counts as infrastructure, and the foundation
> >>>
> > should
> >
> >>> staff a position for this role.
> >>>
> >>> *I think we should get a comment from Oisin on whether he intends
> to
> >>> get the STP bits signed or not*. Then we can talk about either
> >>> granting a dispensation or throwing STP from the train. (Oisin: I
> >>> prefer dark chocolate from Europe.)
> >>>
> >>> It's good to discuss this now, and Bjorn was right to bring it up
> >>> before the final drop.
> >>>
> >>> *From:* cross-project-issues-dev-bounces@xxxxxxxxxxx
> >>> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] *On Behalf
Of
> >>> *Ed Merks
> >>> *Sent:* Wednesday, June 11, 2008 2:44 PM
> >>> *To:* eclipse.org-planning-council
> >>> *Cc:* Cross project issues;
> >>> eclipse.org-planning-council-bounces@xxxxxxxxxxx;
> >>> eclipse.org-planning-council
> >>> *Subject:* [cross-project-issues-dev] Re:
> >>> [eclipse.org-planning-council] Bjorn "Knuckles" the Ganymede
> >>>
> > Enforcer
> >
> >>> asks a question about STP...
> >>>
> >>> Bjorn,
> >>>
> >>> It seems to me that STP's +3 bits aren't due until the 18th. Could
> >>>
> > we
> >
> >>> just say that if those bits aren't signed at that time, then they
> >>> won't be in the final bits? Or is there some reason we have to
> >>>
> > decide
> >
> >>> earlier than that? I know from chatting with Oisin that he's
> >>> scrambling trying to get builds done with glitches in Buckminster
> >>> that's leaving him with a manual task. And Nick is trying to help
> >>>
> > him
> >
> >>> as I type this note...
> >>>
> >>> <pointless-rambling>
> >>> I've never quite understood why it's so important to everyone that
> >>> everyone else sign all their bits. But then I've not spent a lot
of
> >>> time trying to understand it, and we did all agree to it, so I
> >>>
> >> suppose
> >>
> >>> it's pointless to ask why it's so important. The must do's did
> state
> >>> that exceptions could be granted. Kind of like dispensations.
Maybe
> >>>
> >> if
> >>
> >>> STP bought chocolate for all the other islanders we'd be inclined
> to
> >>> vote more favorably...
> >>> </pointless-rambling>
> >>>
> >>> <rant>
> >>> Of course this whole issue highlights a more fundamental problem,
> >>>
> > and
> >
> >>> that's the huge investment that goes into making all these darned
> >>> builds work. All this release engineering stuff is a full time job
> >>>
> >> for
> >>
> >>> Nick. By the time we add up all the releng support that goes into
> >>> Ganymede, and consider how much overlap there is in the various
> >>>
> >> tasks,
> >>
> >>> you've got to think there must be a more productive way to make
> this
> >>> happen. I mean for goodness sake, this is an open source
community,
> >>> surely we can do a better job on the infrastructure front given
the
> >>> resources are being poured in already anyway...
> >>> </rant>
> >>>
> >>>
> >>> Ed Merks/Toronto/IBM@IBMCA
> >>> mailto: merks@xxxxxxxxxx
> >>> 905-413-3265 (t/l 313)
> >>>
> >>>
> >>> Inactive hide details for Bjorn Freeman-Benson
> >>> <bjorn.freeman-benson@xxxxxxxxxxx>Bjorn Freeman-Benson
> >>> <bjorn.freeman-benson@xxxxxxxxxxx>
> >>>
> >>> *Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>*
> >>> Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> >>>
> >>> 06/11/2008 01:58 PM
> >>>
> >>> Please respond to
> >>> "eclipse.org-planning-council" <eclipse.org-planning-
> >>>
> >> council@xxxxxxxxxxx>
> >>
> >>>
> >>> To
> >>>
> >>>
> >>>
> >>>
> >>> "eclipse.org-planning-council"
> >>> <eclipse.org-planning-council@xxxxxxxxxxx>, Cross project issues
> >>> <cross-project-issues-dev@xxxxxxxxxxx>
> >>>
> >>> cc
> >>>
> >>>
> >>>
> >>> Subject
> >>>
> >>>
> >>>
> >>>
> >>> Re: [eclipse.org-planning-council] Bjorn "Knuckles" the Ganymede
> >>> Enforcer asks a question about STP...
> >>>
> >>>
> >>>
> >>>
> >>> Mitch,
> >>>
> >>> I think we should give them more time.
> >>>
> >>> How much time? The final release bits are supposed to be built on
> >>> Friday. And that assumes that there has been integration testing,
> >>>
> >> etc.
> >>
> >>> all along through the RC process... Don't get me wrong, I'm not
> >>>
> >> trying
> >>
> >>> to be mean, I'm just asking the perfectly practical questions: how
> >>> much slippage is the team willing to allow STP? Are we going to
> slip
> >>> the whole Ganymede? Are we going to rebuild the whole Ganymede 48
> >>> hours before the big launch to accommodate STP? What are the
> >>>
> >> constraints?
> >>
> >>> - Bjorn
> >>> --
> >>> [end of message] _______________________________________________
> >>> eclipse.org-planning-council mailing list
> >>> eclipse.org-planning-council@xxxxxxxxxxx
> >>>
> >>>
> >
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> >>> IMPORTANT: Membership in this list is generated by processes
> >>>
> > internal
> >
> >>> to the Eclipse Foundation. To be permanently removed from this
> list,
> >>> you must contact emo@xxxxxxxxxxx to request removal.
> >>>
> >>>
> >>>
> >
---------------------------------------------------------------------
> >
> >> ---
> >>
> >>> _______________________________________________
> >>> cross-project-issues-dev mailing list
> >>> cross-project-issues-dev@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>>
> >>>
> >> --
> >> Nick Boldt :: Release Engineer, IBM Toronto Lab
> >> Eclipse Modeling :: http://www.eclipse.org/modeling
> >> http://wiki.eclipse.org/index.php/User:Nickb
> >>
> >> _______________________________________________
> >> eclipse.org-planning-council mailing list
> >> eclipse.org-planning-council@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-
> council
> >>
> >> IMPORTANT: Membership in this list is generated by processes
> internal
> >> to the Eclipse Foundation.  To be permanently removed from this
> list,
> >> you must contact emo@xxxxxxxxxxx to request removal.
> >>
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> >
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> > IMPORTANT: Membership in this list is generated by processes
internal
> to the Eclipse Foundation.  To be permanently removed from this list,
> you must contact emo@xxxxxxxxxxx to request removal.
> >
> 
> --
> Nick Boldt :: Release Engineer, IBM Toronto Lab
> Eclipse Modeling :: http://www.eclipse.org/modeling
> http://wiki.eclipse.org/index.php/User:Nickb
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top