Gee, now here is a sensitive subject. :-)
IRC BTW is very flaky if you don't have good connection (as most people
at AC currently experience). Mail is much better for that because it is
not as volatile as IRC.
Aside from that I do agree with most things that wrowe wrote. I know of
at least o
On Aug 15, 2006, at 2:38 AM, Ian Holsman wrote:
It isn't the individuals who make the decision, but the community
as a whole.
If they feel more comfortable using X to communicate then fine.
If a individual doesn't like the method the project is
communicating with then it
is up to him to con
The ActiveMQ committers have decided to aim for TLP status (1), as
such we need to get a PPMC in place. Thus far we have been working
under a "committer votes all count" style (really, everyone's vote
counts, it is on a public list without any of the "mine is binding"
stuff that has become
On Aug 15, 2006, at 5:23 PM, Noel J. Bergman wrote:
Yoav Shapira wrote:
Noel J. Bergman wrote:
I would put forth a strawman that the "Editor" role is at least
somewhat analogous to the "Release Manager" for code.
there's a big difference: a release manager does not modify other
people's w
On Aug 15, 2006, at 6:25 PM, Sanjiva Weerawarana wrote:
On Tue, 2006-08-15 at 17:36 -0400, Jim Hurley wrote:
But *the* as in: "the main", "the original", "the most prominent",
(what will be)
"the Community's implementation", and "the one you'd recommend a
developer
go grab to get going wit
On Tue, 2006-08-15 at 17:36 -0400, Jim Hurley wrote:
> I'm not going to try and pull a Bill Clinton with "it depends what the
> definition of "is" is" but I'd answer that I believe the Jini
> Community
> views the project as *the* Jini implementation.
>
> But *the* as in: "the main", "the o
Yoav Shapira wrote:
> Noel J. Bergman wrote:
> > I would put forth a strawman that the "Editor" role is at least
> > somewhat analogous to the "Release Manager" for code.
> there's a big difference: a release manager does not modify other
> people's work (e.g. the code), only packages it.
The Re
Hi,
On 8/15/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
dictates. I would put forth a strawman that the "Editor" role is at least
somewhat analogous to the "Release Manager" for code. Either way, the
deliverable still needs to be approved by the PMC.
Yes, either way the deliverable still
Geir Magnusson Jr wrote:
> > if we start with the mailing lists separate and the source control
> > split, which seems natural from what everyone is saying, I expect
> > that the governmance issue will sort itself out in due course.
> Like a subproject?
Uh, no. Our governance model does not rec
Craig Russell wrote:
> Granqvist, Hans wrote:
>> Just a few thoughts on the process: How do you envision editorship
>> of the spec? Would all committers be editors?
> In successful spec writing projects that I've been involved in, there
> has been an editor for the entire specification or an edit
Jim Hurley wrote:
> But *the* as in: "the main", "the original", "the most prominent", (what will
> be) "the Community's implementation", and "the one you'd recommend a
> developer go grab to get going with Jini". But not *the* as in "the only".
>
> I view it as being/becoming *the* Jini Communi
Hi,
You know, I totally haven't been checking for license headers in
non-source-code files ;) Thank you for pointing that out.
Yoav
On 8/15/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 8/11/06, Steve Toback <[EMAIL PROTECTED]> wrote:
> The Lokahi community voted on and has approve
Jukka Zitting wrote:
>>I'm not convinced the goal in the past was to have multiple
>>implementations, vs allowing multiple implementations.
>
> I think the interpretation of this goal underlies both the naming and
> standard issues. In essence, does the Jini community see the project
> being propo
See my reply to your last post, conversations are OK, but discussions
resulting in proposals can quickly deteriorate into a short circuit
which excludes other participants from the real process, which isn't
about making a boolean decision but about reaching an informed
consensus.
On 15/08/06, Jan
On Aug 15, 2006, at 4:46 PM, Jukka Zitting wrote:
I'm not convinced the goal in the past was to have multiple
implementations, vs allowing multiple implementations.
I think the interpretation of this goal underlies both the naming and
standard issues. In essence, does the Jini community see t
On 15/08/06, Jan Blok <[EMAIL PROTECTED]> wrote:
Hi,
What could be the problem of any real-time communication medium usage
between some community members as long as every one agrees code and
design decisions are made on the mailing list?
Because the discussion which results in the proposal is
On 8/11/06, Steve Toback <[EMAIL PROTECTED]> wrote:
The Lokahi community voted on and has approved a proposal to release
Lokahi M01. Pursuant to the Releases section of the Incubation Policy
we would now like to request the permission of the Incubator PMC to
publish the tarball on the Lokahi Down
Hi,
On 8/15/06, Bob Scheifler <[EMAIL PROTECTED]> wrote:
But I'm not sure it matters at this point whether we agree on how
to interpret success or failure in the past.
Agreed. I'm sorry for bringing the issue out in that light.
I'm not convinced the goal in the past was to have multiple
impl
On 8/14/06, James M Snell <[EMAIL PROTECTED]> wrote:
Ok, so we've addressed most of the issues raised in the note below and
believe we are ready to move forward with 0.1.0. The new zips are
available at http://people.apache.org/~jmsnell
At your convenience, we'd appreciate it if y'all could rev
Hi,
There seems to me a huge difference between doing conversations about
code/design (with a possible conclusion to post a "formal"
change-proposal on the mailing list), and making the decision itself.
Jan
Geir Magnusson Jr wrote:
Jan Blok wrote:
Hi,
What could be the problem of an
Jukka Zitting wrote:
Hi,
On 8/15/06, Bob Scheifler <[EMAIL PROTECTED]> wrote:
It's important to note that the JDP is not a process for
*developing* standards, but for *approving* them. The JDP is
a backend decision process, not a frontend development process.
Most of the specifications that ha
Jukka Zitting wrote:
>>It's important to note that the JDP is not a process for
>>*developing* standards, but for *approving* them. The JDP is
>>a backend decision process, not a frontend development process.
>>Most of the specifications that have been approved under the JDP
>>were in fact develop
Geir Magnusson Jr wrote:
>
> Because the reality is that decisions are made on IRC, implicitly. It's
> hard to engage in an argument that already happened, especially when the
> discussion was very conversational rather than formal :
>
> A: what do you think?
> B: Well, like you said before...
Alan Conway wrote:
> Idiotic question from complete Apache newbie: is the proposal that
> Apache should start hosting specs but would still host projects
> implementing foreign specs, or that Apache should stop hosting projects
> implementing non-Apache specs?
Twofold answer IMHO...
if we host a
On Aug 15, 2006, at 6:57 AM, Alan Conway wrote:
Idiotic question from complete Apache newbie: is the proposal that
Apache should start hosting specs but would still host projects
implementing foreign specs, or that Apache should stop hosting
projects
implementing non-Apache specs?
I haven'
Hi,
On 8/15/06, Bob Scheifler <[EMAIL PROTECTED]> wrote:
It's important to note that the JDP is not a process for
*developing* standards, but for *approving* them. The JDP is
a backend decision process, not a frontend development process.
Most of the specifications that have been approved under
Jukka Zitting wrote:
> I think the question boils down to the issue of what will happen to
> the Jini standard now that the JDP has been closed down.
I hope I'm not nitpicking, but there isn't a singular Jini standard;
there are multiple specifications that have been approved as standards
under th
Jukka Zitting wrote:
>
> I think the question boils down to the issue of what will happen to
> the Jini standard now that the JDP has been closed down. It's correct
> to insist in that the standard shouldn't be developed within the
> implementation project if the goal is to allow independent
>
Geir Magnusson Jr wrote:
>>For the reason I stated: I don't believe we have sufficient commitments
>>from people willing and able to run a broad-based standards process.
>
> Wouldn't it be the same people in the code podling working in two
> podlings?
If one of the podlings is for running a stand
Bob Scheifler wrote:
> Filip at Apache wrote:
>> jini is a trademark
>> directory isn't
>
> The question wasn't about Jini vs others. Geir said he wouldn't support
> "Apache EMail" or "Apache Web", and I'd like to understand how those two
> are different from "Apache Directory", "Apache Web Servi
On 8/15/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
If a individual doesn't like the method the project is communicating
with then it
is up to him to convince the rest of the community/project to change.
It's not necessarily a question of 'like'. Even if someone likes IRC, they
may not have
Jan Blok wrote:
> Hi,
>
> What could be the problem of any real-time communication medium usage
> between some community members as long as every one agrees code and
> design decisions are made on the mailing list?
Because the reality is that decisions are made on IRC, implicitly. It's
hard to
As I and other have stated, IRC (and other real-time methods)
have their uses, but that it is too easy for them to
grow and expand beyond what they were originally set to
do.
This is, after all, not some willy-nilly "consideration"
that we just felt made sense. Instead, it's something
which has p
Hi,
On 8/15/06, Bob Scheifler <[EMAIL PROTECTED]> wrote:
I'll try again. It seems we're discussing three different things:
1. development of code
2. development of specs
3. running a standards process
My concern is about #3, and not trying to do it in an ASF project.
My reason is simple: there
Filip at Apache wrote:
> jini is a trademark
> directory isn't
The question wasn't about Jini vs others. Geir said he wouldn't support
"Apache EMail" or "Apache Web", and I'd like to understand how those two
are different from "Apache Directory", "Apache Web Services", etc.
- Bob
---
Garrett Rooney wrote:
>>It would help me if you could explain how these existing TLP names
>>are different/OK: DB, Directory, Logging, Web Services, XML.
>
> Just because we did things in the past does not mean it was a good idea.
That's fine, but it doesn't help me understand the statement
about
Hi,
What could be the problem of any real-time communication medium usage
between some community members as long as every one agrees code and
design decisions are made on the mailing list?
Regards Jan Blok
Jim Jagielski wrote:
I think one way of looking at this is simply remembering that
Noel J. Bergman wrote:
> What is your concern? Can you please try to be simple and specific about
> it?
I'll try again. It seems we're discussing three different things:
1. development of code
2. development of specs
3. running a standards process
My concern is about #3, and not trying to do it
Bob Scheifler wrote:
Geir Magnusson Jr wrote:
We have a tradition, for good reason, for not giving our projects
"technology domain" ownership for implementations. I'd never support
"Apache EMail" or "Apache Web".
It would help me if you could explain how these existing TLP names
are d
On 8/15/06, Bob Scheifler <[EMAIL PROTECTED]> wrote:
Geir Magnusson Jr wrote:
> We have a tradition, for good reason, for not giving our projects
> "technology domain" ownership for implementations. I'd never support
> "Apache EMail" or "Apache Web".
It would help me if you could explain how th
Geir Magnusson Jr wrote:
> We have a tradition, for good reason, for not giving our projects
> "technology domain" ownership for implementations. I'd never support
> "Apache EMail" or "Apache Web".
It would help me if you could explain how these existing TLP names
are different/OK: DB, Directory,
I think one way of looking at this is simply remembering that
the ASF values community over code. Yes, IRC and other
real-time communication methods means "quicker" code
development, etc, but it places, IMO, an undue barrier
to the development of the community.
---
Idiotic question from complete Apache newbie: is the proposal that
Apache should start hosting specs but would still host projects
implementing foreign specs, or that Apache should stop hosting projects
implementing non-Apache specs?
On Mon, 2006-08-14 at 08:34 +0100, James Strachan wrote:
> On 8/
Hi,
Ian Holsman wrote:
It isn't the individuals who make the decision, but the community as
a whole.
I don't agree with the above at all. The community is more than just
the sum of its members, but that sum is a large part of the community
nonetheless. A lot of times (too many in some projec
On Aug 15, 2006, at 1:52 AM, Ian Holsman wrote:
I don't think we (the ASF) need to support the weakest link of the
chain either. if a member
can't access a project due to limitations of corporate policy or
timezone, we should be OK with that too.
not every member has to be able to particip
On 15/08/2006, at 7:02 PM, Danny Angus wrote:
On 15/08/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
Obvioulsy we aren't going to agree about this, which is fine, but I'd
still like to pick up on a couple of points that you raised;
we are talking about stopping people using what they are comfo
+1 with these statement.
Finally one that really makes sense in my eyes
johan
On 8/15/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
you can either acknowledge that some people prefer to use IRC
to communicate, and accept that while it isn't the best medium, or
the one
you would choose, it is th
On 15/08/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
Obvioulsy we aren't going to agree about this, which is fine, but I'd
still like to pick up on a couple of points that you raised;
we are talking about stopping people using what they are comfortable
with just
because we have a few people who
48 matches
Mail list logo
