You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@vafer.org> on 2004/03/31 14:59:43 UTC
[VOTE RESULT] javaflow
ok... more than 24h...
here are the results.
Leave it where it is:
Bertrand
Gianugo
Ugo
Torsten
Marc
Sylvain
Michael
Chris
Tim
Vadim
Move it into scratchpad:
Carsten
Reinhard
Antonio
Rename it to jflow:
Joerg
Everything correct?
Any other votes?
--
Torsten
Re: [VOTE RESULT] javaflow
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Pötz dijo:
> Torsten Curdt wrote:
>
>>> ok... more than 24h...
>>> here are the results.
>>>
>>> Leave it where it is:
>>> Bertrand
>>> Gianugo
>>> Ugo
>>> Torsten
>>> Marc
>>> Sylvain
>>> Michael
>>> Chris
>>> Tim
>>> Vadim
>>>
>>> Move it into scratchpad:
>>> Carsten
>>> Reinhard
>>> Antonio
>>>
>>> Rename it to jflow:
>>> Joerg
>>>
>>> Everything correct?
>>> Any other votes?
>>
>>
>> Noone answers, the vote result is
>> pretty much clear ...so I asume it's
>> ok to leave it where it is.
>>
>> Is that (more or less) ok for everyone?
>> Carsten, Reinhard, Antonio, Joerg?
>
>
> no problem, it's okay.
> I would like to see the Javaflow as part of Cocoon 2.1 core when we
> believe it is stable. And in 2.2(3.0) I would prefer having modules for
> the different flow implementations and the environments.
Same feeling here.
Best Regards,
Antonio Gallardo.
Re: [VOTE RESULT] javaflow
Posted by Reinhard Pötz <re...@apache.org>.
Torsten Curdt wrote:
>> ok... more than 24h...
>> here are the results.
>>
>> Leave it where it is:
>> Bertrand
>> Gianugo
>> Ugo
>> Torsten
>> Marc
>> Sylvain
>> Michael
>> Chris
>> Tim
>> Vadim
>>
>> Move it into scratchpad:
>> Carsten
>> Reinhard
>> Antonio
>>
>> Rename it to jflow:
>> Joerg
>>
>> Everything correct?
>> Any other votes?
>
>
> Noone answers, the vote result is
> pretty much clear ...so I asume it's
> ok to leave it where it is.
>
> Is that (more or less) ok for everyone?
> Carsten, Reinhard, Antonio, Joerg?
no problem, it's okay.
I would like to see the Javaflow as part of Cocoon 2.1 core when we
believe it is stable. And in 2.2(3.0) I would prefer having modules for
the different flow implementations and the environments.
--
Reinhard
Re: [VOTE RESULT] javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
Reinhard Pötz wrote:
> Carsten Ziegeler wrote:
>
>> Ok, we guess we can continue this discussion forever :)
I like discussion :)
>> I would say, do what you think is better, we will see what
>> happens.
And this is not one of the April's fools day jokes? ;)
I'd leave it as it is and add it to the release
instructions :) ...and if noone stops me I will
do it right now!
> Carsten, I like your pragmatic approaches ;-)
That's my pragmatic approach ;)
...but we can change anytime you want
cheers
--
Torsten
RE: [VOTE RESULT] javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Pötz [mailto:reinhard@apache.org]
>
> Carsten Ziegeler wrote:
>
> >Ok, we guess we can continue this discussion forever :) I
> would say, do
> >what you think is better, we will see what happens.
> >
> >
>
> +1
> Carsten, I like your pragmatic approaches ;-)
>
Thanks :) I know today is first-of-april...(just kidding).
Carsten
Re: [VOTE RESULT] javaflow
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
>Ok, we guess we can continue this discussion forever :)
>I would say, do what you think is better, we will see what
>happens.
>
>
+1
Carsten, I like your pragmatic approaches ;-)
Best,
Reinhard
>>-----Original Message-----
>>From: Reinhard Pötz [mailto:reinhard@apache.org]
>>Sent: Thursday, April 01, 2004 12:53 PM
>>To: dev@cocoon.apache.org
>>Subject: Re: [VOTE RESULT] javaflow
>>
>>Torsten Curdt wrote:
>>
>>
>>
>>>>>but then I'd propose to disable *all* unstable blocks
>>>>>
>>>>>
>>>>>
>>>>Oh no, please not because this will lead to everyone wanting to
>>>>declare his favorite block "stable" :)
>>>>
>>>>
>>>don't wanna bitch around but... if you want prevent users to use
>>>unstable code (or at least make them aware of the fact) we should
>>>handle blocks all the same.
>>>
>>>and as you see with the midi block
>>>...if we can consider it stable it'll
>>>become marked stable. no big deal.
>>>
>>>
>>I think so too. Either all unstable blocks are disabled or noone.
>>
>>
>>
>>>I don't think "stable" has anything to do with preference
>>>
>>>
>>but instead
>>
>>
>>>how it has proven to be stable in production over time.
>>>
>>>
>>... and IMO there must be more than one person willing to support it.
>>(of course no guarantee that it will be supported forever but
>>it increases the chances)
>>
>>--
>>Reinhard
>>
>>
RE: [VOTE RESULT] javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, we guess we can continue this discussion forever :)
I would say, do what you think is better, we will see what
happens.
Carsten
> -----Original Message-----
> From: Reinhard Pötz [mailto:reinhard@apache.org]
> Sent: Thursday, April 01, 2004 12:53 PM
> To: dev@cocoon.apache.org
> Subject: Re: [VOTE RESULT] javaflow
>
> Torsten Curdt wrote:
>
> >>> but then I'd propose to disable *all* unstable blocks
> >>>
> >>
> >> Oh no, please not because this will lead to everyone wanting to
> >> declare his favorite block "stable" :)
> >
> >
> > don't wanna bitch around but... if you want prevent users to use
> > unstable code (or at least make them aware of the fact) we should
> > handle blocks all the same.
> >
> > and as you see with the midi block
> > ...if we can consider it stable it'll
> > become marked stable. no big deal.
>
>
> I think so too. Either all unstable blocks are disabled or noone.
>
> >
> > I don't think "stable" has anything to do with preference
> but instead
> > how it has proven to be stable in production over time.
>
>
> ... and IMO there must be more than one person willing to support it.
> (of course no guarantee that it will be supported forever but
> it increases the chances)
>
> --
> Reinhard
>
Re: [VOTE RESULT] javaflow
Posted by Reinhard Pötz <re...@apache.org>.
Torsten Curdt wrote:
>>> but then I'd propose to disable *all* unstable blocks
>>>
>>
>> Oh no, please not because this will lead to everyone wanting to
>> declare his
>> favorite block "stable" :)
>
>
> don't wanna bitch around but... if you
> want prevent users to use unstable code
> (or at least make them aware of the fact)
> we should handle blocks all the same.
>
> and as you see with the midi block
> ...if we can consider it stable it'll
> become marked stable. no big deal.
I think so too. Either all unstable blocks are disabled or noone.
>
> I don't think "stable" has anything to
> do with preference but instead how it
> has proven to be stable in production
> over time.
... and IMO there must be more than one person willing to support it.
(of course no guarantee that it will be supported forever but it
increases the chances)
--
Reinhard
Re: [VOTE RESULT] javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
>>but then I'd propose to disable *all* unstable blocks
>>
>
> Oh no, please not because this will lead to everyone wanting to declare his
> favorite block "stable" :)
don't wanna bitch around but... if you
want prevent users to use unstable code
(or at least make them aware of the fact)
we should handle blocks all the same.
and as you see with the midi block
...if we can consider it stable it'll
become marked stable. no big deal.
I don't think "stable" has anything to
do with preference but instead how it
has proven to be stable in production
over time.
WDYT
--
Torsten
RE: [VOTE RESULT] javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
> >
> > Rule No.1 in OS projects: NEVER TRUST THE RELEASE MANAGER!
>
> hehe ...you wanna shirk the responsibility ;) but I trust you
> anyway :)
>
Hey, it was worth a try :) Thanks!
> >>that he will not forget
> >>to change it when it is on his todo list for the release ;-) But I
> >>have absolutely no problem with disabling in dev by default.
> >>
> >>...I known about it and have my local blocks properties
> file anyway ;)
> >>
> >
> > Actually it's not that big deal, we should either disable it now,
>
> but then I'd propose to disable *all* unstable blocks
>
Oh no, please not because this will lead to everyone wanting to declare his
favorite block "stable" :)
> > or add the instruction to disable the block to the wiki
> (the release
> > process description), so the release manager can't forget it :)
>
> as you like :)
>
Let's just disable the java flow block in the CVS - we all use our
own properties file anyway.
Carsten
Re: [VOTE RESULT] javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
>>Well, I personally think if someone is using our HEAD branch
>>and is missing which blocks are stable and which are not
>>...well, he should better go for the releases.
>>
>>And I also trust our release manager
>
> Rule No.1 in OS projects: NEVER TRUST THE RELEASE MANAGER!
hehe ...you wanna shirk the responsibility ;)
but I trust you anyway :)
>>that he will not forget
>>to change it when it is on his todo list for the release ;-)
>>But I have absolutely no problem with disabling in dev by default.
>>
>>...I known about it and have my local blocks properties file anyway ;)
>>
>
> Actually it's not that big deal, we should either disable it now,
but then I'd propose to disable *all* unstable blocks
> or add the instruction to disable the block to the wiki (the release
> process description), so the release manager can't forget it :)
as you like :)
cheers
--
Torsten
RE: [VOTE RESULT] javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> Well, I personally think if someone is using our HEAD branch
> and is missing which blocks are stable and which are not
> ...well, he should better go for the releases.
>
> And I also trust our release manager
Rule No.1 in OS projects: NEVER TRUST THE RELEASE MANAGER!
> that he will not forget
> to change it when it is on his todo list for the release ;-)
> But I have absolutely no problem with disabling in dev by default.
>
> ...I known about it and have my local blocks properties file anyway ;)
>
Actually it's not that big deal, we should either disable it now,
or add the instruction to disable the block to the wiki (the release
process description), so the release manager can't forget it :)
Carsten
Re: [VOTE RESULT] javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
>>>> Is the block disabled by default?
>>>>
>>>
>>> no not yet ...would you prefer this
>>> also for the dev version or only for
>>> the release?
>>>
>>
>>
>> I personally would prefer to disable it already for
>> the dev version as many users are trying out Cocoon
>> from the CVS and then only use later on a released
>> version as a reference.
>> And it definitly makes releasing Cocoon easier. I think
>> it's very easy to forget to disable the block during
>> the release process.
>>
>> But I also guess, I'm again the only one with this
>> opinion :(
>>
>> Carsten
>>
>>
> no. +1 from me ;-)
Well, I personally think if someone is using our
HEAD branch and is missing which blocks are stable
and which are not ...well, he should better go for
the releases.
And I also trust our release manager that he will
not forget to change it when it is on his todo
list for the release ;-) But I have absolutely no
problem with disabling in dev by default.
...I known about it and have my local blocks
properties file anyway ;)
cheers
--
Torsten
Re: [VOTE RESULT] javaflow
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
>
>Torsten Curdt wrote:
>
>
>>>Is the block disabled by default?
>>>
>>>
>>no not yet ...would you prefer this
>>also for the dev version or only for
>>the release?
>>
>>
>
>I personally would prefer to disable it already for
>the dev version as many users are trying out Cocoon
>from the CVS and then only use later on a released
>version as a reference.
>And it definitly makes releasing Cocoon easier. I think
>it's very easy to forget to disable the block during
>the release process.
>
>But I also guess, I'm again the only one with this
>opinion :(
>
>Carsten
>
>
no. +1 from me ;-)
--
Reinhard
RE: [VOTE RESULT] javaflow
Posted by Stephan Michels <st...@apache.org>.
Am Do, den 01.04.2004 schrieb Carsten Ziegeler um 9:02:
> Torsten Curdt wrote:
> > > Is the block disabled by default?
> >
> > no not yet ...would you prefer this
> > also for the dev version or only for
> > the release?
>
> I personally would prefer to disable it already for
> the dev version as many users are trying out Cocoon
> from the CVS and then only use later on a released
> version as a reference.
> And it definitly makes releasing Cocoon easier. I think
> it's very easy to forget to disable the block during
> the release process.
No problem with it from my side. Go ahead.
Stephan.
RE: [VOTE RESULT] javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
> > Is the block disabled by default?
>
> no not yet ...would you prefer this
> also for the dev version or only for
> the release?
I personally would prefer to disable it already for
the dev version as many users are trying out Cocoon
from the CVS and then only use later on a released
version as a reference.
And it definitly makes releasing Cocoon easier. I think
it's very easy to forget to disable the block during
the release process.
But I also guess, I'm again the only one with this
opinion :(
Carsten
Re: [VOTE RESULT] javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
Carsten Ziegeler wrote:
> Torsten Curdt wrote:
>
>>Noone answers, the vote result is
>>pretty much clear ...so I asume it's
>>ok to leave it where it is.
>>
>>Is that (more or less) ok for everyone?
>>Carsten, Reinhard, Antonio, Joerg?
>>
>
> Sure, that was the deal :(
>
> Is the block disabled by default?
no not yet ...would you prefer this
also for the dev version or only for
the release?
--
Torsten
RE: [VOTE RESULT] javaflow
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Torsten Curdt wrote:
>
> Noone answers, the vote result is
> pretty much clear ...so I asume it's
> ok to leave it where it is.
>
> Is that (more or less) ok for everyone?
> Carsten, Reinhard, Antonio, Joerg?
>
Sure, that was the deal :(
Is the block disabled by default?
Carsten
Re: [VOTE RESULT] javaflow
Posted by Torsten Curdt <tc...@vafer.org>.
> ok... more than 24h...
> here are the results.
>
> Leave it where it is:
> Bertrand
> Gianugo
> Ugo
> Torsten
> Marc
> Sylvain
> Michael
> Chris
> Tim
> Vadim
>
> Move it into scratchpad:
> Carsten
> Reinhard
> Antonio
>
> Rename it to jflow:
> Joerg
>
> Everything correct?
> Any other votes?
Noone answers, the vote result is
pretty much clear ...so I asume it's
ok to leave it where it is.
Is that (more or less) ok for everyone?
Carsten, Reinhard, Antonio, Joerg?
cheers
--
Torsten