On 28 Mar 2011, at 18:09, 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.
I think also starting anew will make it easier for other people to contribute. > > -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----- >
