Subject:
|
Re: Backwards Compatibility (Was Calling all Meta-commands)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 17 Mar 2003 19:38:25 GMT
|
Viewed:
|
2090 times
|
| |
|
|
Tim Courtney wrote:
> In lugnet.cad.dev, Kyle McDonald writes:
>
>
> > Well this was one of the reasons behind my original suggestion.
> > (This thread sure did take off while I was away skiing this weekend.)
> >
> > I suggested that a new meta command group be made today, albeit
> > before the creation of a standards body, so that Application
> > authors could be free to add/implement whatever they can think of
> > in this namespace branch, without using up names that the
> > community might want to use for something else later on.
>
>
> I disagree. Let's stick with the current method of meta-commands until a
> standards body officially determines the syntax of future generation
> commands. No hold on anything, innovation can continue (just in the same
> disorganized fashion it always has), until a definitive decision is reached.
That's fine also. I was only offering a possible way to avoid
taking even more useful options away from the standards commitee.
I don't think it would be too much to ask that new commands
all be prefixed with 'UNOFF' or 'UNOFFICIAL'. It of course
would be totally on the honor system, which as you've stated
has worked in the past (.DAT -> .LDR conversion.) and the
whole 'unofficial' concept even has a parallel in the parts
releases too.
>
> I like the idea of a standards body with defined members, either volunteer
> or voted in initially, but for a certain term. Right now I favor volunteers
> for this body, since I think we'll only have a handful of them. Is there a
> magic number of people here... there can't be too many on this board or
> nothing will get done, but not too few, we need a good cross-section of the
> community's programmers.
As I a programmer of this type of app, I'd love to be involved. However
I'm not going to volunteer, because I realize that my involvement in this
community has been practically non-existant. That said, I am very interested
in contributing more and more to all of these dicussions. Hopefully I'll
even be ready to release some code soon too!
> I also think it would be great if the community could 'listen in' on a std.
> body mailing list -- like receive the mails but not be able to post. Then
> broader discussion can take place here on cad.dev, adding to the depth of
> the discussion without adding to the noise *inside* the SB. The SB would
> then vote on additions/changes to the spec.
I don't have a problem with the SB having an internal communications
mechanism, but I would prefer it if I could have some reasonable assurance
that my comments (where ever the standard place for comments ends up being)
would get read by all (or at least a majority) of the SB.
Also while day to day things might take place by the SB on some quieter
mailing list, I'm very much in favor of some regular public update of
the status and direction of the SB.
> My thoughts are kinda blobby right now. I get the feeling I should talk with
> a few people and come up with a good, fair method of establishing the SB,
> and guidelines for the SB prepetuating itself. As stated elsewhere, I'd like
> to help guide this into existance, but not participate on the actual SB.
Something like this is always tricky.
While all might aggree on the original membership, what will the
procedures be to replace someone who leaves? to grow the committee?
or god forbid, remove someone the commitee isn't happy with?
I'm not trying to be a wet blanket. I think all of this is a great
idea. I just think that some of these things are better off being
decided up front, or at least everyone should be aware that they are
still up in the air.
> A formal voting system is needed, I think. Steve and I have discussed this
> quite a bit. We need some way to define 'members' and some way for members
> to vote.
>
> I DO NOT think just anyone should vote on standards. The members of the SB
> should be people who program the various tools. I also strongly recommend
> Steve is on the SB, though he probably will want the position himself
> anyways. :-)
I'm wondering if (and this is only an idea) some two tiered or wieghted
voting mechanism should be considered? Maybe the committee decides on
a resolution, and then the whole community votes yes/no? or maybe the
committee narrows the choices down to 2, and the community picks the
final result? Lastly maybe the committee memeber have votes that count
100 (or some other number) times as strong as a community members vote?
Again, I'm not promoting any of these ideas. Just throwing them out
there in case anyone wants to pick them up and run with them.
> The reason the SB shouldn't be a free-for-all for anyone to comment on is we
> need people with experience programming, and we need a relatively small
> (less than 10 for sure) number of people to maintain efficiency and focus. I
> am very wary of letting large groups make decisions. Every crowd has a
> stupid lining.
Yes smaller will help things keep moving. But it won't allow all
parties to be represented. There needs to be some method that the
whole community can use to add it's input, and be assured it will
at least be heard.
-Kyle
--
_
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc. |||||
Enterprise Server Products Kyle.McDonald@Sun.COM
1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o) fax: (781) 442-1542
-------------------------------ooO(_)Ooo-------------------------------
|
|
Message has 1 Reply:
Message is in Reply To:
154 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
