Re: Applications Lifecycle Policy
Il giorno Tue, 04 Jul 2017 23:04:08 +0200 Christian Mollekopf ha scritto: > * it should be ok to release from playground for years, or even > potentially forever. That would impact translations, and IMO it can be easily abused as a "get out of jail free" card that avoids kdereview. While I understand the motivations behind it, I don't think it's feasible. I can however understand going from playground for a "while". > should be possible to release from extragear forever. Perhaps some > project is just not interested in translations for instance...) From extragear it's already the case. It simply means "project has its own schedule not tied to Plasma, Applications, or Frameworks". > * Abolishing the extragear/applications differentiation at this level > would make more sense to me (extragear does have a second class feel That would cause a bit of issue wrt releases, since: a. extragear go on their own releases (see Krita for a big example of this) b. Applications releases have predictable, time-based releases which not all projects would like to subject to
Re: Applications Lifecycle Policy
I'm just going to reply to luigis mail since the others make similar arguments. On Wed, Jul 5, 2017, at 12:16 AM, Luigi Toscano wrote: > Christian Mollekopf ha scritto: > > > > > > On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote: > >> Christian Mollekopf ha scritto: > >>> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: > > Yes. I realize that this would be a change from the current situation, > > but I don't think it would hurt. > > It would essentially allow applications to either get the extra quality > > badge or not as they see fit. > > Just to stress again: I don't think it's about extra quality, but > baseline quality. > Yes, that's basically the difference between the approaches. > > > > Ok, but I wouldn't. I think it could be perfectly viable for some > > application to say that i.e. > > because we only target the scientific community (I'm making some random > > example up), > > we just assume they speak english and don't care about the rest. > > > > My point is not specifically about translations, it's about requirements > > in general and whether it > > makes sense to find a "one size fits all" barrier that all applications > > have to pass. > > > > I understood your point, but a review is about many things (starting from > the general test from someone else external to the project, to - say - > expectations in the code, to cmake structure if applicable, to > translations (which are always fit so far). My point is don't assume that > something is > not fit because there could not be "one size fits all"; some things may not > fit but let's find out after, not a priori. > (and we already lowered the requirements, see documentation). > > >> > >>> * Abolishing the extragear/applications differentiation at this level > >>> would make more sense to me (extragear does have a second class feel to > >>> it), instead applications should just declare that they are part of the > >>> applications release. This would indeed also ease transitioning between > >>> releases and dealing with the versioning should be up to the maintainers > >>> (of course versions that go down are not at all something that should be > >>> accepted ever anywhere). > >> > >> > >> So basically change > >> > >> kdereview > >> -> KDE Applications > >> -> KDE Extragear > >> -> KDE Frameworks > >> -> KDE Plasma > >> (as mentioned by Jonathan, we are missing the last two in the graph) > >> > >> with something like > >> > >> kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", > >> independent release schedule). > >> > >> That sound fine, with one caveat: without having the 4 entities in > >> separate nodes of the graph we can't describe the transition between > >> modules. You > >> wrote that this would "ease transitioning", but I think that we may want to > >> capture for example the transition from "any" to Frameworks, which has > >> specific > >> rules. > >> And so on. > > > > What I meant to propose was more that instead of being initially in a > > temporary location, > > and then having to choose one of "proper" ones and go through review, we > > would instead > > start with a permanent location and then you "could" become part of a > > release with requirements > > and therefore review. In general I just think the barrier to release a > > project from KDE infrastructure > > should be lowered not raised. > > > This comes again from the diversity in view: for me the review, with all > its limits, it's the baseline. > As showed in the discussion, releasing from playground is not more > complicated than other type of releases. Yes, I'm fine with that. I just wanted to make sure releasing from playground doesn't require any exceptions but is regular procedure. > It's just when it becomes "too much" that > people start asking "why not go for a proper review". It's not different in my > opinion from new contributor submitting patches until someone see that > it's "too much" and start asking "why don't you get a proper account". Essentially managing the system by applying some peer pressure to get people out of playground. Personally I don't find that necessary but it's a valid approach of course. > Unless... do you (generic) have specific cases when people could fear the > review? That's the part that I don't understand. > For example, would you (specific) have some reason to not have a review > for the 4 modules that were just reviewed for pim, up to Kube? I'm happy since I can release from extragear. If I couldn't (apart from the argument that it doesn't make sense due to lack of feedback, just from the upfront effort), I'm not sure where those repositories would be now. No hurdle is insurmountable or even very large, but everyone has plenty to do without any of them, so if there is an easier way it's just very tempting to just pick that. Overall I just find the cost/benefit factor in the beginning of a project not at all good when using KDE infrastructure. I have to request repos and
Re: Applications Lifecycle Policy
Christian Mollekopf ha scritto: > > > On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote: >> Christian Mollekopf ha scritto: >>> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: The applications lifecycle policy needs an update Is this a good current state of it or are there more stages? https://community.kde.org/Policies/Application_Lifecycle/Draft >>> >>> Looks good to me for what it currently is. >>> >>> In general I think: >>> * it should be ok to release from playground for years, or even >>> potentially forever. >> >> Even stable releases? I disagree. >> > > Yes. I realize that this would be a change from the current situation, > but I don't think it would hurt. > It would essentially allow applications to either get the extra quality > badge or not as they see fit. Just to stress again: I don't think it's about extra quality, but baseline quality. > >>> * going to extragear/applications should be an extra quality badge where >>> you sign up for certain requirements (which is why I think it should be >>> possible to release from extragear forever. Perhaps some project is just >>> not interested in translations for instance...) >> >> I totally disagree. If an application is not interested in the >> translations (or other "details" which should be level 0) and the >> maintainership does >> not even agree to outsource the work for the maintainance of the >> translations, I would question whether the application is fit for the KDE >> community at >> all. > > Ok, but I wouldn't. I think it could be perfectly viable for some > application to say that i.e. > because we only target the scientific community (I'm making some random > example up), > we just assume they speak english and don't care about the rest. > > My point is not specifically about translations, it's about requirements > in general and whether it > makes sense to find a "one size fits all" barrier that all applications > have to pass. > I understood your point, but a review is about many things (starting from the general test from someone else external to the project, to - say - expectations in the code, to cmake structure if applicable, to translations (which are always fit so far). My point is don't assume that something is not fit because there could not be "one size fits all"; some things may not fit but let's find out after, not a priori. (and we already lowered the requirements, see documentation). >> >>> * Abolishing the extragear/applications differentiation at this level >>> would make more sense to me (extragear does have a second class feel to >>> it), instead applications should just declare that they are part of the >>> applications release. This would indeed also ease transitioning between >>> releases and dealing with the versioning should be up to the maintainers >>> (of course versions that go down are not at all something that should be >>> accepted ever anywhere). >> >> >> So basically change >> >> kdereview >> -> KDE Applications >> -> KDE Extragear >> -> KDE Frameworks >> -> KDE Plasma >> (as mentioned by Jonathan, we are missing the last two in the graph) >> >> with something like >> >> kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", >> independent release schedule). >> >> That sound fine, with one caveat: without having the 4 entities in >> separate nodes of the graph we can't describe the transition between >> modules. You >> wrote that this would "ease transitioning", but I think that we may want to >> capture for example the transition from "any" to Frameworks, which has >> specific >> rules. >> And so on. > > What I meant to propose was more that instead of being initially in a > temporary location, > and then having to choose one of "proper" ones and go through review, we > would instead > start with a permanent location and then you "could" become part of a > release with requirements > and therefore review. In general I just think the barrier to release a > project from KDE infrastructure > should be lowered not raised. This comes again from the diversity in view: for me the review, with all its limits, it's the baseline. As showed in the discussion, releasing from playground is not more complicated than other type of releases. It's just when it becomes "too much" that people start asking "why not go for a proper review". It's not different in my opinion from new contributor submitting patches until someone see that it's "too much" and start asking "why don't you get a proper account". Unless... do you (generic) have specific cases when people could fear the review? That's the part that I don't understand. For example, would you (specific) have some reason to not have a review for the 4 modules that were just reviewed for pim, up to Kube? Ciao -- Luigi
Re: Applications Lifecycle Policy
On Tuesday 04 July 2017 23:34:20 Christian Mollekopf wrote: > What I meant to propose was more that instead of being initially in a > temporary location, > and then having to choose one of "proper" ones and go through review, > we would instead > start with a permanent location and then you "could" become part of a > release with requirements > and therefore review. In general I just think the barrier to release a > project from KDE infrastructure > should be lowered not raised. To me this sounds as if you want the KDE infrastructure to become a dumping ground for low-quality, untranslated stuff, i.e. just like github except with the KDE badge. Yes, I'm exaggerating, but essentially that's how I understand what you are saying. I agree with Albert, Ben, and Luigi, that we (at least the four of us) don't want this. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Applications Lifecycle Policy
On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote: > Christian Mollekopf ha scritto: > > On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: > >> The applications lifecycle policy needs an update > >> > >> Is this a good current state of it or are there more stages? > >> > >> https://community.kde.org/Policies/Application_Lifecycle/Draft > >> > > > > Looks good to me for what it currently is. > > > > In general I think: > > * it should be ok to release from playground for years, or even > > potentially forever. > > Even stable releases? I disagree. > Yes. I realize that this would be a change from the current situation, but I don't think it would hurt. It would essentially allow applications to either get the extra quality badge or not as they see fit. > > * going to extragear/applications should be an extra quality badge where > > you sign up for certain requirements (which is why I think it should be > > possible to release from extragear forever. Perhaps some project is just > > not interested in translations for instance...) > > I totally disagree. If an application is not interested in the > translations (or other "details" which should be level 0) and the > maintainership does > not even agree to outsource the work for the maintainance of the > translations, I would question whether the application is fit for the KDE > community at > all. Ok, but I wouldn't. I think it could be perfectly viable for some application to say that i.e. because we only target the scientific community (I'm making some random example up), we just assume they speak english and don't care about the rest. My point is not specifically about translations, it's about requirements in general and whether it makes sense to find a "one size fits all" barrier that all applications have to pass. > > > * Abolishing the extragear/applications differentiation at this level > > would make more sense to me (extragear does have a second class feel to > > it), instead applications should just declare that they are part of the > > applications release. This would indeed also ease transitioning between > > releases and dealing with the versioning should be up to the maintainers > > (of course versions that go down are not at all something that should be > > accepted ever anywhere). > > > So basically change > > kdereview > -> KDE Applications > -> KDE Extragear > -> KDE Frameworks > -> KDE Plasma > (as mentioned by Jonathan, we are missing the last two in the graph) > > with something like > > kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", > independent release schedule). > > That sound fine, with one caveat: without having the 4 entities in > separate nodes of the graph we can't describe the transition between modules. > You > wrote that this would "ease transitioning", but I think that we may want to > capture for example the transition from "any" to Frameworks, which has > specific > rules. > And so on. What I meant to propose was more that instead of being initially in a temporary location, and then having to choose one of "proper" ones and go through review, we would instead start with a permanent location and then you "could" become part of a release with requirements and therefore review. In general I just think the barrier to release a project from KDE infrastructure should be lowered not raised. Cheers, Christian PS: If I don't reply anymore that is because I'm about to board a plane.
Re: Applications Lifecycle Policy
El dimarts, 4 de juliol de 2017, a les 23:04:08 CEST, Christian Mollekopf va escriure: > On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: > > The applications lifecycle policy needs an update > > > > Is this a good current state of it or are there more stages? > > > > https://community.kde.org/Policies/Application_Lifecycle/Draft > > Looks good to me for what it currently is. > > In general I think: > * it should be ok to release from playground for years, or even > potentially forever. Why? > * going to extragear/applications should be an extra quality badge where > you sign up for certain requirements (which is why I think it should be > possible to release from extragear forever. Perhaps some project is just > not interested in translations for instance...) If you're not interested in translations you don't belong into KDE. Translations are a core of our user friendlyness declaration. Cheers, Albert > * Abolishing the extragear/applications differentiation at this level > would make more sense to me (extragear does have a second class feel to > it), instead applications should just declare that they are part of the > applications release. This would indeed also ease transitioning between > releases and dealing with the versioning should be up to the maintainers > (of course versions that go down are not at all something that should be > accepted ever anywhere). > > Cheers, > Christian
Re: Applications Lifecycle Policy
On Wed, Jul 5, 2017 at 9:04 AM, Christian Mollekopf wrote: > On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: >> The applications lifecycle policy needs an update >> >> Is this a good current state of it or are there more stages? >> >> https://community.kde.org/Policies/Application_Lifecycle/Draft >> > > Looks good to me for what it currently is. > > In general I think: > * it should be ok to release from playground for years, or even > potentially forever. Sorry, but I disagree there. Releasing from Playground is allowed merely to allow developers to get feedback from early adopters (who understand the software may possess kittens, open blackholes and start a zombie uprising) Once an application is ready (or is being used) for production purposes by users (and it's own developers count as users) then it should be headed to Extragear/Applications. We're doing ourselves a disservice by not reviewing each others code for issues, which is something KDE Review helps facilitate. > * going to extragear/applications should be an extra quality badge where > you sign up for certain requirements (which is why I think it should be > possible to release from extragear forever. Perhaps some project is just > not interested in translations for instance...) Pretty sure that not allowing translations is a violation of various commitments which are expected of KDE software as it impedes accessibility and usability by portions of our user base. > * Abolishing the extragear/applications differentiation at this level > would make more sense to me (extragear does have a second class feel to > it), instead applications should just declare that they are part of the > applications release. This would indeed also ease transitioning between > releases and dealing with the versioning should be up to the maintainers > (of course versions that go down are not at all something that should be > accepted ever anywhere). > > Cheers, > Christian Regards, Ben
Re: latest draft for mission (and strategy)
Hey, On Sun, Jul 2, 2017, at 03:43 AM, Kevin Ottens wrote: > > I hope for another fate. Because of that, I don't think this is a proper > conclusion to the Evolving KDE effort or a proper answer to Paul's talk. While I think I understand what you're looking for and don't find (yet) in the vision/mission, I'm thinking similar to Sebastian (I think ;-)). For me a grand vision for KDE as a whole is just not all that interesting, I'm much more interested in what Plasma, Zanshin, KWin, KDevelop, are trying to achieve and how they're going about that. Perhaps I then also don't care so much in the end whether a project is coming from KDE or not, which I personally find good, but others may have different opinions. I think it's also much more useful for people to engage with a specific project than just having this large unspecific thing that they then have to dissect to find something tangible to work on. Speaking of that, since the rebranding effort KDE is anyways standing for the community as far as I understand (correct me if I'm wrong), and I don't see how we can have a vision or mission for a community. Sooo, perhaps you are just looking for something different than a very generic and broad guideline to establish some common values =) Cheers, Christian
Re: Applications Lifecycle Policy
Christian Mollekopf ha scritto: > On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: >> The applications lifecycle policy needs an update >> >> Is this a good current state of it or are there more stages? >> >> https://community.kde.org/Policies/Application_Lifecycle/Draft >> > > Looks good to me for what it currently is. > > In general I think: > * it should be ok to release from playground for years, or even > potentially forever. Even stable releases? I disagree. > * going to extragear/applications should be an extra quality badge where > you sign up for certain requirements (which is why I think it should be > possible to release from extragear forever. Perhaps some project is just > not interested in translations for instance...) I totally disagree. If an application is not interested in the translations (or other "details" which should be level 0) and the maintainership does not even agree to outsource the work for the maintainance of the translations, I would question whether the application is fit for the KDE community at all. > * Abolishing the extragear/applications differentiation at this level > would make more sense to me (extragear does have a second class feel to > it), instead applications should just declare that they are part of the > applications release. This would indeed also ease transitioning between > releases and dealing with the versioning should be up to the maintainers > (of course versions that go down are not at all something that should be > accepted ever anywhere). So basically change kdereview -> KDE Applications -> KDE Extragear -> KDE Frameworks -> KDE Plasma (as mentioned by Jonathan, we are missing the last two in the graph) with something like kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", independent release schedule). That sound fine, with one caveat: without having the 4 entities in separate nodes of the graph we can't describe the transition between modules. You wrote that this would "ease transitioning", but I think that we may want to capture for example the transition from "any" to Frameworks, which has specific rules. And so on. -- Luigi
Re: Applications Lifecycle Policy
On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: > The applications lifecycle policy needs an update > > Is this a good current state of it or are there more stages? > > https://community.kde.org/Policies/Application_Lifecycle/Draft > Looks good to me for what it currently is. In general I think: * it should be ok to release from playground for years, or even potentially forever. * going to extragear/applications should be an extra quality badge where you sign up for certain requirements (which is why I think it should be possible to release from extragear forever. Perhaps some project is just not interested in translations for instance...) * Abolishing the extragear/applications differentiation at this level would make more sense to me (extragear does have a second class feel to it), instead applications should just declare that they are part of the applications release. This would indeed also ease transitioning between releases and dealing with the versioning should be up to the maintainers (of course versions that go down are not at all something that should be accepted ever anywhere). Cheers, Christian
Re: latest draft for mission (and strategy)
On 2017 M07 2, Sun 03:43:57 CEST Kevin Ottens wrote: ... > In my opinion our answer to "where we want to go" was supposed to be > something else than "nowhere in particular". Then I think we're falling > very short on that. We face a problem, and instead of putting our efforts > to find where to go to solve it, we're been pouring over the years massive > efforts into describing where we currently are. That's understandable but > it means we went off track in my opinion. If we stop at what we got so far, > we're in my opinion falling into a kind of conservatism trap. The community > will stay put and will keep shrinking as people loose interest and less new > blood gets in. Are you saying somewhere in those documents we should say what we actually want to accomplish ? Maybe not only on a community level, but on a software level ? If so, I agree. Alex
Re: Applications Lifecycle Policy
On Tue, Jul 04, 2017 at 01:43:32PM +0200, Kevin Ottens wrote: > Hello, > > On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote: > > The applications lifecycle policy needs an update > > > > Is this a good current state of it or are there more stages? > > > > https://community.kde.org/Policies/Application_Lifecycle/Draft > > Didn't we have cases of applications moving between KDE Applications and > Extragear? Occationally, at last extragear to apps I seem to remember. It's potentially problematic when it happens because of the change in version numbers, distros don't like them to go down. I have missed Plasma and Frameworks from the diagram which seems like an oversight. Jonathan
Re: [kde-community] Re: Applications Lifecycle Policy
On Tuesday, 4 July 2017 14:27:07 CEST Jonathan Riddell wrote: > On Tue, Jul 04, 2017 at 02:24:30PM +0200, Luigi Toscano wrote: > > Are we focusing on the graph for now, and then we can move to the content > > of the page, or can we start the general discussion as well? > > Go wild :) > I think that we need to expand the step about moving to unmaintained. It's really rare that someone writes "I'm abandoning this", so we may want to find some other conditions. For example, change of underlying Qt and program not ported? We have many applications like this in "extragear" (still kdelibs4). -- Luigi
Re: [kde-community] Re: Applications Lifecycle Policy
On Tue, Jul 04, 2017 at 02:24:30PM +0200, Luigi Toscano wrote: > Are we focusing on the graph for now, and then we can move to the content of > the page, or can we start the general discussion as well? Go wild :) Jonathan
Re: Applications Lifecycle Policy
On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote: > The applications lifecycle policy needs an update > > Is this a good current state of it or are there more stages? > > https://community.kde.org/Policies/Application_Lifecycle/Draft Are we focusing on the graph for now, and then we can move to the content of the page, or can we start the general discussion as well? The proposed graph is fine by me, and it solves the issue with applications coming from the Incubation which ended into playground while they should have gone directly to kdereview. I think that a separate "playground" has still value in defining some kind of line where the application has been released. "Extragear" here already means "whatever is released with its own release cycle not in the big bundles", as we basically officially removed that word from public usage. -- Luigi
Re: Applications Lifecycle Policy
On Tue, Jul 4, 2017 at 1:43 PM, Kevin Ottens wrote: > Hello, > > On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote: >> The applications lifecycle policy needs an update >> >> Is this a good current state of it or are there more stages? >> >> https://community.kde.org/Policies/Application_Lifecycle/Draft > > Didn't we have cases of applications moving between KDE Applications and > Extragear? Probably. I do wonder if we can, maybe, get rid of Extragear as a thing altogether. Extragear applications are KDE applications on their own release schedule. At least for the purposes of the lifecycle I'd think they are one and the same. Separating them by name only and calling one "extra" kind of implies that the others are common/normal/standard/default, when in fact they are simply released at different points in time but otherwise the same. Tearing down this artificial wall may well incline extragear apps that have a particularly irregular release schedule to switch to the bundle releases to get bugfixes out (i.e. committing to releases seem less of a daunting thing) or the other way around if the fixed schedule turns out to not work in an application's favor (I seem to recall Marble having had some trouble with release prep). (I do appreciate that this may also blur the line a bit too much given we refer to the applications release as "The" KDE Applications releases) HS
Re: Applications Lifecycle Policy
Hello, On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote: > The applications lifecycle policy needs an update > > Is this a good current state of it or are there more stages? > > https://community.kde.org/Policies/Application_Lifecycle/Draft Didn't we have cases of applications moving between KDE Applications and Extragear? Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Applications Lifecycle Policy
The applications lifecycle policy needs an update Is this a good current state of it or are there more stages? https://community.kde.org/Policies/Application_Lifecycle/Draft Jonathan
