I confess I know nothing about Surfnet and Mitre code bases, but in general I second the strategy of fresh start. This gives us all an opportunity to think fresh on a well designed architecture. I think the expertise and lessons learn't in building existing three code bases will be much more valuable then the code itself. Nothing to undermine the existing code, just emphasizing more on the architecture then on existing implementations.
>>>>> 5. Analyze initial feature list from proposal and review donated feature >>>>> sets In regards to the above, just want to refresh that since we decided to keep the feature set high level in proposal, revisiting this with lower level details might be necessary before we dive into the architecture. Suresh On Mar 28, 2011, at 1:09 PM, Franklin, Matthew B. wrote: > My current thought regarding this strategy is to start fresh. Adopting > any one code base as a starting point or trying to merge two together will > probably not produce the best product. If we are after quality and > consistency of style over quick release, then this approach will allow us > to define as a group the structure and function of the application we > build. > > I am flexible on this point, but want to ensure that we have a strategy > that builds a robust, scalable, high-quality code base. > > -Matt > > On 3/28/11 12:37 PM, "Marlon Pierce" <[email protected]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I think we have a critical initial work regarding #5/#6 below. Surfnet >> and Mitre codes are both using SpringMVC as a general framework. We at >> IU are not, but after reviewing both of the other code bases, we think it >> is the way to go and will be happy to adopt it and add to it. >> >> >> I think then we have the following options. At this time, I don't have a >> preference. >> >> * Option 1: Start completely from scratch with a new project layout. >> >> * Option 2: Adopt either the Surfnet or Mitre code donations as our >> starting point. >> >> * Option 3: Merge the core elements of Surfnet and Mitre approaches to >> create a new skeleton. >> >> >> How should we proceed in choosing between these options? I have not >> considered the amount of work or feasibility to do any of these. This is >> just to get the discussion going. >> >> >> Marlon >> >> >> On 3/25/11 12:29 PM, Carlucci, Tony wrote: >>> +3 on the MITRE side for Spring MVC! >>> >>> --- >>> Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development & >>> Maint >>> e: [email protected] | v: 781.271.2432 | f: 781.271.3299 >>> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420 >>> >>> >>> -----Original Message----- >>> From: Marlon Pierce [mailto:[email protected]] >>> Sent: Friday, March 25, 2011 11:13 AM >>> To: [email protected] >>> Subject: Re: Next Steps >>> >>> For #6 in particular we should have consensus on framework as a >>> starting point. SpringMVC seems like the right choice. >>> >>> >>> Marlon >>> >>> >>> On 3/25/11 11:07 AM, Scott Wilson wrote: >>> >>>> On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote: >>>>> It looks like accounts for us new committers are being created. As we >>>>> prepare to commit the donated code bases, I thought it would be good >>>>> to >>>>> lay out some of the next steps. The last few weeks seem to have been >>>>> busy >>>>> for everyone, and we haven't had many discussions regarding what we >>>>> need >>>>> to do to get Rave moving forward. The following is a list of things I >>>>> think we need to accomplish in the near term. The list is by no means >>>>> comprehensive and there is probably a better place for it to live, >>>>> but it >>>>> is intended to spark discussion. >>> >>>> Looks like a good start - thanks for starting the ball rolling! >>> >>>>> 1. Commit donated code bases >>>>> 2. Finish public website on CMS (think Ross started this?) >>>>> 3. Lay out wiki structure and port relevant portions to Apache wiki >>>>> (think >>>>> Ate started this?) >>>>> 4. Discuss working agreements for coding practices, quality, unit >>>>> testing, >>>>> coverage, CI, sandbox environments, etc (Some of this is probably >>>>> standard >>>>> Apache practice) >>> >>>> I don't think there is such a thing as a standard Apache coding >>>> practice :-) >>> >>>>> 5. Analyze initial feature list from proposal and review donated >>>>> feature >>>>> sets >>>>> 6. Discuss high level architecture and agree on basic design >>>>> 7. Agree on process for "cherry picking" features and integrating them >>>>> into the Rave code base >>> >>>> Well, we can pick things we want to work on and mail the list to say >>>> we're doing it, but beyond that I don't think we can have that much of >>>> a process - anyone can implement any features they want and submit >>>> patches for them, its up to committers whether to commit them. >>> >>>>> 8. Commit initial project structure and configure CI >>>>> 9. Begin work on features >>>>> >>>>> This list is high-level, but I think it is a good starting place. >>>>> Time to >>>>> get this project moving forward! >>> >>>> +1 >>> >>>>> >>>>> -Matt >>>>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.16 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJNkLk9AAoJEEfVXEODPFIDHQcH/RcnViAvyq3La1I9fWKO3E0z >> aJCJWTWdZ2x+DZXImREwJHUkYXq85K0zjSpXHroZ5KY6e1Q1l8NW4aDo9gxsr0Oa >> AcRnp3MTPDdEiSG5M0M+SaHedjgjmPxyiplqONVk2R8dKkTPp9EwV+zRct8C+1mW >> pMeCstC6ZfKolktxhppm+ZgOThIQGOw1+ftaLotsYXtyTpPKsSnNOskYFEV0uWTB >> IRdEmIwpDYrg0b6+gsaYybjokMEQDle5yhbwjFg5wZoDPpefXTFlr1/U5v3FGhSW >> UN/7A2fGvjfBUebUprZZP1mEluR2AXx+d9vOnYKQCEwL5j4w/hA2YM2d1SORMg4= >> =IIS6 >> -----END PGP SIGNATURE----- >
