You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/08/09 18:20:54 UTC
ASF maturity model.
Hi.
I just spent a few hours having fun.
I made a wiki page, with the maturity model
https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
Actually quite an interesting job. Please have a look at my responses, and
let us see where we
end up.
I found some of the questions, directly wrong or at the very least
misleading. I also lacked some questions about how the community is
actually doing.
My intention is to see your reactions (and incorporate that), and then
start a new discussion on general@ because if this is something podlings
should fill up, some of the questions need to
be changed or better documented.
rgds
jan i.
Re: ASF maturity model.
Posted by Ian C <ia...@amham.net>.
On Mon, Aug 10, 2015 at 7:23 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 09/08/2015 jan i wrote:
>>
>> I made a wiki page, with the maturity model
>>
>> https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
>
For what it's worth I read through that and did not raise any concerns.
>
> Many of your findings and questions can probably be solved by defining what
> "maturity" means. To me, being "mature" is not a requirement for graduation,
> and the discussion on using it as a guideline for exiting the Incubator does
> not mean that a podling is expected to pass all checks, because some of them
> only make sense for a "mature" project.
>
> A couple examples just to make my opinion clearer:
> - Backwards compatibility is a concern for a "mature" project; for sure, not
> for a podling that hasn't got to version 0.1 yet.
> - Maintaining the PMC list becomes (the Chair is the person who gives/add
> privileges) a project's duty after graduation.
> - Security and other user-facing concerns apply to a project that has a
> stable users base; I consider this to be a sign that a project is "mature",
> but I don't see it as a requirement for graduation.
>
> Also, remember that the maturity model is not of super-human origin: it was
> written by a Board member as soon as last year. It can be changed as needed.
> It can be customized for podlings if some items do not make sense for
> podlings; but I don't see it as a "must have" requirement for a podling to
> graduate. (That said, my vote on these matters is not binding, so this is
> just an opinion).
>
> Regards,
> Andrea.
--
Cheers,
Ian C
Re: ASF maturity model.
Posted by Andrea Pescetti <pe...@apache.org>.
On 09/08/2015 jan i wrote:
> I made a wiki page, with the maturity model
> https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
Many of your findings and questions can probably be solved by defining
what "maturity" means. To me, being "mature" is not a requirement for
graduation, and the discussion on using it as a guideline for exiting
the Incubator does not mean that a podling is expected to pass all
checks, because some of them only make sense for a "mature" project.
A couple examples just to make my opinion clearer:
- Backwards compatibility is a concern for a "mature" project; for sure,
not for a podling that hasn't got to version 0.1 yet.
- Maintaining the PMC list becomes (the Chair is the person who
gives/add privileges) a project's duty after graduation.
- Security and other user-facing concerns apply to a project that has a
stable users base; I consider this to be a sign that a project is
"mature", but I don't see it as a requirement for graduation.
Also, remember that the maturity model is not of super-human origin: it
was written by a Board member as soon as last year. It can be changed as
needed. It can be customized for podlings if some items do not make
sense for podlings; but I don't see it as a "must have" requirement for
a podling to graduate. (That said, my vote on these matters is not
binding, so this is just an opinion).
Regards,
Andrea.
Re: ASF maturity model.
Posted by Peter Kelly <pm...@apache.org>.
> On 10 Aug 2015, at 12:05 am, jan i <ja...@apache.org> wrote:
>
> As I think you noticed, this will be basis of a new voting discussion in
> Incubator. And also to get some of the wording made more precise.
The first step on that would be to replace my accidental wording “the policy decides on a policy” with "the podling decides on a policy” ;)
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: ASF maturity model.
Posted by jan i <ja...@apache.org>.
WOW, thanks for a lot of comments, I will later try to integrate your
comments with mine, and then hope we are both "happy".
Thanks for taking time.
As I think you noticed, this will be basis of a new voting discussion in
Incubator. And also to get some of the wording made more precise.
rgds
jan I.
On 9 August 2015 at 18:46, Peter Kelly <pm...@apache.org> wrote:
> Here are my thoughts on the questions/responses:
>
> CD20: "The project's code is easily discoverable and publicly accessible."
>
> Perhaps provide a link to the repository as evidence
>
> LC30: (your comment) "The definition of libraries seems to be missing,
> when developing for e.g. MS-Windows or OS-X all kind of closed source
> libraries are part of the linking (at least in the C/C++ world). Is library
> only a loose term for something installed extra on the target platform, and
> the builtin libraries do not count ?"
>
> Although the intention (as I understand it) of preventing projects from
> requiring LGPL licenses makes sense, in practice it has the effect of
> encouraging projects to rely instead on APIs that are provided only by
> proprietary operatings systems. For example instead of using Qt and having
> an editor which everyone can use, it may be that we end up (for example)
> distributing an editor that uses Apple's Cocoa API (to avoid violating the
> rules) and can only be used by people who buy expensive Mac hardware. Seems
> like a bit of an own goal.
>
> QU10: "The project is open and honest about the quality of its code.
> Various levels of quality and maturity for various modules are natural and
> acceptable as long as they are clearly communicated."
>
> I would add to your comment that we've mentioned in the README which parts
> of the code are mature (specifically the MS word support), and that we've
> mentioned additional immature/early stage components that are in
> development but not but part of the release.
>
> QU20: (your response) "For a library project like Corinthia, "secure
> software" is not a demand, however "stable" software is in high demand."
>
> I would argue that security is a priority, in the form of avoiding
> vulnerabilities. That is, if a buffer overflow attack or similar exploit is
> found, this could have the usual serious implications for applications
> using the Library, as we see on a regular basis for other libraries.
>
> You could mention that we are developing a special-purpose domain-specific
> programming language (Flat) in which to express much of the work Corinthia
> does, which will avoid entire classes of bugs that are possible in C. So
> this will help a lot to reduce the chance of exploits.
>
> QU30: "The project provides a well-documented channel to report security
> issues, along with a documented way of responding to them."
>
> Could we set up a dedicated email address which forwards to the private
> mailing list?
>
> CO10: (your response) "Why is it "well known" a demand ? it is quite hard
> to be "well known" when you are in a startup phase."
>
> I think they just mean easily-identifiable - I would consider
> http://corinthia.incubator.apache.org to be sufficient for this
> requirement, though I agree it's worded badly. And how many people need to
> know the address for it to be considered "well known" - I don't even know
> the address of Maven or CouchDB, and would just use Goole for convenience
> (I could probably guess <project-name>.apache.org but google is easier).
>
> I think the intention of this question is it's not something like
> http://www.adelaide.edu.au/~pmk/research/projects/2012/foo-main.html
>
> C050 (your reponse) - I agree with this and it should be clarified (even
> if it's "the policy decides on a policy, possibly with approval from IPMC")
>
>
> CS10 (your response): "Why would the project maintain a public list ? this
> is done at ASF level (people.a.o)"
>
> I agree it isn't stricly necessary, but I see no harm in doing this on the
> website or wiki for convienient access.
>
> CS30 (your response): "We believed using standard ASF rules was enough,
> but when 2 directors and 3 foundation members cannot agree on how a PPMC
> vote works, then there is a need for local rules (or even better correct
> the ASF wide rules)"
>
> A very good point indeed :)
>
> CS40: "In Apache projects, vetoes are only valid for code commits and are
> justified by a technical explanation, as per the Apache voting rules
> defined in CS30."
>
> Well, this is interesting...
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
> > On 9 Aug 2015, at 11:20 pm, jan i <ja...@apache.org> wrote:
> >
> > Hi.
> >
> > I just spent a few hours having fun.
> >
> > I made a wiki page, with the maturity model
> >
> https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
> >
> > Actually quite an interesting job. Please have a look at my responses,
> and
> > let us see where we
> > end up.
> >
> > I found some of the questions, directly wrong or at the very least
> > misleading. I also lacked some questions about how the community is
> > actually doing.
> >
> > My intention is to see your reactions (and incorporate that), and then
> > start a new discussion on general@ because if this is something podlings
> > should fill up, some of the questions need to
> > be changed or better documented.
> >
> > rgds
> > jan i.
>
>
Re: ASF maturity model.
Posted by jan i <ja...@apache.org>.
On 9 August 2015 at 19:42, Dennis E. Hamilton <de...@acm.org>
wrote:
> General remark:
>
> My sense is that an assessment against the ASF maturity model is in
> addition to other requirements for graduation from the incubator.
>
I think you are right here...for me it was a experiment (I made it too for
another project we both know). I know there is a big discussion in IPMC and
Incubator
about graduation so it was an experiment to see how honest I could be.
For sure when we come closer to graduation, all the question marks should
be replaced with "yes, we interpret it as ....".
>
> Also, the footnotes matter. The Model is meant to be generic, which is
> why it does not go down to specifics about libraries, etc.
>
I did read the footnotes, but found e.g. no explanation about libraries.
And if you use the generic term libraries, where do we stop ?
>
> I also think that it will be very ASF-friendly if assessment remarks
> simply declare how a particular element is taken to apply, and where
> supporting information about further details is found.
>
I am not sure I understand what you mean, I have tried to keep answer
neutral, and commented below, but maybe you mean something different ?
rgds
jan I.
>
> - Dennis
>
> [ ... ]
>
> > On 9 Aug 2015, at 11:20 pm, jan i <ja...@apache.org> wrote:
> >
> > Hi.
> >
> > I just spent a few hours having fun.
> >
> > I made a wiki page, with the maturity model
> >
> https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
> >
> > Actually quite an interesting job. Please have a look at my responses,
> and
> > let us see where we
> > end up.
> >
> > I found some of the questions, directly wrong or at the very least
> > misleading. I also lacked some questions about how the community is
> > actually doing.
> >
> > My intention is to see your reactions (and incorporate that), and then
> > start a new discussion on general@ because if this is something podlings
> > should fill up, some of the questions need to
> > be changed or better documented.
> >
> > rgds
> > jan i.
>
>
>
RE: ASF maturity model.
Posted by "Dennis E. Hamilton" <de...@acm.org>.
General remark:
My sense is that an assessment against the ASF maturity model is in addition to other requirements for graduation from the incubator.
Also, the footnotes matter. The Model is meant to be generic, which is why it does not go down to specifics about libraries, etc.
I also think that it will be very ASF-friendly if assessment remarks simply declare how a particular element is taken to apply, and where supporting information about further details is found.
- Dennis
[ ... ]
> On 9 Aug 2015, at 11:20 pm, jan i <ja...@apache.org> wrote:
>
> Hi.
>
> I just spent a few hours having fun.
>
> I made a wiki page, with the maturity model
> https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
>
> Actually quite an interesting job. Please have a look at my responses, and
> let us see where we
> end up.
>
> I found some of the questions, directly wrong or at the very least
> misleading. I also lacked some questions about how the community is
> actually doing.
>
> My intention is to see your reactions (and incorporate that), and then
> start a new discussion on general@ because if this is something podlings
> should fill up, some of the questions need to
> be changed or better documented.
>
> rgds
> jan i.
Re: ASF maturity model.
Posted by Peter Kelly <pm...@apache.org>.
Here are my thoughts on the questions/responses:
CD20: "The project's code is easily discoverable and publicly accessible."
Perhaps provide a link to the repository as evidence
LC30: (your comment) "The definition of libraries seems to be missing, when developing for e.g. MS-Windows or OS-X all kind of closed source libraries are part of the linking (at least in the C/C++ world). Is library only a loose term for something installed extra on the target platform, and the builtin libraries do not count ?"
Although the intention (as I understand it) of preventing projects from requiring LGPL licenses makes sense, in practice it has the effect of encouraging projects to rely instead on APIs that are provided only by proprietary operatings systems. For example instead of using Qt and having an editor which everyone can use, it may be that we end up (for example) distributing an editor that uses Apple's Cocoa API (to avoid violating the rules) and can only be used by people who buy expensive Mac hardware. Seems like a bit of an own goal.
QU10: "The project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated."
I would add to your comment that we've mentioned in the README which parts of the code are mature (specifically the MS word support), and that we've mentioned additional immature/early stage components that are in development but not but part of the release.
QU20: (your response) "For a library project like Corinthia, "secure software" is not a demand, however "stable" software is in high demand."
I would argue that security is a priority, in the form of avoiding vulnerabilities. That is, if a buffer overflow attack or similar exploit is found, this could have the usual serious implications for applications using the Library, as we see on a regular basis for other libraries.
You could mention that we are developing a special-purpose domain-specific programming language (Flat) in which to express much of the work Corinthia does, which will avoid entire classes of bugs that are possible in C. So this will help a lot to reduce the chance of exploits.
QU30: "The project provides a well-documented channel to report security issues, along with a documented way of responding to them."
Could we set up a dedicated email address which forwards to the private mailing list?
CO10: (your response) "Why is it "well known" a demand ? it is quite hard to be "well known" when you are in a startup phase."
I think they just mean easily-identifiable - I would consider http://corinthia.incubator.apache.org to be sufficient for this requirement, though I agree it's worded badly. And how many people need to know the address for it to be considered "well known" - I don't even know the address of Maven or CouchDB, and would just use Goole for convenience (I could probably guess <project-name>.apache.org but google is easier).
I think the intention of this question is it's not something like http://www.adelaide.edu.au/~pmk/research/projects/2012/foo-main.html
C050 (your reponse) - I agree with this and it should be clarified (even if it's "the policy decides on a policy, possibly with approval from IPMC")
CS10 (your response): "Why would the project maintain a public list ? this is done at ASF level (people.a.o)"
I agree it isn't stricly necessary, but I see no harm in doing this on the website or wiki for convienient access.
CS30 (your response): "We believed using standard ASF rules was enough, but when 2 directors and 3 foundation members cannot agree on how a PPMC vote works, then there is a need for local rules (or even better correct the ASF wide rules)"
A very good point indeed :)
CS40: "In Apache projects, vetoes are only valid for code commits and are justified by a technical explanation, as per the Apache voting rules defined in CS30."
Well, this is interesting...
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 9 Aug 2015, at 11:20 pm, jan i <ja...@apache.org> wrote:
>
> Hi.
>
> I just spent a few hours having fun.
>
> I made a wiki page, with the maturity model
> https://cwiki.apache.org/confluence/display/Corinthia/The+Apache+Project+Maturity+Model
>
> Actually quite an interesting job. Please have a look at my responses, and
> let us see where we
> end up.
>
> I found some of the questions, directly wrong or at the very least
> misleading. I also lacked some questions about how the community is
> actually doing.
>
> My intention is to see your reactions (and incorporate that), and then
> start a new discussion on general@ because if this is something podlings
> should fill up, some of the questions need to
> be changed or better documented.
>
> rgds
> jan i.