On Thursday 27 March 2003 21:48, Jeff Turner wrote:
> No.. not more voting! ;)
Can't voting be better automated, instead of a lot of +1 emails, that are hard
to count (does anyone ever count?).
Niclas
Le Jeudi, 27 mars 2003, à 15:17 Europe/Zurich, Pier Fumagalli a écrit :
...
+1 :-) Should I open the repo?
+1.
As I understand there are no risks associated with this, just need
indicate in the announcement that commits to this will affect
cocoon-2.1 too, so voting is probably not required for
On Thu, Mar 27, 2003 at 02:16:02PM +0100, Bertrand Delacretaz wrote:
> Le Jeudi, 27 mars 2003, à 13:52 Europe/Zurich, Diana Shannon a écrit :
>
> >...
> >I think a discussion intermixed with a vote changes the vote so that
> >people end up voting on different issues -- with no clear cut result.
>
On Thursday, March 27, 2003, at 08:16 AM, Bertrand Delacretaz wrote:
Agreed - in this particular case, the best thing might be to cancel the
current vote and make a new proposal (taking into account the
"cocoon-docs alias" stuff)?
Wasn't Pier going to experiment with this approach and report ba
Le Jeudi, 27 mars 2003, à 14:31 Europe/Zurich, Steven Noels a écrit :
...It's good to see that the 'requirement' to vote adds some energy to
the discussion, but then again, you, Diana & David are mostly right
when suggesting that vote was premature and underspecified. I'm the
hero of underspeci
Le Jeudi, 27 mars 2003, à 13:52 Europe/Zurich, Diana Shannon a écrit :
...
I think a discussion intermixed with a vote changes the vote so that
people end up voting on different issues -- with no clear cut result.
Agreed - in this particular case, the best thing might be to cancel the
current vo
On Wednesday, March 26, 2003, at 10:52 PM, David Crossley wrote:
Hm. Could be, although this particular subject has been discussed,
semi-proposed and whatnot already at some serious length in the
past, the usual circular discussion following suit hereafter.
I only ever saw haphazard discussion, n
Le Mercredi, 26 mars 2003, à 10:45 Europe/Zurich, Stefano Mazzocchi a
écrit :
So, the proposal is not about forcing docu-oriented people as
second-class citizens, but potentially allowing people (or services)
that *request* or *need* to be docu-oriented-only to be able to be
given karma l
David Crossley wrote:
Stefano Mazzocchi wrote:
Pier Fumagalli wrote:
Folks, do you know that there's the possibility to alias certain subparts of
a particular CVS repository from another repository?
Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
Apache does it alread
> From: Diana Shannon [mailto:[EMAIL PROTECTED]
>
> Locally, referenced via a path set in a configuration file. If code
> repos aren't available/downloaded, info can also be looked up online via
> a parsed view-cvs data. Still, I don't think it's too much to expect
> from committers, to have al
Pier Fumagalli wrote:
On 24/3/03 9:13 am, "Jeff Turner" <[EMAIL PROTECTED]> wrote:
On Mon, Mar 24, 2003 at 07:31:39AM +0100, Steven Noels wrote:
In order to get one little step closer to the 'new' document
infrastructure, many of us seek clarity whether we should move docs to a
separate CVS modu
On Monday, March 24, 2003, at 10:34 AM, Steven Noels wrote:
My own belly tells me that people will write more and better user
documentation if they get some proper playground. Having to worry
about code sitting right beside their documents will not bring peace
in their minds.
Ok, please, expl
On Monday, March 24, 2003, at 09:15 AM, Steven Noels wrote:
On 24/03/2003 14:23 Stefano Mazzocchi wrote:
I don't expect 2.0 to live long after 2.1 is out. There is no reason
to.
To be really honest, I'd like to see some facts backing this statement.
Not technical facts, but truly compelling re
Diana Shannon wrote:
[ +1 ] creation of cocoon-docs module
[ ] docs should stay in src/documentation of the code tree module(s)
I feel strongly about this, give the past year of my watching cvs
commits. The fact remains that many committers don't update both doc
branches when committing doc
[ +1 ] creation of cocoon-docs module
[ ] docs should stay in src/documentation of the code tree module(s)
I feel strongly about this, give the past year of my watching cvs
commits. The fact remains that many committers don't update both doc
branches when committing docs. If someone needs *
Steven Noels wrote:
In order to get one little step closer to the 'new' document
infrastructure, many of us seek clarity whether we should move docs to a
separate CVS module or not. The benefits and downfalls are largely
known, so let's vote on this and get this issue cleared.
My own personal b
Jeff Turner wrote, On 24/03/2003 10.13:
On Mon, Mar 24, 2003 at 07:31:39AM +0100, Steven Noels wrote:
In order to get one little step closer to the 'new' document
infrastructure, many of us seek clarity whether we should move docs to a
separate CVS module or not. The benefits and downfalls are
On Mon, Mar 24, 2003 at 07:31:39AM +0100, Steven Noels wrote:
> In order to get one little step closer to the 'new' document
> infrastructure, many of us seek clarity whether we should move docs to a
> separate CVS module or not. The benefits and downfalls are largely
> known, so let's vote on t
Steven Noels wrote:
In order to get one little step closer to the 'new' document
infrastructure, many of us seek clarity whether we should move docs to
a separate CVS module or not. The benefits and downfalls are largely
known, so let's vote on this and get this issue cleared.
My own personal
> From: Steven Noels [mailto:[EMAIL PROTECTED]
>
> In order to get one little step closer to the 'new' document
> infrastructure, many of us seek clarity whether we should move docs to a
> separate CVS module or not. The benefits and downfalls are largely
> known, so let's vote on this and get
In order to get one little step closer to the 'new' document
infrastructure, many of us seek clarity whether we should move docs to a
separate CVS module or not. The benefits and downfalls are largely
known, so let's vote on this and get this issue cleared.
My own personal bias: don't forget th
21 matches
Mail list logo
