"contrib" sounds like as good of a name as any. I'll move the ALM project the next chance I get.
As for if people really care about ALM in uP3 I really think the work that Drew & Pat did at Chico mitigate many of the current ALM implementors concerns, at least that is my impression from those I have talked to. That they could potentially migrate from ALM to DLM using the Chico tools & experience helps mitigate the worry of ALM maintenance and provides viable upgrade paths. Perhaps this is something we could have the board or steering committee do a slightly more formal survey of. -Eric Andrew Petro wrote: > "contrib" ? > > +1 on moving ALM out of the core uPortal SVN deliverable > > +1 for finding someplace more articulate than "sandbox" for it to live > > +1 for really, seriously, figuring out whether anyone cares about ALM > in uPortal 3... > > > ... and whether those someones are interested in going after > opportunities like Drew Wills' sleek automated ALM-->DLM upgrade and > enhancing DLM (perhaps via adoption of the Mark Boyd code in Sandbox) > to meet their needs. Now that we've got a uPortal Steering Committee, > I thnk this is a job for that committee, to engage with Unicon to > understand the prognosis on the Academus --> Open Source uPortal using > ALM with Open Source Plugins --> Open Source uPortal using DLM with > Open Source Plugins upgrade path, to engage with ESUP-Portail to > understand the prognosis for the "ESUP Distribution Uses DLM" idea. > > I've added this to the agenda for the steering committee bootstrapping > conference call > <http://www.ja-sig.org/wiki/display/UPC/Steering+Committee>. > > Andrew > >> +1 on removing it. >> >> +1 on bill's comments. >> >> based on some previous threads, it almost seems like we need an >> additional svn space outside of the sandbox that is more like a >> uportal framework plug-ins or add-ons space. >> >> >> >> William G. Thompson, Jr. wrote: >>> I think the approach is a good one, although I wonder if it would keep >>> these a bit clearer to put the ALM code into module tree distinct from >>> sandbox so as to keep the meaning of the sandbox "experimental, not in >>> production, code base" clear. >>> >>> On 9/28/07, Eric Dalquist <[EMAIL PROTECTED]> wrote: >>> >>>> In the code cleanup effort outlined for the uP3 community roadmap I've >>>> been removing chunks of deprecated code where prudent and doing other >>>> minor tweaking. Some that was talked about in-depth at the conference >>>> but not as much on this list is what to do with the ALM code. The >>>> plan I >>>> had worked out with several folks was to pull the ALM/integrated modes >>>> code out into a sandboxed project in SVN. >>>> >>>> The goal of this is that we do not want new installs using ALM and we >>>> don't have plans to continue to maintain that code. That said >>>> moving the >>>> code into the sandbox allows someone else to step up at a later >>>> date and >>>> apply ALM patches and actually use the code in uPortal 3. The >>>> sandboxed >>>> project is designed to be an overlay of the uPortal 3 code, if >>>> there is >>>> interest in actually making sure that overlay is functional as we move >>>> forward I'm sure we could tweak the Maven build for the ALM project to >>>> automate that processes. >>>> >>>> These changes have already been made but it doesn't me they can't be >>>> rolled back or have a different strategy taken. >>>> >>>> -Eric >>>> >>>> ALM Move: http://www.ja-sig.org/issues/browse/UP-1835 >>>> Code Cleanup: http://www.ja-sig.org/issues/browse/UP-1832 >>>> >>>> >>>> >>> >>> >>> >> > > > -- > You are currently subscribed to [email protected] as: [EMAIL > PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
