You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Franklin, Matthew B." <mf...@mitre.org> on 2011/03/25 15:48:26 UTC
Next Steps
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.
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)
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
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!
-Matt
Re: Next Steps
Posted by Suresh Marru <sm...@cs.indiana.edu>.
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" <mp...@cs.indiana.edu> 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: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
>>> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>>>
>>>
>>> -----Original Message-----
>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>> Sent: Friday, March 25, 2011 11:13 AM
>>> To: rave-dev@incubator.apache.org
>>> 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-----
>
Re: Next Steps
Posted by Scott Wilson <sc...@gmail.com>.
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" <mp...@cs.indiana.edu> 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: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
>>> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>>>
>>>
>>> -----Original Message-----
>>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>>> Sent: Friday, March 25, 2011 11:13 AM
>>> To: rave-dev@incubator.apache.org
>>> 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-----
>
Re: Next Steps
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
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" <mp...@cs.indiana.edu> 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: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
>> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>>
>>
>> -----Original Message-----
>> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
>> Sent: Friday, March 25, 2011 11:13 AM
>> To: rave-dev@incubator.apache.org
>> 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-----
Re: Next Steps
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----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: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>
>
> -----Original Message-----
> From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
> Sent: Friday, March 25, 2011 11:13 AM
> To: rave-dev@incubator.apache.org
> 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-----
RE: Next Steps
Posted by "Carlucci, Tony" <ac...@mitre.org>.
+3 on the MITRE side for Spring MVC!
---
Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development & Maint
e: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
-----Original Message-----
From: Marlon Pierce [mailto:mpierce@cs.indiana.edu]
Sent: Friday, March 25, 2011 11:13 AM
To: rave-dev@incubator.apache.org
Subject: Re: Next Steps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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/
iQEcBAEBAgAGBQJNjLDpAAoJEEfVXEODPFIDN+QH/2CXMQGCgDOGo0Lblblbz+Xc
XTgQBo/AbXn+qrlhkTiV6OEWwpjaFO/orj0XBIEPKaPvStpSWEaM3yiWvCF3nYCU
zvEwADE58H156Xk1323FpnudVkVEfwsQWtxqX9/7yNoV4ndxyWnIl+BeRl5LvSCY
QjJt3oqWEcWBtzlF+QnmHbyS5Vz72FV76GK+5hr5S937/quLA86fZOzYtBQ+nhiB
fk9yT4TZF3IhMjs2jOGUcn6s0ekq2YRwSO70XTz9xIW5p9fIoZwWyCNJkIP8E0hK
GRuY0cjmublbh2B3DKkuV0v6f/O3yQmApyrB/g7v8WSK4W1ykHfujXQAAiNGdqs=
=XNoC
-----END PGP SIGNATURE-----
Re: Next Steps
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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/
iQEcBAEBAgAGBQJNjLDpAAoJEEfVXEODPFIDN+QH/2CXMQGCgDOGo0Lblblbz+Xc
XTgQBo/AbXn+qrlhkTiV6OEWwpjaFO/orj0XBIEPKaPvStpSWEaM3yiWvCF3nYCU
zvEwADE58H156Xk1323FpnudVkVEfwsQWtxqX9/7yNoV4ndxyWnIl+BeRl5LvSCY
QjJt3oqWEcWBtzlF+QnmHbyS5Vz72FV76GK+5hr5S937/quLA86fZOzYtBQ+nhiB
fk9yT4TZF3IhMjs2jOGUcn6s0ekq2YRwSO70XTz9xIW5p9fIoZwWyCNJkIP8E0hK
GRuY0cjmublbh2B3DKkuV0v6f/O3yQmApyrB/g7v8WSK4W1ykHfujXQAAiNGdqs=
=XNoC
-----END PGP SIGNATURE-----
Re: Next Steps
Posted by Ross Gardler <rg...@apache.org>.
Yes, re-reading my words I can see it might be read as "get consensus" I agree with Sylvain. My intention was that 1) and 3) happen in quick succession. Proceed with the assumption that no objection will be raised. If one is raised we have a wonderful time machine (subversion) to resolve the issue.
Sent from my mobile device.
On 25 Mar 2011, at 18:37, Sylvain Wallez <sy...@bluxte.net> wrote:
> Le 25/03/11 17:32, Ross Gardler a écrit :
>> On 25/03/2011 15:07, Scott Wilson wrote:
>>>
>>> On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote:
> [...]
>>>> 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 :-)
>>
>> Scott is correct. There is no "standard" but there are a whole bunch of
>> common practices that you'll find here. I'm not sure how the other
>> mentors plan to tackle this issue. My own style is to let you get on
>> with it and pipe up if I believe either a) something is potentially
>> harmful to an ASF project or b) there is a way to do something that I
>> believe will help.
>
> Well, I personally have two important rules :
> - use spaces for indentation and not tabs
> - choose a consistent coding standard that nobody is strongly against (which is very different from "everybody agrees on") and stick with it.
>
> That's it :-)
>
>> For your mentors to do this effectively you need to discuss everything
>> here on the list. I don't think there will be much of a problem with
>> that in these team.
>>
>>>> 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.
>>
>> Yes, this is probably the best approach.
>>
>> 1) say I'm going to work on getting feature X implemented I know how the code in foo does that so I'm going to use that as a starting point. This means I will implement it like this [pseudo code/UML/whatever]
>>
>> 2) community sits back and lets it happen or shouts "no - bar does it better because.."
>>
>> 3) regular, frequent and early commits to give people chance to sound a word of caution early
>>
>> One of the approaches I like in some of our projects is for someone to post a "Random Thought". This is a very early stage proposal for a solution. The fact that it is a Random Thought means that people know it is not supposed to be fully thought out and so constructive criticism and enhancements are welcome.
>>
>> These are posed to the list with [RT] in the subject and will typically define a use case, a problem preventing the use case from being carried out today, a rough idea that will satisfy the use case, a rough proposal for how it might be implemented
>>
>> Often such an RT can start the above 1-2-3 cycle going.
>
> You can also ready a blog post I wrote long ago about "I-will-do-it-o-cracy" that discusses how informing that you _will_ do something before actually doing it keeps the community rolling by allowing people to voice their opinion before too much work has been done, which can lead both to technical problems (reverts, etc) and more harmfully community problems : http://bluxte.net/musings/2005/03/21/meritocracy-doocracy-and-iwilldoitocracy
>
> Note that this is a bit different from trying to constantly seek consensus and agreement, which can lead a projet to stall.
>
> Sylvain
>
> --
> Sylvain Wallez - http://bluxte.net
>
Re: Next Steps
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1
On Mar 25, 2011, at 2:37 PM, Sylvain Wallez wrote:
> Le 25/03/11 17:32, Ross Gardler a écrit :
>> On 25/03/2011 15:07, Scott Wilson wrote:
>>>
>>> On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote:
> [...]
>>>> 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 :-)
>>
>> Scott is correct. There is no "standard" but there are a whole bunch of
>> common practices that you'll find here. I'm not sure how the other
>> mentors plan to tackle this issue. My own style is to let you get on
>> with it and pipe up if I believe either a) something is potentially
>> harmful to an ASF project or b) there is a way to do something that I
>> believe will help.
>
> Well, I personally have two important rules :
> - use spaces for indentation and not tabs
> - choose a consistent coding standard that nobody is strongly against (which is very different from "everybody agrees on") and stick with it.
>
> That's it :-)
>
>> For your mentors to do this effectively you need to discuss everything
>> here on the list. I don't think there will be much of a problem with
>> that in these team.
>>
>>>> 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.
>>
>> Yes, this is probably the best approach.
>>
>> 1) say I'm going to work on getting feature X implemented I know how the code in foo does that so I'm going to use that as a starting point. This means I will implement it like this [pseudo code/UML/whatever]
>>
>> 2) community sits back and lets it happen or shouts "no - bar does it better because.."
>>
>> 3) regular, frequent and early commits to give people chance to sound a word of caution early
>>
>> One of the approaches I like in some of our projects is for someone to post a "Random Thought". This is a very early stage proposal for a solution. The fact that it is a Random Thought means that people know it is not supposed to be fully thought out and so constructive criticism and enhancements are welcome.
>>
>> These are posed to the list with [RT] in the subject and will typically define a use case, a problem preventing the use case from being carried out today, a rough idea that will satisfy the use case, a rough proposal for how it might be implemented
>>
>> Often such an RT can start the above 1-2-3 cycle going.
>
> You can also ready a blog post I wrote long ago about "I-will-do-it-o-cracy" that discusses how informing that you _will_ do something before actually doing it keeps the community rolling by allowing people to voice their opinion before too much work has been done, which can lead both to technical problems (reverts, etc) and more harmfully community problems : http://bluxte.net/musings/2005/03/21/meritocracy-doocracy-and-iwilldoitocracy
>
> Note that this is a bit different from trying to constantly seek consensus and agreement, which can lead a projet to stall.
>
> Sylvain
>
> --
> Sylvain Wallez - http://bluxte.net
>
Re: Next Steps
Posted by Sylvain Wallez <sy...@bluxte.net>.
Le 25/03/11 17:32, Ross Gardler a écrit :
> On 25/03/2011 15:07, Scott Wilson wrote:
>>
>> On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote:
[...]
>>> 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 :-)
>
> Scott is correct. There is no "standard" but there are a whole bunch of
> common practices that you'll find here. I'm not sure how the other
> mentors plan to tackle this issue. My own style is to let you get on
> with it and pipe up if I believe either a) something is potentially
> harmful to an ASF project or b) there is a way to do something that I
> believe will help.
Well, I personally have two important rules :
- use spaces for indentation and not tabs
- choose a consistent coding standard that nobody is strongly against
(which is very different from "everybody agrees on") and stick with it.
That's it :-)
> For your mentors to do this effectively you need to discuss everything
> here on the list. I don't think there will be much of a problem with
> that in these team.
>
>>> 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.
>
> Yes, this is probably the best approach.
>
> 1) say I'm going to work on getting feature X implemented I know how
> the code in foo does that so I'm going to use that as a starting
> point. This means I will implement it like this [pseudo
> code/UML/whatever]
>
> 2) community sits back and lets it happen or shouts "no - bar does it
> better because.."
>
> 3) regular, frequent and early commits to give people chance to sound
> a word of caution early
>
> One of the approaches I like in some of our projects is for someone to
> post a "Random Thought". This is a very early stage proposal for a
> solution. The fact that it is a Random Thought means that people know
> it is not supposed to be fully thought out and so constructive
> criticism and enhancements are welcome.
>
> These are posed to the list with [RT] in the subject and will
> typically define a use case, a problem preventing the use case from
> being carried out today, a rough idea that will satisfy the use case,
> a rough proposal for how it might be implemented
>
> Often such an RT can start the above 1-2-3 cycle going.
You can also ready a blog post I wrote long ago about
"I-will-do-it-o-cracy" that discusses how informing that you _will_ do
something before actually doing it keeps the community rolling by
allowing people to voice their opinion before too much work has been
done, which can lead both to technical problems (reverts, etc) and more
harmfully community problems :
http://bluxte.net/musings/2005/03/21/meritocracy-doocracy-and-iwilldoitocracy
Note that this is a bit different from trying to constantly seek
consensus and agreement, which can lead a projet to stall.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Next Steps
Posted by Ross Gardler <rg...@apache.org>.
On 26/03/2011 23:38, Upayavira wrote:
> I'll try to do a karma grant for Rave folks tomorrow, meaning you can
> all start committing to your hearts content :-)
I just did it.
If anyone on the initial committer list cannot now write to the Rave svn
then I did something wrong. Please mail this list with your availid and
ask us to check it.
How do you know if you have access? you could add your name, in
alphabetic order, to the list of contributors on our "in progress" web
site. To do so follow these instructions:
- install CMS bookmarklet from the bottom of https://cms.apache.org/
- http://rave.staging.apache.org/rave/people.html
- click the CMS bookmarklet
- click edit
- make your edit
- tick the "quick commit" checkbox and enter a log message
Since you ticked "quick commit" you will have triggered a staging build
with this commit (without it you commit but no staging build is carried
out - handy if you know you have more to do).
View your work by clicking "staged"
If this process fails at any point then let us know.
If it did work, feel free to improve the very rough skeleton site I've
put together. Note that you can checkout the site files using SVN and
work on them locally.
There's some info on the CMS at http://www.apache.org/dev/cmsref.html
There's a new committer guide at
http://www.apache.org/dev/new-committers-guide.html
and a FAQ at http://www.apache.org/dev/committers.html
you know where we are if you need help
>
> Upayavira
>
> On Fri, 25 Mar 2011 16:32 +0000, "Ross Gardler"<rg...@apache.org>
> wrote:
>> On 25/03/2011 15:07, 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?)
>>
>> Not yet. It's getting closer to the top of my todo list. now you are All
>> getting your logins I will keep it moving up. My intention is to put a
>> skeleton in place for you and you can take it from there.
>>
>>>> 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 :-)
>>
>> Scott is correct. There is no "standard" but there are a whole bunch of
>> common practices that you'll find here. I'm not sure how the other
>> mentors plan to tackle this issue. My own style is to let you get on
>> with it and pipe up if I believe either a) something is potentially
>> harmful to an ASF project or b) there is a way to do something that I
>> believe will help.
>>
>> For your mentors to do this effectively you need to discuss everything
>> here on the list. I don't think there will be much of a problem with
>> that in these team.
>>
>>>> 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.
>>
>> Yes, this is probably the best approach.
>>
>> 1) say I'm going to work on getting feature X implemented I know how the
>> code in foo does that so I'm going to use that as a starting point. This
>> means I will implement it like this [pseudo code/UML/whatever]
>>
>> 2) community sits back and lets it happen or shouts "no - bar does it
>> better because.."
>>
>> 3) regular, frequent and early commits to give people chance to sound a
>> word of caution early
>>
>> One of the approaches I like in some of our projects is for someone to
>> post a "Random Thought". This is a very early stage proposal for a
>> solution. The fact that it is a Random Thought means that people know it
>> is not supposed to be fully thought out and so constructive criticism
>> and enhancements are welcome.
>>
>> These are posed to the list with [RT] in the subject and will typically
>> define a use case, a problem preventing the use case from being carried
>> out today, a rough idea that will satisfy the use case, a rough proposal
>> for how it might be implemented
>>
>> Often such an RT can start the above 1-2-3 cycle going.
>>
>> Ross
>>
Re: Next Steps
Posted by Upayavira <uv...@odoko.co.uk>.
I'll try to do a karma grant for Rave folks tomorrow, meaning you can
all start committing to your hearts content :-)
Upayavira
On Fri, 25 Mar 2011 16:32 +0000, "Ross Gardler" <rg...@apache.org>
wrote:
> On 25/03/2011 15:07, 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?)
>
> Not yet. It's getting closer to the top of my todo list. now you are All
> getting your logins I will keep it moving up. My intention is to put a
> skeleton in place for you and you can take it from there.
>
> >> 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 :-)
>
> Scott is correct. There is no "standard" but there are a whole bunch of
> common practices that you'll find here. I'm not sure how the other
> mentors plan to tackle this issue. My own style is to let you get on
> with it and pipe up if I believe either a) something is potentially
> harmful to an ASF project or b) there is a way to do something that I
> believe will help.
>
> For your mentors to do this effectively you need to discuss everything
> here on the list. I don't think there will be much of a problem with
> that in these team.
>
> >> 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.
>
> Yes, this is probably the best approach.
>
> 1) say I'm going to work on getting feature X implemented I know how the
> code in foo does that so I'm going to use that as a starting point. This
> means I will implement it like this [pseudo code/UML/whatever]
>
> 2) community sits back and lets it happen or shouts "no - bar does it
> better because.."
>
> 3) regular, frequent and early commits to give people chance to sound a
> word of caution early
>
> One of the approaches I like in some of our projects is for someone to
> post a "Random Thought". This is a very early stage proposal for a
> solution. The fact that it is a Random Thought means that people know it
> is not supposed to be fully thought out and so constructive criticism
> and enhancements are welcome.
>
> These are posed to the list with [RT] in the subject and will typically
> define a use case, a problem preventing the use case from being carried
> out today, a rough idea that will satisfy the use case, a rough proposal
> for how it might be implemented
>
> Often such an RT can start the above 1-2-3 cycle going.
>
> Ross
>
Re: Next Steps
Posted by Ross Gardler <rg...@apache.org>.
On 25/03/2011 15:07, 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?)
Not yet. It's getting closer to the top of my todo list. now you are All
getting your logins I will keep it moving up. My intention is to put a
skeleton in place for you and you can take it from there.
>> 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 :-)
Scott is correct. There is no "standard" but there are a whole bunch of
common practices that you'll find here. I'm not sure how the other
mentors plan to tackle this issue. My own style is to let you get on
with it and pipe up if I believe either a) something is potentially
harmful to an ASF project or b) there is a way to do something that I
believe will help.
For your mentors to do this effectively you need to discuss everything
here on the list. I don't think there will be much of a problem with
that in these team.
>> 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.
Yes, this is probably the best approach.
1) say I'm going to work on getting feature X implemented I know how the
code in foo does that so I'm going to use that as a starting point. This
means I will implement it like this [pseudo code/UML/whatever]
2) community sits back and lets it happen or shouts "no - bar does it
better because.."
3) regular, frequent and early commits to give people chance to sound a
word of caution early
One of the approaches I like in some of our projects is for someone to
post a "Random Thought". This is a very early stage proposal for a
solution. The fact that it is a Random Thought means that people know it
is not supposed to be fully thought out and so constructive criticism
and enhancements are welcome.
These are posed to the list with [RT] in the subject and will typically
define a use case, a problem preventing the use case from being carried
out today, a rough idea that will satisfy the use case, a rough proposal
for how it might be implemented
Often such an RT can start the above 1-2-3 cycle going.
Ross
Re: Next Steps
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Scott,
I assume Franklin referred mostly to the shared services offered by asf-infra. Yes, we can and should use them.
In terms of coding practices, depending on how you define that, there are actually strictly enforced coding practices. For instance non trivial changes, design aspects, etc. should be discussed on the mailing list first. However I believe you were referring to the code style, which is up to the pmc/developers, the ASF does not enforce anything in that area, you are correct.
Just a minor clarification,
Hadrian
On Mar 25, 2011, at 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
>>
>
Re: Next Steps
Posted by Scott Wilson <sc...@gmail.com>.
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
>
Re: Next Steps
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks for initiating this, Matt. I was thinking along the same lines.
Marlon
On 3/25/11 10:48 AM, 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.
>
> 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)
> 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
> 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!
>
> -Matt
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNjK0iAAoJEEfVXEODPFIDaX0IAJ5cY4aGgHgzmasb5tTmi5k2
IxWsq4ZYFM2dUdN4/+5w+LGIWPFp6npyp5GHecxM5lpjJSPXpFETlPzOgZi5XdSh
BMYkXIHwQXRfOSial8iHpIlMViaSVRPme1FbwgbdVYVSvCsVHZosGicyWP61ZBSj
NjTRthDQW+I1DXTqiglgK3zGClp+MbgNcE4JMjHn6QxDkB2zryuHVbio579I9VkR
SN/Ly3pVpKLAu67oAmzPFhpRhcncfb9tEv/I3QprOiAaRwci4Zl6o0vIyHomx0JE
yC+q6v/h62D7eSEyhiDgPi4U0i8R4Z1aAiRm/dFuKpfRI/dtMhIZb6/ceKUJ20k=
=ux2K
-----END PGP SIGNATURE-----