You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Sam Ruby <ru...@apache.org> on 2006/07/10 18:33:18 UTC
Rules for Revolutionaries [was: M2]
Jeremy Boynes wrote:
> Ant
>
> I'm disappointed that you have chosen this path. I will ask one more
> time if you and Sebastien would consider collaborating with those of us
> working on core2.
A while ago, I agreed to be a mentor for this project. I guess it is
about time that I start acting like one.
If this project ever hopes to exit incubation, it had better start
acting like an ASF project. For starters, I suggest that all committers
read the Rules for Revolutionaries[1][2][3].
For those who want the Cliff notes version: anybody who wants to work in
an evolutionary fashion on the main trunk is welcome to do so. Anybody
who wants to work on a revolutionary branch is welcome to do so.
Multiple concurrent revolutionary branches are OK too.
One thing that is decidedly NOT OK is to include a version number in the
name, as it causes friction. Hence, I'd suggest that "core2"
immediately get renamed to something that neither reflects the term
"core" or the number "2".
Something implicit in the R4R document is that the burden of proof is on
the revolutionaries. If you would like to see your particular branch
merged back onto the trunk, be prepared to demonstrate why your
particular branch is not merely better, but necessary. My experience it
that the more concrete and the less hand-wavy the argument, the more
likely it will be accepted. So, if you chose to believe that scenarios
and test cases are optional, just remember, merging your sandbox back to
the trunk is optional too. That does not mean that scenarios and test
cases are required, but it does mean that if these aren't present, you
need to come up with something just as compelling.
- Sam Ruby
[1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
[2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
[3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by ant elder <an...@gmail.com>.
I agree with Simon 100%. Its really bad we've let the main trunk lose
momentum, we should all start working on it again. I'll start that tomorrow
and hope others will come and help.
...ant
(and as a sign of good faith and commitment to the main trunk code I've
deleted miral)
On 7/12/06, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Thanks, Sam; this is very helpful. One part in particular of the
> James Duncan Davidson post caught my eye:
>
> <jdd>
> 4) The trunk is the official versioned line of the project. All
> evolutionary minded people are welcome to work on it to improve it.
> Evolutionary work is important and should not stop as it is always
> unclear when any particular revolution will be ready for prime time
> or whether it will be officially accepted.
> </jdd>
>
> I think we have failed to follow this guideline over recent weeks.
> People have submitted patches for the trunk and they have not been
> applied (or applied to a sandbox instead). Technical discussions
> have started that in the normal course of events would have led to
> commits and patches, but these commits and patches have not been
> forthcoming. This has generally led to progress on the project
> (except for sandbox activity) being stalled, presumably because
> people were waiting to see what would happen with the sandbox code.
>
> I believe we need to get the project moving forward again. At the
> present time, we have an evolutionary trunk and a revolutionary
> sandbox. We should therefore continue (in reality restart) doing
> evolutionary work on the trunk for the reasons that JDD gives in
> the quote above. There is evolutionary work that can usefully
> be done, such as Raymond's work on databindings, the work on
> interface represenation that Ant and others have been discussing,
> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
> there are other things too. If at some point there is a revolution,
> then we will deal with it when it happens and rework existing code
> as necessary.
>
> Revolutionaries can work in the "chianti" sandbox, or if they
> prefer a different brand of revolution, they can create another
> sandbox to do this. The latter is perfectly legitimate according
> to the Rules for Revolutionaries, and I think it is healthy for
> the project for people to be able to show their new ideas in the
> form of code, as long as the project as a whole (i.e., the whole
> community) keeps moving forward with ongoing work on the trunk
> and doesn't focus exclusively on what is happening in the
> sandboxes.
>
> Simon
>
> Sam Ruby wrote:
>
> > Jeremy Boynes wrote:
> >
> >> Ant
> >>
> >> I'm disappointed that you have chosen this path. I will ask one more
> >> time if you and Sebastien would consider collaborating with those of
> >> us working on core2.
> >
> >
> > A while ago, I agreed to be a mentor for this project. I guess it is
> > about time that I start acting like one.
> >
> > If this project ever hopes to exit incubation, it had better start
> > acting like an ASF project. For starters, I suggest that all committers
> > read the Rules for Revolutionaries[1][2][3].
> >
> > For those who want the Cliff notes version: anybody who wants to work in
> > an evolutionary fashion on the main trunk is welcome to do so. Anybody
> > who wants to work on a revolutionary branch is welcome to do so.
> > Multiple concurrent revolutionary branches are OK too.
> >
> > One thing that is decidedly NOT OK is to include a version number in the
> > name, as it causes friction. Hence, I'd suggest that "core2"
> > immediately get renamed to something that neither reflects the term
> > "core" or the number "2".
> >
> > Something implicit in the R4R document is that the burden of proof is on
> > the revolutionaries. If you would like to see your particular branch
> > merged back onto the trunk, be prepared to demonstrate why your
> > particular branch is not merely better, but necessary. My experience it
> > that the more concrete and the less hand-wavy the argument, the more
> > likely it will be accepted. So, if you chose to believe that scenarios
> > and test cases are optional, just remember, merging your sandbox back to
> > the trunk is optional too. That does not mean that scenarios and test
> > cases are required, but it does mean that if these aren't present, you
> > need to come up with something just as compelling.
> >
> > - Sam Ruby
> >
> > [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
> > [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
> > [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
>
> --
> Simon C Nash IBM Distinguished Engineer
> Hursley Park, Winchester, UK nash@hursley.ibm.com
> Tel. +44-1962-815156 Fax +44-1962-818999
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Bigbank application, was Rules for Revolutionaries
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Rick wrote:
> If there are no issues I'd like to look at the bigbank sample
> converting to the new composite spec. Besides the obvious need to
> change the SCDL, I suppose refactoring the server (account) side to
> take advantage of the composite nature maybe see if includes can be
> used too. Was there immediately more that you were thinking of ?
>
> Jean-Sebastien Delfino wrote:
>> Simon Nash wrote:
>>> Thanks, Sam; this is very helpful. One part in particular of the
>>> James Duncan Davidson post caught my eye:
>>>
>>> <jdd>
>>> 4) The trunk is the official versioned line of the project. All
>>> evolutionary minded people are welcome to work on it to improve it.
>>> Evolutionary work is important and should not stop as it is always
>>> unclear when any particular revolution will be ready for prime time
>>> or whether it will be officially accepted.
>>> </jdd>
>>>
>>> I think we have failed to follow this guideline over recent weeks.
>>> People have submitted patches for the trunk and they have not been
>>> applied (or applied to a sandbox instead). Technical discussions
>>> have started that in the normal course of events would have led to
>>> commits and patches, but these commits and patches have not been
>>> forthcoming. This has generally led to progress on the project
>>> (except for sandbox activity) being stalled, presumably because
>>> people were waiting to see what would happen with the sandbox code.
>>>
>>> I believe we need to get the project moving forward again. At the
>>> present time, we have an evolutionary trunk and a revolutionary
>>> sandbox. We should therefore continue (in reality restart) doing
>>> evolutionary work on the trunk for the reasons that JDD gives in
>>> the quote above. There is evolutionary work that can usefully
>>> be done, such as Raymond's work on databindings, the work on
>>> interface represenation that Ant and others have been discussing,
>>> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
>>> there are other things too. If at some point there is a revolution,
>>> then we will deal with it when it happens and rework existing code
>>> as necessary.
>>>
>>> Revolutionaries can work in the "chianti" sandbox, or if they
>>> prefer a different brand of revolution, they can create another
>>> sandbox to do this. The latter is perfectly legitimate according
>>> to the Rules for Revolutionaries, and I think it is healthy for
>>> the project for people to be able to show their new ideas in the
>>> form of code, as long as the project as a whole (i.e., the whole
>>> community) keeps moving forward with ongoing work on the trunk
>>> and doesn't focus exclusively on what is happening in the
>>> sandboxes.
>>>
>>> Simon
>>>
>>> Sam Ruby wrote:
>>>
>>>> Jeremy Boynes wrote:
>>>>
>>>>> Ant
>>>>>
>>>>> I'm disappointed that you have chosen this path. I will ask one
>>>>> more time if you and Sebastien would consider collaborating with
>>>>> those of us working on core2.
>>>>
>>>>
>>>> A while ago, I agreed to be a mentor for this project. I guess it
>>>> is about time that I start acting like one.
>>>>
>>>> If this project ever hopes to exit incubation, it had better start
>>>> acting like an ASF project. For starters, I suggest that all
>>>> committers read the Rules for Revolutionaries[1][2][3].
>>>>
>>>> For those who want the Cliff notes version: anybody who wants to
>>>> work in an evolutionary fashion on the main trunk is welcome to do
>>>> so. Anybody who wants to work on a revolutionary branch is welcome
>>>> to do so. Multiple concurrent revolutionary branches are OK too.
>>>>
>>>> One thing that is decidedly NOT OK is to include a version number
>>>> in the name, as it causes friction. Hence, I'd suggest that
>>>> "core2" immediately get renamed to something that neither reflects
>>>> the term "core" or the number "2".
>>>>
>>>> Something implicit in the R4R document is that the burden of proof
>>>> is on the revolutionaries. If you would like to see your
>>>> particular branch merged back onto the trunk, be prepared to
>>>> demonstrate why your particular branch is not merely better, but
>>>> necessary. My experience it that the more concrete and the less
>>>> hand-wavy the argument, the more likely it will be accepted. So,
>>>> if you chose to believe that scenarios and test cases are optional,
>>>> just remember, merging your sandbox back to the trunk is optional
>>>> too. That does not mean that scenarios and test cases are
>>>> required, but it does mean that if these aren't present, you need
>>>> to come up with something just as compelling.
>>>>
>>>> - Sam Ruby
>>>>
>>>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>>>> [3]
>>>> http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>> Simon,
>>
>> I agree. I'm going to do some work on the samples in the trunk, I'd
>> like to evolve some of them (starting with the Calculator sample and
>> then Bigbank) to start showing some of the concepts in the evolving
>> SCA specification.
>>
>> In addition, I searched through our JIRA backlog and found the
>> following patches, which should be reviewed and potentially applied
>> to the trunk:
>> TUSCANY-120 - Java2WSDL patches to generate correct XSDs
>> TUSCANY-454 - Fixes WSDLs in some of the samples
>> TUSCANY-457 - Fixes an NPE in TuscanyContextListener
>> TUSCANY-477 - Improve unresolved type error handling
>> TUSCANY-520 - Fixes build to handle folder names containing spaces
>> TUSCANY-535 - Implements XSDHelper.generate()
>>
>> I'm going to start by looking at TUSCANY-120.
>>
>> I may have missed some patches (I wished JIRA had a query listing all
>> issues with pending patches...) so could people waiting for their
>> patches to be reviewed and applied please speak up and point us to
>> the JIRA issue numbers? Thanks.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Rick,
Sounds like a good plan, we could port the SCDL first and adjust to the
new APIs (for example ModuleContext becomes CompositeContext). After
this first pass, I suggest to write a Composite around the bigbank
moduleComponents (equivalent to an SCA 0.9 subsystem), and maybe also
use composite includes and/or nested composite implementations inside
the account composite.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by Rick <cr...@gmail.com>.
If there are no issues I'd like to look at the bigbank sample converting
to the new composite spec. Besides the obvious need to change the
SCDL, I suppose refactoring the server (account) side to take advantage
of the composite nature maybe see if includes can be used too. Was
there immediately more that you were thinking of ?
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>> Thanks, Sam; this is very helpful. One part in particular of the
>> James Duncan Davidson post caught my eye:
>>
>> <jdd>
>> 4) The trunk is the official versioned line of the project. All
>> evolutionary minded people are welcome to work on it to improve it.
>> Evolutionary work is important and should not stop as it is always
>> unclear when any particular revolution will be ready for prime time
>> or whether it will be officially accepted.
>> </jdd>
>>
>> I think we have failed to follow this guideline over recent weeks.
>> People have submitted patches for the trunk and they have not been
>> applied (or applied to a sandbox instead). Technical discussions
>> have started that in the normal course of events would have led to
>> commits and patches, but these commits and patches have not been
>> forthcoming. This has generally led to progress on the project
>> (except for sandbox activity) being stalled, presumably because
>> people were waiting to see what would happen with the sandbox code.
>>
>> I believe we need to get the project moving forward again. At the
>> present time, we have an evolutionary trunk and a revolutionary
>> sandbox. We should therefore continue (in reality restart) doing
>> evolutionary work on the trunk for the reasons that JDD gives in
>> the quote above. There is evolutionary work that can usefully
>> be done, such as Raymond's work on databindings, the work on
>> interface represenation that Ant and others have been discussing,
>> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
>> there are other things too. If at some point there is a revolution,
>> then we will deal with it when it happens and rework existing code
>> as necessary.
>>
>> Revolutionaries can work in the "chianti" sandbox, or if they
>> prefer a different brand of revolution, they can create another
>> sandbox to do this. The latter is perfectly legitimate according
>> to the Rules for Revolutionaries, and I think it is healthy for
>> the project for people to be able to show their new ideas in the
>> form of code, as long as the project as a whole (i.e., the whole
>> community) keeps moving forward with ongoing work on the trunk
>> and doesn't focus exclusively on what is happening in the
>> sandboxes.
>>
>> Simon
>>
>> Sam Ruby wrote:
>>
>>> Jeremy Boynes wrote:
>>>
>>>> Ant
>>>>
>>>> I'm disappointed that you have chosen this path. I will ask one
>>>> more time if you and Sebastien would consider collaborating with
>>>> those of us working on core2.
>>>
>>>
>>> A while ago, I agreed to be a mentor for this project. I guess it
>>> is about time that I start acting like one.
>>>
>>> If this project ever hopes to exit incubation, it had better start
>>> acting like an ASF project. For starters, I suggest that all
>>> committers read the Rules for Revolutionaries[1][2][3].
>>>
>>> For those who want the Cliff notes version: anybody who wants to
>>> work in an evolutionary fashion on the main trunk is welcome to do
>>> so. Anybody who wants to work on a revolutionary branch is welcome
>>> to do so. Multiple concurrent revolutionary branches are OK too.
>>>
>>> One thing that is decidedly NOT OK is to include a version number in
>>> the name, as it causes friction. Hence, I'd suggest that "core2"
>>> immediately get renamed to something that neither reflects the term
>>> "core" or the number "2".
>>>
>>> Something implicit in the R4R document is that the burden of proof
>>> is on the revolutionaries. If you would like to see your particular
>>> branch merged back onto the trunk, be prepared to demonstrate why
>>> your particular branch is not merely better, but necessary. My
>>> experience it that the more concrete and the less hand-wavy the
>>> argument, the more likely it will be accepted. So, if you chose to
>>> believe that scenarios and test cases are optional, just remember,
>>> merging your sandbox back to the trunk is optional too. That does
>>> not mean that scenarios and test cases are required, but it does
>>> mean that if these aren't present, you need to come up with
>>> something just as compelling.
>>>
>>> - Sam Ruby
>>>
>>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>>> [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>>
>>
> Simon,
>
> I agree. I'm going to do some work on the samples in the trunk, I'd
> like to evolve some of them (starting with the Calculator sample and
> then Bigbank) to start showing some of the concepts in the evolving
> SCA specification.
>
> In addition, I searched through our JIRA backlog and found the
> following patches, which should be reviewed and potentially applied to
> the trunk:
> TUSCANY-120 - Java2WSDL patches to generate correct XSDs
> TUSCANY-454 - Fixes WSDLs in some of the samples
> TUSCANY-457 - Fixes an NPE in TuscanyContextListener
> TUSCANY-477 - Improve unresolved type error handling
> TUSCANY-520 - Fixes build to handle folder names containing spaces
> TUSCANY-535 - Implements XSDHelper.generate()
>
> I'm going to start by looking at TUSCANY-120.
>
> I may have missed some patches (I wished JIRA had a query listing all
> issues with pending patches...) so could people waiting for their
> patches to be reviewed and applied please speak up and point us to the
> JIRA issue numbers? Thanks.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Calculator sample
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 12, 2006, at 3:07 PM, Jean-Sebastien Delfino wrote:
>
> I agree. I'm going to do some work on the samples in the trunk, I'd
> like to evolve some of them (starting with the Calculator sample
> and then Bigbank) to start showing some of the concepts in the
> evolving SCA specification.
If it helps, I ported the calculator sample to chianti.
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/chianti/
sca/samples/calculator
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> Thanks, Sam; this is very helpful. One part in particular of the
> James Duncan Davidson post caught my eye:
>
> <jdd>
> 4) The trunk is the official versioned line of the project. All
> evolutionary minded people are welcome to work on it to improve it.
> Evolutionary work is important and should not stop as it is always
> unclear when any particular revolution will be ready for prime time
> or whether it will be officially accepted.
> </jdd>
>
> I think we have failed to follow this guideline over recent weeks.
> People have submitted patches for the trunk and they have not been
> applied (or applied to a sandbox instead). Technical discussions
> have started that in the normal course of events would have led to
> commits and patches, but these commits and patches have not been
> forthcoming. This has generally led to progress on the project
> (except for sandbox activity) being stalled, presumably because
> people were waiting to see what would happen with the sandbox code.
>
> I believe we need to get the project moving forward again. At the
> present time, we have an evolutionary trunk and a revolutionary
> sandbox. We should therefore continue (in reality restart) doing
> evolutionary work on the trunk for the reasons that JDD gives in
> the quote above. There is evolutionary work that can usefully
> be done, such as Raymond's work on databindings, the work on
> interface represenation that Ant and others have been discussing,
> Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
> there are other things too. If at some point there is a revolution,
> then we will deal with it when it happens and rework existing code
> as necessary.
>
> Revolutionaries can work in the "chianti" sandbox, or if they
> prefer a different brand of revolution, they can create another
> sandbox to do this. The latter is perfectly legitimate according
> to the Rules for Revolutionaries, and I think it is healthy for
> the project for people to be able to show their new ideas in the
> form of code, as long as the project as a whole (i.e., the whole
> community) keeps moving forward with ongoing work on the trunk
> and doesn't focus exclusively on what is happening in the
> sandboxes.
>
> Simon
>
> Sam Ruby wrote:
>
>> Jeremy Boynes wrote:
>>
>>> Ant
>>>
>>> I'm disappointed that you have chosen this path. I will ask one more
>>> time if you and Sebastien would consider collaborating with those of
>>> us working on core2.
>>
>>
>> A while ago, I agreed to be a mentor for this project. I guess it is
>> about time that I start acting like one.
>>
>> If this project ever hopes to exit incubation, it had better start
>> acting like an ASF project. For starters, I suggest that all
>> committers read the Rules for Revolutionaries[1][2][3].
>>
>> For those who want the Cliff notes version: anybody who wants to work
>> in an evolutionary fashion on the main trunk is welcome to do so.
>> Anybody who wants to work on a revolutionary branch is welcome to do
>> so. Multiple concurrent revolutionary branches are OK too.
>>
>> One thing that is decidedly NOT OK is to include a version number in
>> the name, as it causes friction. Hence, I'd suggest that "core2"
>> immediately get renamed to something that neither reflects the term
>> "core" or the number "2".
>>
>> Something implicit in the R4R document is that the burden of proof is
>> on the revolutionaries. If you would like to see your particular
>> branch merged back onto the trunk, be prepared to demonstrate why
>> your particular branch is not merely better, but necessary. My
>> experience it that the more concrete and the less hand-wavy the
>> argument, the more likely it will be accepted. So, if you chose to
>> believe that scenarios and test cases are optional, just remember,
>> merging your sandbox back to the trunk is optional too. That does
>> not mean that scenarios and test cases are required, but it does mean
>> that if these aren't present, you need to come up with something just
>> as compelling.
>>
>> - Sam Ruby
>>
>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>> [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>>
>
Simon,
I agree. I'm going to do some work on the samples in the trunk, I'd like
to evolve some of them (starting with the Calculator sample and then
Bigbank) to start showing some of the concepts in the evolving SCA
specification.
In addition, I searched through our JIRA backlog and found the following
patches, which should be reviewed and potentially applied to the trunk:
TUSCANY-120 - Java2WSDL patches to generate correct XSDs
TUSCANY-454 - Fixes WSDLs in some of the samples
TUSCANY-457 - Fixes an NPE in TuscanyContextListener
TUSCANY-477 - Improve unresolved type error handling
TUSCANY-520 - Fixes build to handle folder names containing spaces
TUSCANY-535 - Implements XSDHelper.generate()
I'm going to start by looking at TUSCANY-120.
I may have missed some patches (I wished JIRA had a query listing all
issues with pending patches...) so could people waiting for their
patches to be reviewed and applied please speak up and point us to the
JIRA issue numbers? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for Revolutionaries [was: M2]
Posted by Simon Nash <na...@hursley.ibm.com>.
Thanks, Sam; this is very helpful. One part in particular of the
James Duncan Davidson post caught my eye:
<jdd>
4) The trunk is the official versioned line of the project. All
evolutionary minded people are welcome to work on it to improve it.
Evolutionary work is important and should not stop as it is always
unclear when any particular revolution will be ready for prime time
or whether it will be officially accepted.
</jdd>
I think we have failed to follow this guideline over recent weeks.
People have submitted patches for the trunk and they have not been
applied (or applied to a sandbox instead). Technical discussions
have started that in the normal course of events would have led to
commits and patches, but these commits and patches have not been
forthcoming. This has generally led to progress on the project
(except for sandbox activity) being stalled, presumably because
people were waiting to see what would happen with the sandbox code.
I believe we need to get the project moving forward again. At the
present time, we have an evolutionary trunk and a revolutionary
sandbox. We should therefore continue (in reality restart) doing
evolutionary work on the trunk for the reasons that JDD gives in
the quote above. There is evolutionary work that can usefully
be done, such as Raymond's work on databindings, the work on
interface represenation that Ant and others have been discussing,
Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure
there are other things too. If at some point there is a revolution,
then we will deal with it when it happens and rework existing code
as necessary.
Revolutionaries can work in the "chianti" sandbox, or if they
prefer a different brand of revolution, they can create another
sandbox to do this. The latter is perfectly legitimate according
to the Rules for Revolutionaries, and I think it is healthy for
the project for people to be able to show their new ideas in the
form of code, as long as the project as a whole (i.e., the whole
community) keeps moving forward with ongoing work on the trunk
and doesn't focus exclusively on what is happening in the
sandboxes.
Simon
Sam Ruby wrote:
> Jeremy Boynes wrote:
>
>> Ant
>>
>> I'm disappointed that you have chosen this path. I will ask one more
>> time if you and Sebastien would consider collaborating with those of
>> us working on core2.
>
>
> A while ago, I agreed to be a mentor for this project. I guess it is
> about time that I start acting like one.
>
> If this project ever hopes to exit incubation, it had better start
> acting like an ASF project. For starters, I suggest that all committers
> read the Rules for Revolutionaries[1][2][3].
>
> For those who want the Cliff notes version: anybody who wants to work in
> an evolutionary fashion on the main trunk is welcome to do so. Anybody
> who wants to work on a revolutionary branch is welcome to do so.
> Multiple concurrent revolutionary branches are OK too.
>
> One thing that is decidedly NOT OK is to include a version number in the
> name, as it causes friction. Hence, I'd suggest that "core2"
> immediately get renamed to something that neither reflects the term
> "core" or the number "2".
>
> Something implicit in the R4R document is that the burden of proof is on
> the revolutionaries. If you would like to see your particular branch
> merged back onto the trunk, be prepared to demonstrate why your
> particular branch is not merely better, but necessary. My experience it
> that the more concrete and the less hand-wavy the argument, the more
> likely it will be accepted. So, if you chose to believe that scenarios
> and test cases are optional, just remember, merging your sandbox back to
> the trunk is optional too. That does not mean that scenarios and test
> cases are required, but it does mean that if these aren't present, you
> need to come up with something just as compelling.
>
> - Sam Ruby
>
> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
> [3] http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Chianti, was: Rules for Revolutionaries [was: M2]
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 11, 2006, at 2:27 PM, Jeremy Boynes wrote:
> On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote:
>>
>> One thing that is decidedly NOT OK is to include a version number
>> in the name, as it causes friction. Hence, I'd suggest that
>> "core2" immediately get renamed to something that neither reflects
>> the term "core" or the number "2".
>>
>
> To resolve this I propose that we move the code from my sandbox to
> its own location based on a codename. Once I get the build issues
> resolved, I plan to move the tree from "sandbox/jboynes" to
> "sandbox/chianti" and will rename the "core2" module back to "core"
This should now be complete - if you cd to sandbox and "svn up
chianti" you should get a buildable tree.
I changed the artifact versions to "1.0-chianti-SNAPSHOT" - the "1.0"
is only there to keep maven happy by starting the version with a number.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Chianti, was: Rules for Revolutionaries [was: M2]
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote:
>
> One thing that is decidedly NOT OK is to include a version number
> in the name, as it causes friction. Hence, I'd suggest that
> "core2" immediately get renamed to something that neither reflects
> the term "core" or the number "2".
>
To resolve this I propose that we move the code from my sandbox to
its own location based on a codename. Once I get the build issues
resolved, I plan to move the tree from "sandbox/jboynes" to "sandbox/
chianti" and will rename the "core2" module back to "core"
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org