Looking at the mail thread, it appears the votes are:
"Majority"
Margot (didn't see an actual vote from you)
Tom
"Minority"
Aniruddh
John
Mark
Given this, I think we can consider the case approved and the opinion
should switch the two opinions around. There should be the discussed
TCA, but not t
Thanks everyone for voting.
With holiday coming up lets' keep this open for a few more days to give
others
a chance to vote if they want to- COB Tuesday May 26th.
Margot
Aniruddh Dikhit wrote:
> Margot
>
> I am more aligned with the minority opinion on this issue.
>
> -Aniruddh
>
> John Fisch
Margot
I am more aligned with the minority opinion on this issue.
-Aniruddh
John Fischer wrote:
> Margot,
>
> Please put me down with the Minority group.
>
> Thanks,
>
> John
>
>
> Tom Childers wrote:
>> Agreed. I vote to approve with the TCR, and would support a TCA to
>> "document the interf
Margot,
Please put me down with the Minority group.
Thanks,
John
Tom Childers wrote:
> Agreed. I vote to approve with the TCR, and would support a TCA to
> "document the interface classification in the native documentation".
> -tdc
>
>
> On May 20, 2009, at 3:53 PM, Margot Miller wrote:
>
Deny - I'd change it to a TCA to "document the interface classification
in the native documentation" (follow the outline in the minority opinion).
-- mark
Margot Miller wrote:
> All,
>
> I have included the minority opinion written by Mark Carlson.
>
> We did in fact have quorum yesterday; our ex
Agreed. I vote to approve with the TCR, and would support a TCA to
"document the interface classification in the native documentation".
-tdc
On May 20, 2009, at 3:53 PM, Margot Miller wrote:
> I wouldn?t mind having a TCA to have teams document the
> interface classification in their native d
I wouldn?t mind having a TCA to have teams document the
interface classification in their native documentation. The
only thing I disagree with is forcing teams to provide a man
page if they don?t have the interface classification in their
native documentation.
Thanks
Margot
Mark A. Carlson wrot
All,
I have included the minority opinion written by Mark Carlson.
We did in fact have quorum yesterday; our external member
was not listed as a full member.
In any case, due to the lack of perceived quorum yesterday,
please vote on this case.
Vote to approve the case as written (with the TCR
[I know you're looking for a vote here and not more discussion, but I
don't think the text matches up yet.]
Margot Miller writes:
> There is quite a bit of FOSS out there with no interface stability
> in the external Sun documentation. This is not a problem for Sun
> project teams as they can alw
Tom Childers wrote:
> Mark,
>
> This is really good. The bottom line seems to be:
>
> - if we build it, we will use our own interface stability
> classifications, and
> deliver them via language-specific documentation facilities
Yes.
>
> - if someone else built it, and there is IF st
Margot Miller wrote:
> Mark,
>
> In this below scenario 2b, does it mean that if a project team
> is not willing to change the native docs, then they must supply
> a man page?
Yes. Otherwise this case will set the very bad precedent (in my mind)
that projects are not required to publicly document t
Can you include the minority opinion in this? I sent it out yesterday.
It's not clear what you are asking a vote for:
1) approve the project with this opinion or
2) vote for one:
a) this opinion
b) the minority opinion
I would vote:
1) approve the project, but
2) b - the minority opini
Mark,
In this below scenario 2b, does it mean that if a project team
is not willing to change the native docs, then they must supply
a man page?
2) OSS Community does not document interface classification in
their native documentation
a) OpenSolaris project team is stro
Good point.
Will omit that second line.
Thanks
Margot
James Carlson wrote:
> [I know you're looking for a vote here and not more discussion, but I
> don't think the text matches up yet.]
>
> Margot Miller writes:
>
>> There is quite a bit of FOSS out there with no interface stability
>> i
resending it- got psarc address wrong.
Hey All,
Below is the updated opinion with feedback from James, Mark, and
Mike.
We only had three members vote on this during the meeting. There
was an issue of quorum; we did not have quorum as one member
was not formally declared on sabbatical.
So I wou
Hey All,
Below is the updated opinion with feedback from James, Mark, and
Mike.
We only had three members vote on this during the meeting. There
was an issue of quorum; we did not have quorum as one member
was not formally declared on sabbatical.
So I would like to conduct an email vote on this
Mark,
This is really good. The bottom line seems to be:
- if we build it, we will use our own interface stability
classifications, and
deliver them via language-specific documentation facilities
- if someone else built it, and there is IF stability info, we'll
suppo
Michael Kearney writes:
> > There needs to more discussion to determine if it is critical that the
> > ARC stability
> > level be communicated to the Solaris end user for all the FOSS software
> > that is being delivered. If so, a comprehensive solution needs to be
> > formulated, whether it is a
See comments inline:
margot wrote:
> Hey All,
>
> Here is the draft opinion.
>
> Please review/comment.
> Thanks
> Margot
>
> **
>
>
> sun
> microsystems Systems Architecture Committee
>
> _
>
> Subject: trove-2.0.4
>
Please see comments embedded below.
Michael Kearney wrote:
> See comments inline:
>
> margot wrote:
>> Hey All,
>>
>> Here is the draft opinion.
>>
>> Please review/comment.
>> Thanks
>> Margot
>>
>> **
>>
>>
>> sun
>> microsystems Systems Architecture Committee
>>
>> _
See inline.
margot wrote:
> Hey All,
>
> Here is the draft opinion.
>
> Please review/comment.
> Thanks
> Margot
>
> **
>
>
> sun
> microsystems Systems Architecture Committee
>
> _
>
> Subject: trove-2.0.4
>
> Submitt
Hey All,
Here is the draft opinion.
Please review/comment.
Thanks
Margot
**
sun
microsystems Systems Architecture Committee
_
Subject: trove-2.0.4
Submitted by: Vivek Titamare
File: LSARC/2009/262/opinion.txt
Garrett D'Amore wrote:
> Mark A. Carlson wrote:
>> Let's keep in mind that we are trying to document (in an easily
>> accessible place) the
>> interface classification of the OpenSolaris instance (not the Java
>> interface across platforms).
>> Given that we need to do this without massive patche
Could we not add something like a stability file to the META-INF directory in a
JAR file then provide something (like extension in IDE, or CLI) to extract it?
I was going to suggest adding it to the manifest, but it would seem to be more
strict about the format of the file - while the directory ME
During the case discussion today, I took the AI to help Michael Kearney
draft
a minority opinion. There may be other minority opinions, but if this looks
close to something you would sign on to, I am open to small changes.
-- mark
5. Minority Opinion
Background
It is not typical
Garrett D'Amore writes:
> Mark A. Carlson wrote:
> > Let's keep in mind that we are trying to document (in an easily
> > accessible place) the
> > interface classification of the OpenSolaris instance (not the Java
> > interface across platforms).
> > Given that we need to do this without massive
Garrett D'Amore wrote:
> Mark A. Carlson wrote:
>> Let's keep in mind that we are trying to document (in an easily
>> accessible place) the
>> interface classification of the OpenSolaris instance (not the Java
>> interface across platforms).
>> Given that we need to do this without massive patche
James Carlson wrote:
> Garrett D'Amore writes:
>
>> Mark A. Carlson wrote:
>>
>>> Let's keep in mind that we are trying to document (in an easily
>>> accessible place) the
>>> interface classification of the OpenSolaris instance (not the Java
>>> interface across platforms).
>>> Given tha
+-- various people wrote:
|
| ... I remain unconvinced that we (OpenSolaris) should even be concerned
| about stability of Java APIs
|
| ... Do other members see value in having another layer of commitment and
| review beyond whatever is already done as part of the Java community?
|
| ... At a mini
Let's keep in mind that we are trying to document (in an easily
accessible place) the
interface classification of the OpenSolaris instance (not the Java
interface across platforms).
Given that we need to do this without massive patches to the upstream
code, and that
Java projects should use what
I agree in principle with Jim's points. In particular,
> 1. Provides users stability and availability (taxonomy) information
> about jar file packages on Solaris/OpenSolaris not available anywhere
> else.
If ARCs are going to require this information, it should be documented
somewhere that a user
Mark A. Carlson wrote:
> Let's keep in mind that we are trying to document (in an easily
> accessible place) the
> interface classification of the OpenSolaris instance (not the Java
> interface across platforms).
> Given that we need to do this without massive patches to the upstream
> code, and
Jim Walker wrote:
> For LSARC, PSARC and the opinion writer(s) to consider
>
> Michael Kearney wrote:
>> 1. Lloyd, I like the idea of your annotation but have a couple of
>> concerns.
>> - Would teams be expected to update third party, open source jar
>> files with the annotation?
>>
For LSARC, PSARC and the opinion writer(s) to consider
Michael Kearney wrote:
> 1. Lloyd, I like the idea of your annotation but have a couple of
> concerns.
> - Would teams be expected to update third party, open source jar
> files with the annotation?
> - Would the ARC provide the
Instead of doing this via email, let's put this on
the agenda for next week.
At that time we can decide whether the below:
Do not ship man pages with jar files
should be a TCR, TCA, or Advice.
That is the only outstanding issue on this case.
Then, if everyone is ready, we can then vote
on
Margot Miller wrote:
> Hey All,
>
> I am derailing this case as it misses the non-controversial requirement
> for a fast track and would like an email vote on this case by
> Friday May 15th.
>
> My impression from today's meeting was that LSARC will have
> a future case that will address the issue
Worth noting:
'man' pages are wholly inadequate to document some jar files; one
would be in the awkward position of enumerating all the classes, and
possibly all the methods/constants in those classes.
There are jar files that are nothing but interfaces, some that are
interfaces and code, s
"how do we communicate the interface classification of a jar file"
This is a multi-level.
Plenty of jar files contain classes or classes with methods and other
stuff which is not intended for public consumption. Simply because
somthing is "public" or "protected" is not a good way to assume i
In GlassFish V3, here is what I'm doing (one example). I've created
the annotation @Taxonomy, which takes a value of type Stability. This
is what it looks like in the Javadoc. One can click through the
annotation and see the actual definition of the stability level.
This is available at t
The case hasn't been denied; it's been derailed so an opinion can be
written and it will be clear if precedence has been set or not with this
case.
From the LSARC meeting today, it seemed like the majority of
the committee thought it was fine for the project team and other
teams to ship a man pa
Hey All,
I am derailing this case as it misses the non-controversial requirement
for a fast track and would like an email vote on this case by
Friday May 15th.
My impression from today's meeting was that LSARC will have
a future case that will address the issue of how to publicize interface
class
Sent: Friday, May 08, 2009 2:40 AM
To: Mark Carlson
Cc: LSARC-ext at sun.com; Vivek.Titarmare at Sun.COM
Subject: Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Please put the JDK in the imported table. Also previous email
asked what is the minimum JDK that can be used with this.
No nee
Also what is the name of package this is being delivered in?
Margot Miller wrote:
> Please put the JDK in the imported table. Also previous email
> asked what is the minimum JDK that can be used with this.
>
> No need to deliver a man page for a java library.
>
> Thanks
> Margot
>
>
> Mark Carls
Please put the JDK in the imported table. Also previous email
asked what is the minimum JDK that can be used with this.
No need to deliver a man page for a java library.
Thanks
Margot
Mark Carlson wrote:
> I am sponsoring this familiarity case for Vivek Titarmare. It requests minor
> binding
Mark Carlson wrote:
> 5. Interfaces
>
> The jar file "trove.jar" contains following interface.
>
>Exported interface Classification
> Interface type
>===
> ==
>
I am sponsoring this familiarity case for Vivek Titarmare. It requests minor
binding and times out 05/05/2009.
-- mark
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
trove-
46 matches
Mail list logo
