|
Hi Duncan,
Yep, there aren't enough terms to go around. The rules do indeed say that only the PGB can approve an official Release. The flow is that the TSC approves submitting a package of 'stuff' to the PGB with its recommendation that they approve it as a formal Release. We could probably use some refinement of the wording there...
On Mon, Oct 24, 2022 at 4:34 PM duncan@sfractal < duncan@...> wrote:
My point was we celebrate reaching goals. If the open source parts of OCA never want to make official releases, that is ok but I think they are missing an opportunity. I think
it would be better to come out with some sort of 1.0 that has whatever features and those dot releases that ‘rate’ some publicity (not every dot, but those like adding a new interface for an OASIS member that make a good press release). For open source I see
the PGB both approving ‘where they are at’ (whether as release or as PSD) but more from an ‘awareness & adoption’ viewpoint (ie it’s an opportunity not a burden).
But I also think we should at least think about whether we want any interface standards to result. And for those that do, we should start them down the release/project-specification-draft/
project-specification/OASIS-standard path. Even if they are trivially simple (“use Kestrel threat language for sharing …”). Triple benefit (1) actual standards (2) awareness & adoption (3) might get others to pitch in to get their stuff part of standards.
Chet – I thought your other email implied ‘releases’ had to be approved by PGB, but in this thread I think you suggest TSC can approve ‘releases’ as part of the release/ project-specification-draft/
project-specification/OASIS-standard path. Note release is an overloaded term. A github release is not same as project release (which is also not the same as press release, but I think project releases should rate press releases
😊.) I thought (based on what you told me) that TSC did github releases and got PGB to approve them into Official Project
Releases. Note
https://www.oasis-open.org/policies-guidelines/open-projects-process/#releases-and-group-releases-designation of the Oasis Open Project Rules states PGB approves official Releases & Group Releases which they define as “a
collection of links to resources within the project that enable the Project
Governing Board to deliver software to users.”
I’m not doing this to be a pain on terminology (albeit I think if we got our terms straight, our lives would be easier) – I just want to follow the rules and get stuff out
there and celebrate the accomplishments to suck others into joining.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
New guy point of view… It seems to me that TC should/would be responsible for engineering releases, beta releases etc. and govern/manage those as they see fit.
Once they feel they have a “Viable Product”, which is loosely defined by them based on their goals and objectives. Then, they should involve the PGB and, I assume, would illustrate to the PGB how they have achieved some/all of the goals they set out to accomplish.
PGB would approve/advise/guide/commend those efforts via some criteria as well as help them “get the word out”. Do we have such a process in place or are we looking to get one going here?
I should also include, that I agree with the points being made on this thread. We should be looking to get product/tools/etc. out in the public for use, feedback
and improvements as well as increasing visibility of the group(s) and hopefully also increasing involvement at many levels.
My $0.02. Hope it’s helpful.
--
Regards,
Rich
--------------------------------------------------------
SAIC - Charleston, SC
Phone: 843-746-6149 {Direct Line}
--------------------------------------------------------
Need Cyber Help or just more Cyber Info?
DIF Cyber Portal:
https://cyber.digital.saicif.com
EXTERNAL EMAIL -- This message originates from outside of SAIC
Duncan, it sounds like this parallels TC process work. Iterate a series of Working Drafts which could increment version numbers, e.g. 1.0.1, 1.0.2 up to the point where you think it is developed enough to present to the TSC. I'd suggest
the TSC do the approval of incremental enhancements and then, when you're ready, the TSC send it to the PGB with the recommendation that it be approved as a Project Specification Draft. (Assuming, of course, that the PGB has been briefed on progress from time
to time.) In other words, move it to the PGB level when you consider it done from your point of view.
On Mon, Oct 24, 2022 at 10:05 AM duncan@sfractal <duncan@...> wrote:
Jason (and I cc’d TSC as well original PGB).
Agree it’s the TSC that brings to PGB for approval after a project brings it to TSC. I’m just prompting people should look at this (ie not forget
our purpose is to create work products) which might help get others involved, or at least aware of our projects and start using them.
Wrt your gate criteria for a release: At the far end of the scale (standard), the bar should probably be fairly high, but I’d suggest for the near
end (release) the bar be fairly low (ie approve incrementally more often). And I think getting to a ‘first release’ (presume it would be called 1.0.0) would be good even if it’s “incomplete”. And then PGB approving “dot releases” (e.g. 1.1) that add features
would be more often (monthly probably too many, but somewhere in quarterly to annually) would be good. And obviously breaking changes (eg 2.0.0) should be approved as soon as agreed to. If we’d have a lot of breaking changes, then I agree it would be better
to wait until stable.
TSC:
See thread below. Your thoughts of releases (lowest level of approval for open projects, followed by draft project specification, project specification,
and OASIS standard). I’m not proposing people jump right to standard but I am suggesting we should consider putting out releases on our subprojects (or at least plan when we might do so).
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
The TSC would need to guide that question.
-
I do not know what the gate criteria would be to tag a 1.0 release in any of the core projects, it would be a TSC question.
-
In theory the Kestrel language could eventually be a standard but I know there are some changes coming. Again the TSC should guide when they think it is stable enough to start that journey.
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work
products ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work products
ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC standard just approved by PGB instead of a TC). I just sent an email to PACE list about work products I think PACE should be producing. Are either stixshifter or
kestrel at a point where they should be considering PGB approving a release? Note approving stuff might rate OASIS news release and might spur some interest both in participating and in using the open source.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
--
|
|
Chet Ensign
Chief Technical Community Steward
OASIS Open
|
|
|
|
|
The information contained in this e-mail and any attachments from Science Applications International Corporation ("SAIC") may contain confidential and/or proprietary information,
and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in
error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.
-- | Chet EnsignChief Technical Community Steward OASIS Open | | | | |
|
|
|
duncan@sfractal
My point was we celebrate reaching goals. If the open source parts of OCA never want to make official releases, that is ok but I think they are missing an opportunity. I think
it would be better to come out with some sort of 1.0 that has whatever features and those dot releases that ‘rate’ some publicity (not every dot, but those like adding a new interface for an OASIS member that make a good press release). For open source I see
the PGB both approving ‘where they are at’ (whether as release or as PSD) but more from an ‘awareness & adoption’ viewpoint (ie it’s an opportunity not a burden).
But I also think we should at least think about whether we want any interface standards to result. And for those that do, we should start them down the release/project-specification-draft/
project-specification/OASIS-standard path. Even if they are trivially simple (“use Kestrel threat language for sharing …”). Triple benefit (1) actual standards (2) awareness & adoption (3) might get others to pitch in to get their stuff part of standards.
Chet – I thought your other email implied ‘releases’ had to be approved by PGB, but in this thread I think you suggest TSC can approve ‘releases’ as part of the release/ project-specification-draft/
project-specification/OASIS-standard path. Note release is an overloaded term. A github release is not same as project release (which is also not the same as press release, but I think project releases should rate press releases
😊.) I thought (based on what you told me) that TSC did github releases and got PGB to approve them into Official Project
Releases. Note
https://www.oasis-open.org/policies-guidelines/open-projects-process/#releases-and-group-releases-designation of the Oasis Open Project Rules states PGB approves official Releases & Group Releases which they define as “a
collection of links to resources within the project that enable the Project
Governing Board to deliver software to users.”
I’m not doing this to be a pain on terminology (albeit I think if we got our terms straight, our lives would be easier) – I just want to follow the rules and get stuff out
there and celebrate the accomplishments to suck others into joining.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
From:
oca-pgb@... <oca-pgb@...> on behalf of Richard F. Nelson via lists.oasis-open-projects.org <RICHARD.F.NELSON=saic.com@...>
Date: Monday, October 24, 2022 at 10:36 AM
To: oca-pgb@... <oca-pgb@...>, oca-tsc@... <oca-tsc@...>
Subject: Re: [oca-tsc] [oca-pgb] OCA work products
New guy point of view… It seems to me that TC should/would be responsible for engineering releases, beta releases etc. and govern/manage those as they see fit.
Once they feel they have a “Viable Product”, which is loosely defined by them based on their goals and objectives. Then, they should involve the PGB and, I assume, would illustrate to the PGB how they have achieved some/all of the goals they set out to accomplish.
PGB would approve/advise/guide/commend those efforts via some criteria as well as help them “get the word out”. Do we have such a process in place or are we looking to get one going here?
I should also include, that I agree with the points being made on this thread. We should be looking to get product/tools/etc. out in the public for use, feedback
and improvements as well as increasing visibility of the group(s) and hopefully also increasing involvement at many levels.
My $0.02. Hope it’s helpful.
--
Regards,
Rich
--------------------------------------------------------
SAIC - Charleston, SC
Phone: 843-746-6149 {Direct Line}
--------------------------------------------------------
Need Cyber Help or just more Cyber Info?
DIF Cyber Portal:
https://cyber.digital.saicif.com
toggle quoted message
Show quoted text
From: oca-pgb@... <oca-pgb@...>
On Behalf Of Chet Ensign
Sent: Monday, October 24, 2022 10:18 AM
To: oca-tsc@...
Cc: oca-pgb@...
Subject: [EXTERNAL] Re: [oca-tsc] [oca-pgb] OCA work products
EXTERNAL EMAIL -- This message originates from outside of SAIC
Duncan, it sounds like this parallels TC process work. Iterate a series of Working Drafts which could increment version numbers, e.g. 1.0.1, 1.0.2 up to the point where you think it is developed enough to present to the TSC. I'd suggest
the TSC do the approval of incremental enhancements and then, when you're ready, the TSC send it to the PGB with the recommendation that it be approved as a Project Specification Draft. (Assuming, of course, that the PGB has been briefed on progress from time
to time.) In other words, move it to the PGB level when you consider it done from your point of view.
On Mon, Oct 24, 2022 at 10:05 AM duncan@sfractal <duncan@...> wrote:
Jason (and I cc’d TSC as well original PGB).
Agree it’s the TSC that brings to PGB for approval after a project brings it to TSC. I’m just prompting people should look at this (ie not forget
our purpose is to create work products) which might help get others involved, or at least aware of our projects and start using them.
Wrt your gate criteria for a release: At the far end of the scale (standard), the bar should probably be fairly high, but I’d suggest for the near
end (release) the bar be fairly low (ie approve incrementally more often). And I think getting to a ‘first release’ (presume it would be called 1.0.0) would be good even if it’s “incomplete”. And then PGB approving “dot releases” (e.g. 1.1) that add features
would be more often (monthly probably too many, but somewhere in quarterly to annually) would be good. And obviously breaking changes (eg 2.0.0) should be approved as soon as agreed to. If we’d have a lot of breaking changes, then I agree it would be better
to wait until stable.
TSC:
See thread below. Your thoughts of releases (lowest level of approval for open projects, followed by draft project specification, project specification,
and OASIS standard). I’m not proposing people jump right to standard but I am suggesting we should consider putting out releases on our subprojects (or at least plan when we might do so).
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
The TSC would need to guide that question.
-
I do not know what the gate criteria would be to tag a 1.0 release in any of the core projects, it would be a TSC question.
-
In theory the Kestrel language could eventually be a standard but I know there are some changes coming. Again the TSC should guide when they think it is stable enough to start that journey.
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work
products ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work products
ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC standard just approved by PGB instead of a TC). I just sent an email to PACE list about work products I think PACE should be producing. Are either stixshifter or
kestrel at a point where they should be considering PGB approving a release? Note approving stuff might rate OASIS news release and might spur some interest both in participating and in using the open source.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
--
|
|
Chet Ensign
Chief Technical Community Steward
OASIS Open
|
|
|
|
|
The information contained in this e-mail and any attachments from Science Applications International Corporation ("SAIC") may contain confidential and/or proprietary information,
and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in
error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.
|
|
|
New guy point of view… It seems to me that TC should/would be responsible for engineering releases, beta releases etc. and govern/manage those as they see fit.
Once they feel they have a “Viable Product”, which is loosely defined by them based on their goals and objectives. Then, they should involve the PGB and, I assume, would illustrate to the PGB how they have achieved some/all of the goals they set out to accomplish.
PGB would approve/advise/guide/commend those efforts via some criteria as well as help them “get the word out”. Do we have such a process in place or are we looking to get one going here?
I should also include, that I agree with the points being made on this thread. We should be looking to get product/tools/etc. out in the public for use, feedback
and improvements as well as increasing visibility of the group(s) and hopefully also increasing involvement at many levels.
My $0.02. Hope it’s helpful.
--
Regards,
Rich
--------------------------------------------------------
SAIC - Charleston, SC
Phone: 843-746-6149 {Direct Line}
--------------------------------------------------------
Need Cyber Help or just more Cyber Info?
DIF Cyber Portal:
https://cyber.digital.saicif.com
toggle quoted message
Show quoted text
From: oca-pgb@... <oca-pgb@...>
On Behalf Of Chet Ensign
Sent: Monday, October 24, 2022 10:18 AM
To: oca-tsc@...
Cc: oca-pgb@...
Subject: [EXTERNAL] Re: [oca-tsc] [oca-pgb] OCA work products
EXTERNAL EMAIL -- This message originates from outside of SAIC
Duncan, it sounds like this parallels TC process work. Iterate a series of Working Drafts which could increment version numbers, e.g. 1.0.1, 1.0.2 up to the point where you think it is developed enough to present to the TSC. I'd suggest
the TSC do the approval of incremental enhancements and then, when you're ready, the TSC send it to the PGB with the recommendation that it be approved as a Project Specification Draft. (Assuming, of course, that the PGB has been briefed on progress from time
to time.) In other words, move it to the PGB level when you consider it done from your point of view.
On Mon, Oct 24, 2022 at 10:05 AM duncan@sfractal <duncan@...> wrote:
Jason (and I cc’d TSC as well original PGB).
Agree it’s the TSC that brings to PGB for approval after a project brings it to TSC. I’m just prompting people should look at this (ie not forget
our purpose is to create work products) which might help get others involved, or at least aware of our projects and start using them.
Wrt your gate criteria for a release: At the far end of the scale (standard), the bar should probably be fairly high, but I’d suggest for the near
end (release) the bar be fairly low (ie approve incrementally more often). And I think getting to a ‘first release’ (presume it would be called 1.0.0) would be good even if it’s “incomplete”. And then PGB approving “dot releases” (e.g. 1.1) that add features
would be more often (monthly probably too many, but somewhere in quarterly to annually) would be good. And obviously breaking changes (eg 2.0.0) should be approved as soon as agreed to. If we’d have a lot of breaking changes, then I agree it would be better
to wait until stable.
TSC:
See thread below. Your thoughts of releases (lowest level of approval for open projects, followed by draft project specification, project specification,
and OASIS standard). I’m not proposing people jump right to standard but I am suggesting we should consider putting out releases on our subprojects (or at least plan when we might do so).
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
The TSC would need to guide that question.
-
I do not know what the gate criteria would be to tag a 1.0 release in any of the core projects, it would be a TSC question.
-
In theory the Kestrel language could eventually be a standard but I know there are some changes coming. Again the TSC should guide when they think it is stable enough to start that journey.
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work
products ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work products
ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC standard just approved by PGB instead of a TC). I just sent an email to PACE list about work products I think PACE should be producing. Are either stixshifter or
kestrel at a point where they should be considering PGB approving a release? Note approving stuff might rate OASIS news release and might spur some interest both in participating and in using the open source.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
--
|
|
Chet Ensign
Chief Technical Community Steward
OASIS Open
|
|
|
|
|
The information contained in this e-mail and any attachments from Science Applications International Corporation ("SAIC") may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed.
If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete
the e-mail and any attachments.
|
|
|
The PGB does not approve dot releases. If the PGB gets into approving dot releases it would add a ridiculous amount of overhead. Dot releases happen on a very regular basis (timespan of weeks or less). We do not want to get into this, at
all.
Releases that go to PGB level should be few and far between – major releases only.
-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management | www.ibm.com/security
Assistant - Mauricio Durán Cambronero (mauduran@...)
Co-Chair - Open Cybersecurity Alliance, Project Governing Board
www.opencybersecurityalliance.org
From:
oca-pgb@... <oca-pgb@...> on behalf of Chet Ensign <chet.ensign@...>
Date: Monday, October 24, 2022 at 11:18 AM
To: oca-tsc@... <oca-tsc@...>
Cc: oca-pgb@... <oca-pgb@...>
Subject: [EXTERNAL] Re: [oca-tsc] [oca-pgb] OCA work products
Duncan, it sounds like this parallels TC process work. Iterate a series of Working Drafts which could increment version numbers, e. g. 1. 0. 1, 1. 0. 2 up to the
point where you think it is developed enough to present to the TSC. I'd suggest
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Duncan, it sounds like this parallels TC process work. Iterate a series of Working Drafts which could increment version numbers, e.g. 1.0.1, 1.0.2 up to the point where you think it is developed enough to present to the TSC. I'd suggest
the TSC do the approval of incremental enhancements and then, when you're ready, the TSC send it to the PGB with the recommendation that it be approved as a Project Specification Draft. (Assuming, of course, that the PGB has been briefed on progress from time
to time.) In other words, move it to the PGB level when you consider it done from your point of view.
toggle quoted message
Show quoted text
On Mon, Oct 24, 2022 at 10:05 AM duncan@sfractal < duncan@...> wrote:
Jason (and I cc’d TSC as well original PGB).
Agree it’s the TSC that brings to PGB for approval after a project brings it to TSC. I’m just prompting people should look at this (ie not forget our purpose is to create work products)
which might help get others involved, or at least aware of our projects and start using them.
Wrt your gate criteria for a release: At the far end of the scale (standard), the bar should probably be fairly high, but I’d suggest for the near end (release) the bar be fairly
low (ie approve incrementally more often). And I think getting to a ‘first release’ (presume it would be called 1.0.0) would be good even if it’s “incomplete”. And then PGB approving “dot releases” (e.g. 1.1) that add features would be more often (monthly
probably too many, but somewhere in quarterly to annually) would be good. And obviously breaking changes (eg 2.0.0) should be approved as soon as agreed to. If we’d have a lot of breaking changes, then I agree it would be better to wait until stable.
TSC:
See thread below. Your thoughts of releases (lowest level of approval for open projects, followed by draft project specification, project specification, and OASIS standard). I’m
not proposing people jump right to standard but I am suggesting we should consider putting out releases on our subprojects (or at least plan when we might do so).
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
The TSC would need to guide that question.
-
I do not know what the gate criteria would be to tag a 1.0 release in any of the core projects, it would be a TSC question.
-
In theory the Kestrel language could eventually be a standard but I know there are some changes coming. Again the TSC should guide when they think it is stable enough to start that journey.
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work
products ie releases (like TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work products ie releases (like TC WD), project
specifications (like TC CSC), or OASIS Standards (same as TC standard just approved by PGB instead of a TC). I just sent an email to PACE list about work products I think PACE should be producing. Are either stixshifter or kestrel at a point where they should
be considering PGB approving a release? Note approving stuff might rate OASIS news release and might spur some interest both in participating and in using the open source.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
--
|
|
Chet Ensign
Chief Technical Community Steward
OASIS Open
|
|
|
|
|
|
|
|
Duncan, it sounds like this parallels TC process work. Iterate a series of Working Drafts which could increment version numbers, e.g. 1.0.1, 1.0.2 up to the point where you think it is developed enough to present to the TSC. I'd suggest the TSC do the approval of incremental enhancements and then, when you're ready, the TSC send it to the PGB with the recommendation that it be approved as a Project Specification Draft. (Assuming, of course, that the PGB has been briefed on progress from time to time.) In other words, move it to the PGB level when you consider it done from your point of view.
/chet
On Mon, Oct 24, 2022 at 10:05 AM duncan@sfractal < duncan@...> wrote:
Jason (and I cc’d TSC as well original PGB).
Agree it’s the TSC that brings to PGB for approval after a project brings it to TSC. I’m just prompting people should look at this (ie not forget our purpose is to create work products) which might help get
others involved, or at least aware of our projects and start using them.
Wrt your gate criteria for a release: At the far end of the scale (standard), the bar should probably be fairly high, but I’d suggest for the near end (release) the bar be fairly low (ie approve incrementally
more often). And I think getting to a ‘first release’ (presume it would be called 1.0.0) would be good even if it’s “incomplete”. And then PGB approving “dot releases” (e.g. 1.1) that add features would be more often (monthly probably too many, but somewhere
in quarterly to annually) would be good. And obviously breaking changes (eg 2.0.0) should be approved as soon as agreed to. If we’d have a lot of breaking changes, then I agree it would be better to wait until stable.
TSC:
See thread below. Your thoughts of releases (lowest level of approval for open projects, followed by draft project specification, project specification, and OASIS standard). I’m not proposing people jump right
to standard but I am suggesting we should consider putting out releases on our subprojects (or at least plan when we might do so).
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
The TSC would need to guide that question.
- I do not know what the gate criteria would be to tag a 1.0 release in any of the core projects, it would be a TSC question.
- In theory the Kestrel language could eventually be a standard but I know there are some changes coming. Again the TSC should guide when they think it
is stable enough to start that journey.
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work products ie releases (like
TC WD), project specifications (like TC CSC), or OASIS Standards (same as TC
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Is any of the work in the OCA ready yet to progress for any sort of approval yet? If I understand correctly, we have no approved OCA work products ie releases (like TC WD), project specifications (like TC
CSC), or OASIS Standards (same as TC standard just approved by PGB instead of a TC). I just sent an email to PACE list about work products I think PACE should be producing. Are either stixshifter or kestrel at a point where they should be considering PGB approving
a release? Note approving stuff might rate OASIS news release and might spur some interest both in participating and in using the open source.
--
Duncan Sparrell
sFractal Consulting
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
-- | Chet EnsignChief Technical Community Steward OASIS Open | | | | |
|
|
|
