Re: [hackathon] flagging sling modules as deprecated/contrib
On Tuesday 18 September 2018 15:46:09 Bertrand Delacretaz wrote: > On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey wrote: > > ...I'll throw "community" and/or "community supported" into the ring for > > consideration as well. For those bundles that aren't supported... > I like it, as a way to indicate that the PMC expects the community to > take care of those bundles, on a best effort basis, as opposed to the > core bundles which the PMC commits to maintaining and keeping in sync > with the latest evolutions. > > That doesn't prevent any community member from working on core bundles > of course, again it's just an indication of PMC committment. > > So we might go for these two axes: > > Code maturity axis: experimental, alpha, beta, product-ready. > > PMC committment axis: core, community and whiteboard The proposals are way too complex and a maintenance nightmare in my opinion. We should keep it really simple and boil it down to *experimental* and *deprecated*. Regards, O. > -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
On Wednesday 26 September 2018 18:29:47 Carsten Ziegeler wrote: > For setting up Sling from scratch, I guess it would make sense to share > my list of bundles; I assembled it roughly a year ago and I didn't > update it since then. I'll go through this exercise and once I have > something I'll share it with the larger audience. The sling feature is the minimal set of bundles and up to date: https://github.com/apache/sling-org-apache-sling-karaf-features/blob/master/src/main/feature/feature.xml#L22 Regards, O. > Regards > > Carsten > > > Jason E Bailey wrote > > > On Tue, Sep 25, 2018, at 3:25 PM, Dominik Süß wrote: > >> Hi Jason, > >> > >> What beyond the ‚engine‘ is actually required? > > > > I think that's the entire point that I'm trying to make. I don't actually > > know, and if you are coming to the website there really isn't a way for > > you to know what is or isn't needed if you are attempting to set up Sling > > from scratch. Carsten's comment was one of the most educational I've seen > > so far as to what needs to be set up.> > >> And even the engine is not required to use some sling bundles. > > > > Interesting question that, if you are using bundles from Sling without > > using the Sling engine, are you really using Sling?> > >> The axis of interest are maintenance commitment (indicating commitment of > >> active committers for module - staring as contribution and ending > >> orphaned) > >> and maturity (experimental, alpha, beta, production ready/ stable , > >> deprecated, maybe discontinued) > > > > That is your interpretation and I'm not sure if that matches other peoples > > definitions. Bertrand has implied that the level of support is not > > dependent on the number of committers but on whether the PMC decides via > > a vote whether a bundle should be supported i.e. not a contrib. That was > > my takeaway at least. > > > > My goal may also be slightly different from the conversation around > > indicating the deprecated bundles. > > > > I have had an issue with this page for a long time > > https://sling.apache.org/downloads.cgi > > > > It's awful, It conveys very little information, If I have a bundle id I > > can't find it here, I don't see why a bundle listed here should be used > > or not. I'm hoping these categorizations and tags can be utilized here > > to better segment what I'm looking at. So that it provides context. > > > > -Jason
Re: [hackathon] flagging sling modules as deprecated/contrib
Right, that's what I have. I splitted it up into two, OSGi basics and then Sling specific on top Regards Carsten Bertrand Delacretaz wrote > Hi, > > On Wed, Sep 26, 2018 at 12:29 PM Carsten Ziegeler > wrote: >> For setting up Sling from scratch, I guess it would make sense to share >> my list of bundles... > > If that can be done as a feature file in the Sling starter that might > a good way? Just a "core" feature that represents the minimal setup. > > -Bertrand > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [hackathon] flagging sling modules as deprecated/contrib
Hi, On Wed, Sep 26, 2018 at 12:29 PM Carsten Ziegeler wrote: > For setting up Sling from scratch, I guess it would make sense to share > my list of bundles... If that can be done as a feature file in the Sling starter that might a good way? Just a "core" feature that represents the minimal setup. -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
For setting up Sling from scratch, I guess it would make sense to share my list of bundles; I assembled it roughly a year ago and I didn't update it since then. I'll go through this exercise and once I have something I'll share it with the larger audience. Regards Carsten Jason E Bailey wrote > > On Tue, Sep 25, 2018, at 3:25 PM, Dominik Süß wrote: >> Hi Jason, >> >> What beyond the ‚engine‘ is actually required? > > I think that's the entire point that I'm trying to make. I don't actually > know, and if you are coming to the website there really isn't a way for you > to know what is or isn't needed if you are attempting to set up Sling from > scratch. Carsten's comment was one of the most educational I've seen so far > as to what needs to be set up. > >> And even the engine is not required to use some sling bundles. > > Interesting question that, if you are using bundles from Sling without using > the Sling engine, are you really using Sling? > >> The axis of interest are maintenance commitment (indicating commitment of >> active committers for module - staring as contribution and ending orphaned) >> and maturity (experimental, alpha, beta, production ready/ stable , >> deprecated, maybe discontinued) > > That is your interpretation and I'm not sure if that matches other peoples > definitions. Bertrand has implied that the level of support is not dependent > on the number of committers but on whether the PMC decides via a vote whether > a bundle should be supported i.e. not a contrib. That was my takeaway at > least. > > My goal may also be slightly different from the conversation around > indicating the deprecated bundles. > > I have had an issue with this page for a long time > https://sling.apache.org/downloads.cgi > > It's awful, It conveys very little information, If I have a bundle id I can't > find it here, I don't see why a bundle listed here should be used or not. > I'm hoping these categorizations and tags can be utilized here to better > segment what I'm looking at. So that it provides context. > > -Jason > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [hackathon] flagging sling modules as deprecated/contrib
On Tue, Sep 25, 2018, at 3:25 PM, Dominik Süß wrote: > Hi Jason, > > What beyond the ‚engine‘ is actually required? I think that's the entire point that I'm trying to make. I don't actually know, and if you are coming to the website there really isn't a way for you to know what is or isn't needed if you are attempting to set up Sling from scratch. Carsten's comment was one of the most educational I've seen so far as to what needs to be set up. > And even the engine is not required to use some sling bundles. Interesting question that, if you are using bundles from Sling without using the Sling engine, are you really using Sling? > The axis of interest are maintenance commitment (indicating commitment of > active committers for module - staring as contribution and ending orphaned) > and maturity (experimental, alpha, beta, production ready/ stable , > deprecated, maybe discontinued) That is your interpretation and I'm not sure if that matches other peoples definitions. Bertrand has implied that the level of support is not dependent on the number of committers but on whether the PMC decides via a vote whether a bundle should be supported i.e. not a contrib. That was my takeaway at least. My goal may also be slightly different from the conversation around indicating the deprecated bundles. I have had an issue with this page for a long time https://sling.apache.org/downloads.cgi It's awful, It conveys very little information, If I have a bundle id I can't find it here, I don't see why a bundle listed here should be used or not. I'm hoping these categorizations and tags can be utilized here to better segment what I'm looking at. So that it provides context. -Jason
Re: [hackathon] flagging sling modules as deprecated/contrib
On Wed, Sep 26, 2018 at 4:56 AM Carsten Ziegeler wrote: > ...For example if you want to use JCR, then this adds a bunch of new > bundles to the mix which are required for that scenario.. I agree and I think the provisioning / feature model files can express this nicely, in the end the question might be "what feature is this bundle part of in the Sling starter". -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
For just running Sling you need roughly 30 bundles, from which 12 or so are Sling bundles. Some of them are Sling commons one, then you need things like the resource resolver, the servlets bundles and finally a resource provider. But I think the notion of required is not really helpfull here, especially as it only converts a third of what you really need to run Sling. And that would be without considering which resource provider you use. For example if you want to use JCR, then this adds a bunch of new bundles to the mix which are required for that scenario Regards Carsten Dominik Süß wrote > Hi Jason, > > What beyond the ‚engine‘ is actually required? > And even the engine is not required to use some sling bundles. > > Sling follows a service oriented architecture thst is very loosely coupled > and expresses minimal depencies. We shouldn’t try to establish wrong > expectations by naming which is why I really don’t like core & controb or > extensions. > > The functional aspect is very personal and Sling starter is just one > reasonable combination of modules. > > The axis of interest are maintenance commitment (indicating commitment of > active commiters for module - staring as contribution and ending orphaned) > and maturity (experimental, alpha, beta, production ready/ stable , > deprecated, maybe discontinued) > > > For maturity: > Experimental ( intended for poc - might be quick & dirty) > Alpha (active development to cover a full productive scenario) > Beta (full coverage for intended use case - feedback cycles might lead to > refactorings of smaller parts) > Stable (versions > 1.0.0 indicating stable semantic versioning and > behavioral stability) > Deprecated (better alternatives around or no longer actively updated to > work optimally with latest platform) > Discontinued (only archival of latest shipped source) > > For the maintenance commitment I am personally interested how many active > willing commiters are around: 0, 1, 2-3, 4+) indicating how likely someone > can start to help in case of trouble with module > > Cheers > Dominik > > Jason E Bailey schrieb am Mo. 24. Sep. 2018 um 15:13: > >> I still feel like we are missing an axis. One that groups the various >> bundles by functionality. >> >> Maybe: Required, Extension, Optional >> >> Required are the minimal bundles you need, Extensions are alternatives or >> specific implementations of Required, and Optional is just that. >> >> >> - Jason >> >> On Tue, Sep 18, 2018, at 9:46 AM, Bertrand Delacretaz wrote: >>> On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey wrote: ...I'll throw "community" and/or "community supported" into the ring >> for consideration as well. For those bundles that aren't supported... >>> >>> I like it, as a way to indicate that the PMC expects the community to >>> take care of those bundles, on a best effort basis, as opposed to the >>> core bundles which the PMC commits to maintaining and keeping in sync >>> with the latest evolutions. >>> >>> That doesn't prevent any community member from working on core bundles >>> of course, again it's just an indication of PMC committment. >>> >>> So we might go for these two axes: >>> >>> Code maturity axis: experimental, alpha, beta, product-ready. >>> >>> PMC committment axis: core, community and whiteboard >>> >>> -Bertrand >> > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [hackathon] flagging sling modules as deprecated/contrib
Hi Jason, What beyond the ‚engine‘ is actually required? And even the engine is not required to use some sling bundles. Sling follows a service oriented architecture thst is very loosely coupled and expresses minimal depencies. We shouldn’t try to establish wrong expectations by naming which is why I really don’t like core & controb or extensions. The functional aspect is very personal and Sling starter is just one reasonable combination of modules. The axis of interest are maintenance commitment (indicating commitment of active commiters for module - staring as contribution and ending orphaned) and maturity (experimental, alpha, beta, production ready/ stable , deprecated, maybe discontinued) For maturity: Experimental ( intended for poc - might be quick & dirty) Alpha (active development to cover a full productive scenario) Beta (full coverage for intended use case - feedback cycles might lead to refactorings of smaller parts) Stable (versions > 1.0.0 indicating stable semantic versioning and behavioral stability) Deprecated (better alternatives around or no longer actively updated to work optimally with latest platform) Discontinued (only archival of latest shipped source) For the maintenance commitment I am personally interested how many active willing commiters are around: 0, 1, 2-3, 4+) indicating how likely someone can start to help in case of trouble with module Cheers Dominik Jason E Bailey schrieb am Mo. 24. Sep. 2018 um 15:13: > I still feel like we are missing an axis. One that groups the various > bundles by functionality. > > Maybe: Required, Extension, Optional > > Required are the minimal bundles you need, Extensions are alternatives or > specific implementations of Required, and Optional is just that. > > > - Jason > > On Tue, Sep 18, 2018, at 9:46 AM, Bertrand Delacretaz wrote: > > On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey wrote: > > > ...I'll throw "community" and/or "community supported" into the ring > for consideration as well. For those bundles that aren't supported... > > > > I like it, as a way to indicate that the PMC expects the community to > > take care of those bundles, on a best effort basis, as opposed to the > > core bundles which the PMC commits to maintaining and keeping in sync > > with the latest evolutions. > > > > That doesn't prevent any community member from working on core bundles > > of course, again it's just an indication of PMC committment. > > > > So we might go for these two axes: > > > > Code maturity axis: experimental, alpha, beta, product-ready. > > > > PMC committment axis: core, community and whiteboard > > > > -Bertrand >
Re: [hackathon] flagging sling modules as deprecated/contrib
I still feel like we are missing an axis. One that groups the various bundles by functionality. Maybe: Required, Extension, Optional Required are the minimal bundles you need, Extensions are alternatives or specific implementations of Required, and Optional is just that. - Jason On Tue, Sep 18, 2018, at 9:46 AM, Bertrand Delacretaz wrote: > On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey wrote: > > ...I'll throw "community" and/or "community supported" into the ring for > > consideration as well. For those bundles that aren't supported... > > I like it, as a way to indicate that the PMC expects the community to > take care of those bundles, on a best effort basis, as opposed to the > core bundles which the PMC commits to maintaining and keeping in sync > with the latest evolutions. > > That doesn't prevent any community member from working on core bundles > of course, again it's just an indication of PMC committment. > > So we might go for these two axes: > > Code maturity axis: experimental, alpha, beta, product-ready. > > PMC committment axis: core, community and whiteboard > > -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
On Tue, 2018-09-18 at 09:38 -0400, Jason E Bailey wrote: > +1 for defining what the different words mean. I think that's one of > the problems in this thread is that different words mean different > things to different people. One way to approach this would be to link from all badges to a page on our website which explains what they mean. Robert
Re: [hackathon] flagging sling modules as deprecated/contrib
On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey wrote: > ...I'll throw "community" and/or "community supported" into the ring for > consideration as well. For those bundles that aren't supported... I like it, as a way to indicate that the PMC expects the community to take care of those bundles, on a best effort basis, as opposed to the core bundles which the PMC commits to maintaining and keeping in sync with the latest evolutions. That doesn't prevent any community member from working on core bundles of course, again it's just an indication of PMC committment. So we might go for these two axes: Code maturity axis: experimental, alpha, beta, product-ready. PMC committment axis: core, community and whiteboard -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
On Tue, Sep 18, 2018 at 11:37 AM Robert Munteanu wrote: > ...Maybe 'unsupported' is a more expressive term than 'contrib'? > (Although it might be scarier)... It's more precise, I agree, but I would argue that those modules are not actually unsupported, they are supported, but only on a best effort, irregular basis. If we don't want contrib, "Optional" might be a good name? As opposed to "core" modules which we think are required to run Sling for common use-cases. Naming is hard..I think contrib works because its meaning is not obvious and people need to look up what we mean by it. Which means if we redefine those labels we need to document them, I don't think we have a definition on our website currently. -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
On Tue, 2018-09-18 at 09:26 +0200, Bertrand Delacretaz wrote: > Hi, > > On Thu, Sep 13, 2018 at 6:48 PM Daniel Klco wrote: > > ...One concern I have with the experimental (or perhaps the > > definition > > therein) is that it seems much more bleeding edge than what we > > currently > > consider contrib > > I think contrib and experimental refer to different axes. > > There's the code maturity axis: experimental, alpha, beta, product- > ready. > > And the Sling PMC committment axis: > > a) core, for things that we consider an integral part of sling and > intend to maintain continuously, being careful about backwards > compatibility etc. > b) contrib, for modules which might not be maintained continuously > and > might be out of sync with the core modules > c) whiteboard, for modules which we aren't sure belong in Sling yet > > Although it's rare to have an "experimental & core" module, "contrib > & > production-ready" is realistic, even though such a module might not > be > usable with the latest core due to its contrib status. Orthogonal > concerns, really. > > I think we should label modules on both of these axes, without mixing > them up. Maybe 'unsupported' is a more expressive term than 'contrib'? (Although it might be scarier) Robert
Re: [hackathon] flagging sling modules as deprecated/contrib
Hi, On Thu, Sep 13, 2018 at 6:48 PM Daniel Klco wrote: > ...One concern I have with the experimental (or perhaps the definition > therein) is that it seems much more bleeding edge than what we currently > consider contrib I think contrib and experimental refer to different axes. There's the code maturity axis: experimental, alpha, beta, product-ready. And the Sling PMC committment axis: a) core, for things that we consider an integral part of sling and intend to maintain continuously, being careful about backwards compatibility etc. b) contrib, for modules which might not be maintained continuously and might be out of sync with the core modules c) whiteboard, for modules which we aren't sure belong in Sling yet Although it's rare to have an "experimental & core" module, "contrib & production-ready" is realistic, even though such a module might not be usable with the latest core due to its contrib status. Orthogonal concerns, really. I think we should label modules on both of these axes, without mixing them up. -Bertrand
Re: [hackathon] flagging sling modules as deprecated/contrib
I much like this set of definitions. I particularly like the Extensions set as this could accommodate the large number of modules which are used by downstream applications, but are not "required" for Sling to run. The only item I might argue, is that Contrib may be a better fit than Legacy, e.g. this is not a supported part of the application, but without the connotation of being old / out of date. On Mon, Sep 17, 2018 at 9:50 AM Jason E Bailey wrote: > My take - > > Core - Does this mean it has to be in the starter? Does everything that > shows up in the starter means it's Core? My take on the concept of "Core" > is that these are the minimal set of bundles required for Sling and that > every Sling product should have. > > Extensions - ? These are bundles that are supported and provide value but > that not all downstream applications might use. Potentially this would > cover scripting languages, jdbc support, resource providers, etc.., There > could be possible multiple sub sets of extensions that define the types of > extensions > > Legacy - bundles that aren't supported because of complexity, lack of > demand, no one is going to touch it. Use at your own risk sort of thing. > > Deprecated - It's here because we once made it available, but don't use > it, really, it's a security risk or a legal issue. > > > > - Jason > > On Mon, Sep 17, 2018, at 5:01 AM, Radu Cotescu wrote: > > Hi Daniel, > > > > We had no native English speaker in the room when we came up with > > “experimental”. However, I think it denotes exactly the status of a > > module that was contributed to Sling but was never made a part of the > > core. I wouldn’t necessarily call a contrib module unmaintained, however > > its usage was not necessarily vetted by the majority of the Sling > > committers. > > > > Bleeding edge modules should still be part of the Whiteboard until they > > stabilise. The more I write about this, the more I’m tempted to say that > > we should maybe categorise our modules into “stable” (core), > > “beta” (contrib), “alpha” (whiteboard). > > > > What do the others think? > > > > Cheers, > > Radu > > > > > On 13 Sep 2018, at 18:48, Daniel Klco wrote: > > > > > > One concern I have with the experimental (or perhaps the definition > > > therein) is that it seems much more bleeding edge than what we > currently > > > consider contrib. Is there some more middle ground here, between "not > part > > > of the "core"" and "use on your own risk, probably not well > maintained"? > > >
Re: [hackathon] flagging sling modules as deprecated/contrib
My take - Core - Does this mean it has to be in the starter? Does everything that shows up in the starter means it's Core? My take on the concept of "Core" is that these are the minimal set of bundles required for Sling and that every Sling product should have. Extensions - ? These are bundles that are supported and provide value but that not all downstream applications might use. Potentially this would cover scripting languages, jdbc support, resource providers, etc.., There could be possible multiple sub sets of extensions that define the types of extensions Legacy - bundles that aren't supported because of complexity, lack of demand, no one is going to touch it. Use at your own risk sort of thing. Deprecated - It's here because we once made it available, but don't use it, really, it's a security risk or a legal issue. - Jason On Mon, Sep 17, 2018, at 5:01 AM, Radu Cotescu wrote: > Hi Daniel, > > We had no native English speaker in the room when we came up with > “experimental”. However, I think it denotes exactly the status of a > module that was contributed to Sling but was never made a part of the > core. I wouldn’t necessarily call a contrib module unmaintained, however > its usage was not necessarily vetted by the majority of the Sling > committers. > > Bleeding edge modules should still be part of the Whiteboard until they > stabilise. The more I write about this, the more I’m tempted to say that > we should maybe categorise our modules into “stable” (core), > “beta” (contrib), “alpha” (whiteboard). > > What do the others think? > > Cheers, > Radu > > > On 13 Sep 2018, at 18:48, Daniel Klco wrote: > > > > One concern I have with the experimental (or perhaps the definition > > therein) is that it seems much more bleeding edge than what we currently > > consider contrib. Is there some more middle ground here, between "not part > > of the "core"" and "use on your own risk, probably not well maintained"? >
Re: [hackathon] flagging sling modules as deprecated/contrib
Hi Daniel, We had no native English speaker in the room when we came up with “experimental”. However, I think it denotes exactly the status of a module that was contributed to Sling but was never made a part of the core. I wouldn’t necessarily call a contrib module unmaintained, however its usage was not necessarily vetted by the majority of the Sling committers. Bleeding edge modules should still be part of the Whiteboard until they stabilise. The more I write about this, the more I’m tempted to say that we should maybe categorise our modules into “stable” (core), “beta” (contrib), “alpha” (whiteboard). What do the others think? Cheers, Radu > On 13 Sep 2018, at 18:48, Daniel Klco wrote: > > One concern I have with the experimental (or perhaps the definition > therein) is that it seems much more bleeding edge than what we currently > consider contrib. Is there some more middle ground here, between "not part > of the "core"" and "use on your own risk, probably not well maintained"?
Re: [hackathon] flagging sling modules as deprecated/contrib
One concern I have with the experimental (or perhaps the definition therein) is that it seems much more bleeding edge than what we currently consider contrib. Is there some more middle ground here, between "not part of the "core"" and "use on your own risk, probably not well maintained"? On Thu, Sep 13, 2018 at 12:42 PM Stefan Seifert wrote: > - current contrib/deprecated state maintained in [1] > - status explanations pages missing e.g. [2] > > - we currently have not process when a module should be marked as > deprecated - here is a proposal: > - export statistics on module usage (downloads) from maven central > statistics > - mark modules as deprecated that have both low usage and no committers > willing to actively maintain it > - there is no "attic" any more, so labeling the module as deprecated is > equivalent to attic > - this deprecation check should be done roughly once a year for all > non-deprecated modules > > - the "contrib" flag is difficult to understand what it should mean - we > propose to rename it > - it should be renamed to "experimental" > - modules labeled as experimental (or currently "contrib") must never be > included in the sling starter > - (contrib modules currently includes in starter have to be removed or > "un-contribbed") > - the meaning of "experimental" is: not indented for production use, use > on your own risk, probably not well maintained > > - our sling download page [3] should reflect the deprecated or contrib > status of the modules liste > - this page is the one page users detect most easily, and they should > know when the module is not part of the "core" > > stefan > > [1] https://github.com/apache/sling-aggregator/blob/master/Sling-Repos.csv > [2] > https://github.com/apache/sling-aggregator/blob/master/docs/status/contrib.md > [3] http://sling.apache.org/downloads.cgi > > >
