On 3/1/2012 12:11 PM, William A. Rowe Jr. wrote:
A proposal to adopt mod_firehose is attached.
[ ] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
72 hours have passed; the firehose module and utility, as committed, are
accepted as a
On 01.03.2012 19:11, William A. Rowe Jr. wrote:
Let's simply reset this whole mess.
A proposal to adopt mod_firehose is attached.
[X] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
Option 1.
Regards,
Rainer
On 1 Mar 2012, at 18:11, William A. Rowe Jr. wrote:
Let's simply reset this whole mess.
+1 to that!
I think maybe we have some confusion here because attitudes
have evolved over the years, and modules that would once not
have been accepted to trunk are now welcomed there. Maybe
there would
On 1 Mar 2012, at 21:27, William A. Rowe Jr. wrote:
On 3/1/2012 3:02 PM, Greg Stein wrote:
Modules do not have to be tested *before* they appear in trunk. That's
putting the cart before the horse. Part of the development process
(while in trunk) is doing the testing portion. And hey... if it
On 3/2/2012 2:14 AM, Nick Kew wrote:
mod_firehose meets a need. But my +1 has to be conditional on
satisfactory integration of the complementary firehose utility
alongside it, presumably in /bin/ .
That obligation is met. minfrin acknowledges you could do more
than what the firehose
On Mar 1, 2012, at 4:30 PM, Rich Bowen wrote:
I've often thought that modules like, say, mod_ftp, would have a much greater
chance of being successful if they were in trunk rather than it being several
additional steps to obtain.
Yeppers.
On 3/1/2012 12:11 PM, William A. Rowe Jr. wrote:
A proposal to adopt mod_firehose is attached.
[X] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
+1 to adopt as experimental module in trunk. More discussion should
follow about the
Let's simply reset this whole mess.
A proposal to adopt mod_firehose is attached.
[ ] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
[Prior to this vote, option 2 had previously passed with minfrin, issac,
sctemme, jim in support.
On 3/1/2012 12:11 PM, William A. Rowe Jr. wrote:
A proposal to adopt mod_firehose is attached.
[ ] Option 1: adopt as trunk module
[X] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote:
Let's simply reset this whole mess.
A proposal to adopt mod_firehose is attached.
[X] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
On Mar 1, 2012, at 10:11 AM, William A. Rowe Jr. wrote:
Let's simply reset this whole mess.
A proposal to adopt mod_firehose is attached.
[X] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
Dimpled chad: I would support option 2 if
On 3/1/2012 12:40 PM, Sander Temme wrote:
Dimpled chad: I would support option 2 if 1 doesn't have traction.
Yup - that's implicit.
On Mar 1, 2012 1:29 PM, Jim Jagielski j...@jagunet.com wrote:
On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote:
Let's simply reset this whole mess.
A proposal to adopt mod_firehose is attached.
[X] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ]
Seems dangerous to even comment in this flow - but as I am all about
thinking testing at the moment - is there any thought about how to test
this. From a packaging point of view I would expect tooling to be able to
test are included functions. As a user I would expect anything in trunk
(what I
Modules do not have to be tested *before* they appear in trunk. That's
putting the cart before the horse. Part of the development process
(while in trunk) is doing the testing portion. And hey... if it never
gets tested, then it gets marked as experimental and we all move on.
Cheers,
-g
On Thu,
On 3/1/2012 3:02 PM, Greg Stein wrote:
Modules do not have to be tested *before* they appear in trunk. That's
putting the cart before the horse. Part of the development process
(while in trunk) is doing the testing portion. And hey... if it never
gets tested, then it gets marked as
On Mar 1, 2012, at 4:02 PM, Greg Stein wrote:
Modules do not have to be tested *before* they appear in trunk. That's
putting the cart before the horse. Part of the development process
(while in trunk) is doing the testing portion. And hey... if it never
gets tested, then it gets marked as
On Thu, Mar 1, 2012 at 16:30, Rich Bowen rbo...@rcbowen.com wrote:
...
I've often thought that modules like, say, mod_ftp, would have a much
greater chance of being successful if they were in trunk rather than it
being several additional steps to obtain.
I'm +1 to having this in trunk, but am
I learned something tonight :)
On Thu, Mar 1, 2012 at 11:37 PM, Greg Stein gst...@gmail.com wrote:
On Thu, Mar 1, 2012 at 16:30, Rich Bowen rbo...@rcbowen.com wrote:
...
I've often thought that modules like, say, mod_ftp, would have a much
greater chance of being successful if they were in
19 matches
Mail list logo
