I am new to protocols here and not sure which thread to jump on. But I am
quite interested in the viability of the math project and hope the following observation is helpful. I think one reason people are talking past each other in this debate is because those outside the commons-math community may be thinking more about commons-math classes like Median and those within it may be more concerned with commons-math classes like AkimaSplineInterpolator. In the case of Median, the fit to the commons mission is quite clear. It's a simple function that is widely needed and used but not in the Java API. Commons as a whole is strengthened by classes like Median, and commons-math is strengthened by being in the commons framework. And Median, probably any of us could maintain. But a class like AkimaSplineInterpolator is a different matter. In that case the fit with the commons mission is less clear. And in the case of classes like AkimaSplineInterpolator, Gilles is right. It doesn't make sense to carry a method like that forward to the next version of a package, if there is no one around who even knows what an Akima spline is, let alone can defend the methodology in the library or its accuracy. One can't have a credible library for scientific computing if it contains methods, for which no present maintainer can guarantee the accuracy or effectiveness. In such case, such a class should probably be mothballed in the next release, or spun off to be maintained by someone who knows what they are doing. (I have offered to maintain the interpolators BTW.) So I actually see Gilles' proposal for spin-off packages as solving a fundamental dischord in the way commons-math is set up. At the risk of adding yet another proposal to the mix, what about deciding which of the Math classes suit the commons mission, and are of fairly wide currency such that developers from other packages in commons who have offered their help could probably maintain them just as easily. This makes for a core CM. Then for the rich array of more sophisticated classes that prompted calls for a TLP math in the first place -- I can certainly understand the impulse -- only one of two possibilities exists. Either a new community needs to be built through incubator, or the classes with current support need to be spun off, and new releases of those classes overseen by people who understand them and want to manage them. Gilles feels a trip through the incubator is unlikely to bring new mathematicians into the fold who want to maintain an omnibus math package. His instinct here aligns with what I've seen empirically over the last few months -- myself, Artem, syenkoc all have our particular agendas and niches of interest that we want to maintain. Gilles says it was ever thus, and I see no reason to doubt his knowledge of the history. So if the days of a core of several omnibus maintainers are over, we should go with the other logical plan which is to spin off the fancier interpolators, solvers, etc. -- classes that exceed the commons mission -- into classes that have someone who understands them and wants to support then, and classes which get mothballed for 4.0 . I think this makes a lot of sense. I would only add that I think that all the math-related classes, as well as all of commons, benefits from some sort of commons-math core classes that we are sure belong in commons. And then there is no more debate about whether someone is trying to destroy commons-math, which quickly becomes acrimonious. I think this is a partitioning we could all achieve. We can vote on every math package if you like! Eric |
Hi Eric.
Thanks for a refreshing viewpoint! Gilles On Sat, 18 Jun 2016 20:22:24 +0200, Eric Barnhill wrote: > I am new to protocols here and not sure which thread to jump on. But > I am > quite interested in the viability of the math project and hope the > following observation is helpful. > > I think one reason people are talking past each other in this debate > is > because those outside the commons-math community may be thinking more > about > commons-math classes like Median and those within it may be more > concerned > with commons-math classes like AkimaSplineInterpolator. > > In the case of Median, the fit to the commons mission is quite clear. > It's > a simple function that is widely needed and used but not in the Java > API. > Commons as a whole is strengthened by classes like Median, and > commons-math > is strengthened by being in the commons framework. And Median, > probably any > of us could maintain. > > But a class like AkimaSplineInterpolator is a different matter. In > that > case the fit with the commons mission is less clear. And in the case > of > classes like AkimaSplineInterpolator, Gilles is right. It doesn't > make > sense to carry a method like that forward to the next version of a > package, > if there is no one around who even knows what an Akima spline is, let > alone > can defend the methodology in the library or its accuracy. One can't > have > a credible library for scientific computing if it contains methods, > for > which no present maintainer can guarantee the accuracy or > effectiveness. In > such case, such a class should probably be mothballed in the next > release, > or spun off to be maintained by someone who knows what they are > doing. (I > have offered to maintain the interpolators BTW.) > > So I actually see Gilles' proposal for spin-off packages as solving a > fundamental dischord in the way commons-math is set up. At the risk > of > adding yet another proposal to the mix, what about deciding which of > the > Math classes suit the commons mission, and are of fairly wide > currency such > that developers from other packages in commons who have offered their > help > could probably maintain them just as easily. This makes for a core > CM. Then > for the rich array of more sophisticated classes that prompted calls > for a > TLP math in the first place -- I can certainly understand the impulse > -- > only one of two possibilities exists. Either a new community needs to > be > built through incubator, or the classes with current support need to > be > spun off, and new releases of those classes overseen by people who > understand them and want to manage them. > > Gilles feels a trip through the incubator is unlikely to bring new > mathematicians into the fold who want to maintain an omnibus math > package. > His instinct here aligns with what I've seen empirically over the > last few > months -- myself, Artem, syenkoc all have our particular agendas and > niches > of interest that we want to maintain. Gilles says it was ever thus, > and I > see no reason to doubt his knowledge of the history. > > So if the days of a core of several omnibus maintainers are over, we > should > go with the other logical plan which is to spin off the fancier > interpolators, solvers, etc. -- classes that exceed the commons > mission -- > into classes that have someone who understands them and wants to > support > then, and classes which get mothballed for 4.0 . I think this makes a > lot > of sense. > > I would only add that I think that all the math-related classes, as > well > as all of commons, benefits from some sort of commons-math core > classes > that we are sure belong in commons. And then there is no more debate > about > whether someone is trying to destroy commons-math, which quickly > becomes > acrimonious. I think this is a partitioning we could all achieve. We > can > vote on every math package if you like! > > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Eric Barnhill
Thanks, Eric.
I am OK with Commons Math being split into modules in the Commons Math sub-project. I am not OK with Commons Math A, Commons Math B, etc existing within Commons. In other words, when a user traverses to Commons Math they can then see the modules that make up Commons Math. I am also OK with code being mothballed if no one knows what it does, how it works, why it exists or who may want to use it. I am not OK with retiring code just because a single person doesn’t know what it does or how to maintain it. In other words, I am looking for people like you to volunteer to be part of the community that decides what should stay and what should go. IMO, that community needs to be of sufficient size that it is somewhat representative of the users of Commons Math. That doesn’t mean it necessarily needs 10 people, but I would say it needs more than 2. The side effect of this, is that once you have a community that can start making these kinds of decisions you can also make a proposal to go to the incubator or become a TLP (there is really no reason a project can’t “incubate” here in Commons). Ralph > On Jun 18, 2016, at 11:22 AM, Eric Barnhill <[hidden email]> wrote: > > I am new to protocols here and not sure which thread to jump on. But I am > quite interested in the viability of the math project and hope the > following observation is helpful. > > I think one reason people are talking past each other in this debate is > because those outside the commons-math community may be thinking more about > commons-math classes like Median and those within it may be more concerned > with commons-math classes like AkimaSplineInterpolator. > > In the case of Median, the fit to the commons mission is quite clear. It's > a simple function that is widely needed and used but not in the Java API. > Commons as a whole is strengthened by classes like Median, and commons-math > is strengthened by being in the commons framework. And Median, probably any > of us could maintain. > > But a class like AkimaSplineInterpolator is a different matter. In that > case the fit with the commons mission is less clear. And in the case of > classes like AkimaSplineInterpolator, Gilles is right. It doesn't make > sense to carry a method like that forward to the next version of a package, > if there is no one around who even knows what an Akima spline is, let alone > can defend the methodology in the library or its accuracy. One can't have > a credible library for scientific computing if it contains methods, for > which no present maintainer can guarantee the accuracy or effectiveness. In > such case, such a class should probably be mothballed in the next release, > or spun off to be maintained by someone who knows what they are doing. (I > have offered to maintain the interpolators BTW.) > > So I actually see Gilles' proposal for spin-off packages as solving a > fundamental dischord in the way commons-math is set up. At the risk of > adding yet another proposal to the mix, what about deciding which of the > Math classes suit the commons mission, and are of fairly wide currency such > that developers from other packages in commons who have offered their help > could probably maintain them just as easily. This makes for a core CM. Then > for the rich array of more sophisticated classes that prompted calls for a > TLP math in the first place -- I can certainly understand the impulse -- > only one of two possibilities exists. Either a new community needs to be > built through incubator, or the classes with current support need to be > spun off, and new releases of those classes overseen by people who > understand them and want to manage them. > > Gilles feels a trip through the incubator is unlikely to bring new > mathematicians into the fold who want to maintain an omnibus math package. > His instinct here aligns with what I've seen empirically over the last few > months -- myself, Artem, syenkoc all have our particular agendas and niches > of interest that we want to maintain. Gilles says it was ever thus, and I > see no reason to doubt his knowledge of the history. > > So if the days of a core of several omnibus maintainers are over, we should > go with the other logical plan which is to spin off the fancier > interpolators, solvers, etc. -- classes that exceed the commons mission -- > into classes that have someone who understands them and wants to support > then, and classes which get mothballed for 4.0 . I think this makes a lot > of sense. > > I would only add that I think that all the math-related classes, as well > as all of commons, benefits from some sort of commons-math core classes > that we are sure belong in commons. And then there is no more debate about > whether someone is trying to destroy commons-math, which quickly becomes > acrimonious. I think this is a partitioning we could all achieve. We can > vote on every math package if you like! > > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Thanks Eric for your view and great suggestions!
I agree that more Commons-like codes that are easy enough to understand fit well here, and that more exotic interpolators etc are harder to get into, and would fit better in a mathematician-centric community (Incubator/TLP/Github organisation) with more leverage as to breaking API changes and different release granularities. I think if we start categorizing it could be difficult to draw the line, but I think Gilles "I can (roughly) understand this" is a good criteria to start with. I think it's OK for Commons Maths +1 to have less features, particularly here we know Maths have grown too big. It's possible to later re-add your favourite algorithm, so the documentation would need to clearly show both the ("unsupported") legacy version and the newer more focused version. However I still don't understand the reluctance to release "unsupported code" - we have no support contracts or correctness guarantees. If say AkimaSpline Interpolator has already been released, then why can't it be included in future releases? Any bugs from before would be the same later. I know from experience that it's annoying when repeated updates to open source software haven't fixed your most annoying bug; but then this itch is what can trigger a "perhaps I can fix it then?" reaction. I have not explored the differences, but if it is the case that the master branch have too much experimental code which has never been released and which you don't want to commit to "supporting", how about putting them in an .experimental package? It would be a good indicator that you're on your own, this might break, please come join us to develop these further. If someone finds a bug they care enough about, then perhaps we need to reevaluate why they can't simply contribute a fix (e.g. reluctance to degrade performance) and lower the barriers for becoming part of Math - this is important both inside or outside Commons. We don't need to verify the absolute correctness of the fix; we should rather assume by default the contributor who needs a fix in a particular specific method knows something about its algorithm and try to bring in their knowledge (and hopefully future maintainership). I think we need to keep calm and avoid rushing off with arguments and he said/she said; we don't need to fragment the Math community any further and be realistic with what is a reasonable code base to work with for a smaller/fresher community. I think it's clear that such a community would need some liberty to decide for itself on things like release and update policies and how to structure/modularize it's code, and I think the Incubator would be a good place to try this out. (If it doesn't work out, that is also OK) I think it's also important for us to revisit the assumed requirement of all classes to remain "supported", I can tell you there are many Apache projects that have effectively unsupported modules or packages (stagnant development, lack of knowledge within active committers), but they are part of the regular releases and therefore still are supported in the sense that they still compile and can accept patches. On 19 Jun 2016 12:09 a.m., "Ralph Goers" <[hidden email]> wrote: > Thanks, Eric. > > I am OK with Commons Math being split into modules in the Commons Math > sub-project. I am not OK with Commons Math A, Commons Math B, etc existing > within Commons. In other words, when a user traverses to Commons Math they > can then see the modules that make up Commons Math. > > I am also OK with code being mothballed if no one knows what it does, how > it works, why it exists or who may want to use it. I am not OK with > retiring code just because a single person doesn’t know what it does or how > to maintain it. In other words, I am looking for people like you to > volunteer to be part of the community that decides what should stay and > what should go. IMO, that community needs to be of sufficient size that it > is somewhat representative of the users of Commons Math. That doesn’t mean > it necessarily needs 10 people, but I would say it needs more than 2. > > The side effect of this, is that once you have a community that can start > making these kinds of decisions you can also make a proposal to go to the > incubator or become a TLP (there is really no reason a project can’t > “incubate” here in Commons). > > Ralph > > > On Jun 18, 2016, at 11:22 AM, Eric Barnhill <[hidden email]> > wrote: > > > > I am new to protocols here and not sure which thread to jump on. But I am > > quite interested in the viability of the math project and hope the > > following observation is helpful. > > > > I think one reason people are talking past each other in this debate is > > because those outside the commons-math community may be thinking more > about > > commons-math classes like Median and those within it may be more > concerned > > with commons-math classes like AkimaSplineInterpolator. > > > > In the case of Median, the fit to the commons mission is quite clear. > It's > > a simple function that is widely needed and used but not in the Java API. > > Commons as a whole is strengthened by classes like Median, and > commons-math > > is strengthened by being in the commons framework. And Median, probably > any > > of us could maintain. > > > > But a class like AkimaSplineInterpolator is a different matter. In that > > case the fit with the commons mission is less clear. And in the case of > > classes like AkimaSplineInterpolator, Gilles is right. It doesn't make > > sense to carry a method like that forward to the next version of a > package, > > if there is no one around who even knows what an Akima spline is, let > alone > > can defend the methodology in the library or its accuracy. One can't > have > > a credible library for scientific computing if it contains methods, for > > which no present maintainer can guarantee the accuracy or effectiveness. > In > > such case, such a class should probably be mothballed in the next > release, > > or spun off to be maintained by someone who knows what they are doing. (I > > have offered to maintain the interpolators BTW.) > > > > So I actually see Gilles' proposal for spin-off packages as solving a > > fundamental dischord in the way commons-math is set up. At the risk of > > adding yet another proposal to the mix, what about deciding which of the > > Math classes suit the commons mission, and are of fairly wide currency > such > > that developers from other packages in commons who have offered their > help > > could probably maintain them just as easily. This makes for a core CM. > Then > > for the rich array of more sophisticated classes that prompted calls for > a > > TLP math in the first place -- I can certainly understand the impulse -- > > only one of two possibilities exists. Either a new community needs to be > > built through incubator, or the classes with current support need to be > > spun off, and new releases of those classes overseen by people who > > understand them and want to manage them. > > > > Gilles feels a trip through the incubator is unlikely to bring new > > mathematicians into the fold who want to maintain an omnibus math > package. > > His instinct here aligns with what I've seen empirically over the last > few > > months -- myself, Artem, syenkoc all have our particular agendas and > niches > > of interest that we want to maintain. Gilles says it was ever thus, and I > > see no reason to doubt his knowledge of the history. > > > > So if the days of a core of several omnibus maintainers are over, we > should > > go with the other logical plan which is to spin off the fancier > > interpolators, solvers, etc. -- classes that exceed the commons mission > -- > > into classes that have someone who understands them and wants to support > > then, and classes which get mothballed for 4.0 . I think this makes a lot > > of sense. > > > > I would only add that I think that all the math-related classes, as well > > as all of commons, benefits from some sort of commons-math core classes > > that we are sure belong in commons. And then there is no more debate > about > > whether someone is trying to destroy commons-math, which quickly becomes > > acrimonious. I think this is a partitioning we could all achieve. We can > > vote on every math package if you like! > > > > Eric > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
In reply to this post by Ralph Goers
Hi Ralph,
Ralph Goers wrote: > Thanks, Eric. > > I am OK with Commons Math being split into modules in the Commons Math > sub-project. That was my first idea too. But if the collection of all submodules will in the end nevertheless only contain 20% of the code, we gained nothing. > I am not OK with Commons Math A, Commons Math B, etc existing > within Commons. In other words, when a user traverses to Commons Math they > can then see the modules that make up Commons Math. The main problem seems to be that CM was a dumping ground for all kind of stuff that have at least the slightest relation to a mathematical base. Gilles never expressed it directly, but in its consequence he proposed to move the current CM into dormant/attic and extract single parts of the old code base as new components. Some of those components can be: - Commons RNG (Random Number Generators) - Commons Complex (Complex Numbers) - Commons Matrix (Matrix Algebra) Those components might have an own life, those algorithms have a wide audience and can be used in a lot of stuff on its own. The question is what happens with: - Commons Genetics (Genetic Algorithms) - Commons ML (Machine Learning) Or other stuff requiring deep mathematical background. I don't have the impression this belongs as own components into Commons. Moving CM as whole into a new TLP at least provides a place for all of it. The question is, what do we want as PMC members? > I am also OK with code being mothballed if no one knows what it does, how > it works, why it exists or who may want to use it. I am not OK with > retiring code just because a single person doesn’t know what it does or > how to maintain it. In other words, I am looking for people like you to > volunteer to be part of the community that decides what should stay and > what should go. And this does not require that the code base is separated now before the decisions are made. > IMO, that community needs to be of sufficient size that it > is somewhat representative of the users of Commons Math. That doesn’t mean > it necessarily needs 10 people, but I would say it needs more than 2. Otherwise a TLP will never be accepted. > The side effect of this, is that once you have a community that can start > making these kinds of decisions you can also make a proposal to go to the > incubator or become a TLP (there is really no reason a project can’t > “incubate” here in Commons). +1 Thanks for your thoughts, Eric + Ralph! - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Sun, 19 Jun 2016 19:40:34 +0200, Jörg Schaible wrote:
> Hi Ralph, > > Ralph Goers wrote: > >> Thanks, Eric. >> >> I am OK with Commons Math being split into modules in the Commons >> Math >> sub-project. > > > That was my first idea too. But if the collection of all submodules > will in > the end nevertheless only contain 20% of the code, we gained nothing. > > >> I am not OK with Commons Math A, Commons Math B, etc existing >> within Commons. In other words, when a user traverses to Commons >> Math they >> can then see the modules that make up Commons Math. > > > The main problem seems to be that CM was a dumping ground for all > kind of > stuff that have at least the slightest relation to a mathematical > base. > > Gilles never expressed it directly, but in its consequence he > proposed to > move the current CM into dormant/attic and extract single parts of > the old > code base as new components. Really? I have a hard time figuring out what could have been more direct than the initial post of that thread: http://markmail.org/message/ye6wvqvlvnqe4qrp > > Some of those components can be: > - Commons RNG (Random Number Generators) > - Commons Complex (Complex Numbers) > - Commons Matrix (Matrix Algebra) > > Those components might have an own life, those algorithms have a wide > audience and can be used in a lot of stuff on its own. The question > is what > happens with: > - Commons Genetics (Genetic Algorithms) > - Commons ML (Machine Learning) > > Or other stuff requiring deep mathematical background. I don't have > the > impression this belongs as own components into Commons. Moving CM as > whole > into a new TLP at least provides a place for all of it. > > The question is, what do we want as PMC members? > > >> I am also OK with code being mothballed if no one knows what it >> does, how >> it works, why it exists or who may want to use it. I am not OK with >> retiring code just because a single person doesn’t know what it does >> or >> how to maintain it. In other words, I am looking for people like >> you to >> volunteer to be part of the community that decides what should stay >> and >> what should go. > > > And this does not require that the code base is separated now before > the > decisions are made. > > >> IMO, that community needs to be of sufficient size that it >> is somewhat representative of the users of Commons Math. That >> doesn’t mean >> it necessarily needs 10 people, but I would say it needs more than >> 2. > > > Otherwise a TLP will never be accepted. > > >> The side effect of this, is that once you have a community that can >> start >> making these kinds of decisions you can also make a proposal to go >> to the >> incubator or become a TLP (there is really no reason a project can’t >> “incubate” here in Commons). > > > +1 > > Thanks for your thoughts, Eric + Ralph! > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Jörg Schaible
> On Jun 19, 2016, at 10:40 AM, Jörg Schaible <[hidden email]> wrote: > > Hi Ralph, > > Ralph Goers wrote: > >> Thanks, Eric. >> >> I am OK with Commons Math being split into modules in the Commons Math >> sub-project. > > > That was my first idea too. But if the collection of all submodules will in > the end nevertheless only contain 20% of the code, we gained nothing. > > >> I am not OK with Commons Math A, Commons Math B, etc existing >> within Commons. In other words, when a user traverses to Commons Math they >> can then see the modules that make up Commons Math. > > > The main problem seems to be that CM was a dumping ground for all kind of > stuff that have at least the slightest relation to a mathematical base. > > Gilles never expressed it directly, but in its consequence he proposed to > move the current CM into dormant/attic and extract single parts of the old > code base as new components. Personally, I don’t think moving it to the attic is appropriate. Projects go to the attic, not components. The Math project (or sub-project) is free to add or drop components as the see fit, so long as it is a community decision. > > Some of those components can be: > - Commons RNG (Random Number Generators) > - Commons Complex (Complex Numbers) > - Commons Matrix (Matrix Algebra) > > Those components might have an own life, those algorithms have a wide > audience and can be used in a lot of stuff on its own. The question is what > happens with: > - Commons Genetics (Genetic Algorithms) > - Commons ML (Machine Learning) If there is a case to be made to move components out of Commons Math to become individual Commons components then those proposals should be made individually so the merits can be discussed. For example, just by its name I am not sure why Machine Learning belongs in Math unless it really is just a bunch of machine learning algorithms. > > Or other stuff requiring deep mathematical background. I don't have the > impression this belongs as own components into Commons. Moving CM as whole > into a new TLP at least provides a place for all of it. > > The question is, what do we want as PMC members? I’m not sure I understand the question. Once there are enough active committers then I would think they would become Math TLP PMC members when it is appropriate. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Hi Ralph,
Ralph Goers wrote: > > >> On Jun 19, 2016, at 10:40 AM, Jörg Schaible <[hidden email]> >> wrote: >> >> Hi Ralph, >> >> Ralph Goers wrote: >> >>> Thanks, Eric. >>> >>> I am OK with Commons Math being split into modules in the Commons Math >>> sub-project. >> >> >> That was my first idea too. But if the collection of all submodules will >> in the end nevertheless only contain 20% of the code, we gained nothing. >> >> >>> I am not OK with Commons Math A, Commons Math B, etc existing >>> within Commons. In other words, when a user traverses to Commons Math >>> they can then see the modules that make up Commons Math. >> >> >> The main problem seems to be that CM was a dumping ground for all kind of >> stuff that have at least the slightest relation to a mathematical base. >> >> Gilles never expressed it directly, but in its consequence he proposed to >> move the current CM into dormant/attic and extract single parts of the >> old code base as new components. > > Personally, I don’t think moving it to the attic is appropriate. Projects > go to the attic, not components. The Math project (or sub-project) is > free to add or drop components as the see fit, so long as it is a > community decision. > >> >> Some of those components can be: >> - Commons RNG (Random Number Generators) >> - Commons Complex (Complex Numbers) >> - Commons Matrix (Matrix Algebra) >> >> Those components might have an own life, those algorithms have a wide >> audience and can be used in a lot of stuff on its own. The question is >> what happens with: >> - Commons Genetics (Genetic Algorithms) >> - Commons ML (Machine Learning) > > If there is a case to be made to move components out of Commons Math to > become individual Commons components then those proposals should be made > individually so the merits can be discussed. And it has to be cleared what it means for CM itself. > For example, just by its name > I am not sure why Machine Learning belongs in Math unless it really is > just a bunch of machine learning algorithms. It seems so. >> Or other stuff requiring deep mathematical background. I don't have the >> impression this belongs as own components into Commons. Moving CM as >> whole into a new TLP at least provides a place for all of it. >> >> The question is, what do we want as PMC members? > > I’m not sure I understand the question. Do we want new individual components here in Commons that have been extracted from the original CM? Basically this could be done for some code (targeting a wide audience as explained above), but the rest of the code will no longer fit even as individual components into the Commons context. And what are the consequences for CM if we go down that road. > Once there are enough active > committers then I would think they would become Math TLP PMC members when > it is appropriate. To me this means to keep CM alive as it is (multi-project or not), wait for a big enough community (in the incubator or here) to claim TLP and the Math TLP can then act with the code as it likes. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
> On Jun 19, 2016, at 3:13 PM, Jörg Schaible <[hidden email]> wrote: > > Hi Ralph, > > Ralph Goers wrote: > > >> Once there are enough active >> committers then I would think they would become Math TLP PMC members when >> it is appropriate. > > > To me this means to keep CM alive as it is (multi-project or not), wait for > a big enough community (in the incubator or here) to claim TLP and the Math > TLP can then act with the code as it likes. That is sort of true. There is really nothing stopping individuals from creating new forks or branches to at least demonstrate what they have in mind. In itself, that might help to get more people involved. Ralph |
Free forum by Nabble | Edit this page |