Re: latest draft for mission (and strategy)
Hi, I'm new on the list so sorry for not replying to the thread. I was asked to contribute my feedback on the Vision/Mission, so here it goes. I like Vision and Mission-Statement and they generally reflect my values as well. They are very inclusive and fairly loose, which I think is the only reasonable thing for such a high-level statement, yet they still establish some values, which is good. Personally, the strategy points are not too relevant for me, so I'm not going comment on the individual points (which I too find generally agreeable, nothing in there goes against what I want to achieve), but I'm going to comment on why they are not too important to me instead. To me, KDE is not one project. We're a diverse bunch of people working on a variety of projects with different goals and ideas. As such, as much as I can agree with individual strategy points, those are ultimately up to the individual projects and their people. Those strategic decisions are always tradeoffs, and as such must be made on a case by case basis. I think it's entirely fine for an application to decide to not be translatable, or to only run on a certain platform, these are decisions for the individual projects and people to make, and sometime heavily depend on individual goals projects set for themselves. The strategy points are fine examples how the vision *could* be pursued, but that's all they are to me, so I think there is little point in trying to fine tune them too much and I think they must not be treated as rules of any sort. Personally I'd like to see more great software produced by the KDE community and not necessarily "KDE-software" (though that's also ok if that's what you're interested in doing of course), so I like that openness in the vision and the mission. I realize though that I have a developer perspective and there is perhaps a need for being more specific for the sake of creating more of an identity, and to that end the strategy points perhaps explain the mission better. Cheers, Christian
Re: latest draft for mission (and strategy)
On Thursday, June 22, 2017 10:23:55 AM CEST you wrote:> Hi Christian, > > On donderdag 22 juni 2017 00:02:00 CEST Christian Mollekopf wrote: ... > > You are exactly right, these documents are fairly loose and they're not meant > to be The Law, but give us all a bit more direction. That said, with a > community as large and diverse as KDE, it can't be overly specific. For that > reason, we encourage sub-projects in KDE to create a more concrete vision, > mission and strategy as well. The Krita team has done that some time ago and > it has brought them a lot more focus and as a result of that focus (and hard > work!), Krita has become the best in class in their newly found niche (which > is not meant belittling at all!). Yeah, I really like the focus and drive the Krita project seems to have, and in that regard I think they are an excellent example of how a KDE project could work. > In Plasma, we've started on the same > process, we're working on the Plasma vision right now (see the plasma-devel > mailing list) and we're planning to drill down to more specifics in that > process. Perhaps, this can be used as a template for other software as well, > I > can imagine that especially in the early stages of development (Hi Kube! :)) > it can deliver great value. Indeed. We have tried a while ago to distill something: * https://kube.kde.org/features.html * http://kube.readthedocs.io/en/latest/project/#vision-statement While I think there is a lot of room for improvement, it's an ok start for us for the time being. Cheers, Christian
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)
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
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
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 cou
Re: Applications Lifecycle Policy
On Wed, Jul 5, 2017, at 09:37 PM, Martin Flöser wrote: > Am 2017-07-04 13:20, schrieb Jonathan Riddell: > > The applications lifecycle policy needs an update > > > > Is this a good current state of it or are there more stages? > > > > Hi all, > > I'm now going to propose a rather radical change to the process: > > 1. Remove extragear > 2. Remove playground > 3. Remove the 2 week Review process I just wanted to say that this very much aligns with my thinking and just explains it much better than I did. Thanks!
Re: Applications Lifecycle Policy
On Wed, Jul 5, 2017, at 10:18 PM, Luigi Toscano wrote: > Martin Flöser ha scritto: > > Am 2017-07-04 13:20, schrieb Jonathan Riddell: > >> The applications lifecycle policy needs an update > >> > >> Is this a good current state of it or are there more stages? > >> > > > > Hi all, > > > > I'm now going to propose a rather radical change to the process: > > > > 1. Remove extragear > > 2. Remove playground > > 3. Remove the 2 week Review process > > > > Let me explain the reasoning. > > > > [...] > Interesting, an annotation on this point: > > > > > Today I think there are way better things to measure the quality than a two > > week process on kde review: > > > > * how many unit tests does a project have? > > * how large is the test coverage? > > * how often do tests fail on build.kde.org? > > * how often does the build fail on build.kde.org? > > * is it translated? > > * does it have appstream data? > > * is the code getting reviewed? > > * is the project a one person show? > > * ... > > > > So instead of a one time review I would propose a continuous review of the > > projects and make it available in an easy accessible way so that users can > > also see the objective quality of the application. And yes that would mean > > that many long standing applications would have a way lower quality than the > > new kids on the block. > > > > For KDE Applications, Plasma and Frameworks I expect to have additional > > rules > > for integration. Frameworks already has them, Plasma kind of has them, but I > > think they are not codified and KDE Applications could e.g. start with the > > current review process. > > > > So to sum it up: I don't think there is a need for extragear and playground > > any more. When a project starts it should have the same rights and > > obligations > > as any other current extragear app. In addition we should come up with > > measurable quality facts and make them available to the community. > > This is different from what Christian said (the "dumping ground is fine > even if some details are not relevant"). This process would make clear that > not all repositories are the same, and that's fine. It's to some extend different, it improves the situation by not only having a quality badge of being part of a release that requires to match certain review criterias, but also improves it with an individual quality assessment, which is a good thing (but will require some work). It also states that all projects still have the same obligations as extragear, which is a change from what I proposed and I don't see how that would really be applicable if you don't have a playground to start. Anyways, in general it is completely in my spirit; little upfront requirements and then judge the quality of what falls out of it. Cheers, Christian
Re: Splitting Craft, move the recipes to GitHub
On Wed, Aug 23, 2017, at 03:33 PM, Hannah von Reth wrote: > Hi everyone, > Hey, > We have been thinking about splitting the Craft recipes into a separate > repository for some time now. > To have a Craft core and the recipes separated would enable us to > provide more stable user experience. It would allow us to use the latest > recipes with the stable core. > I think that is an excellent idea =) It would allow people like me to maintain a stable set of buildscripts while being able to use the latest of the buildtool itself. > At the same time Craft tries to get rid of the image as the KDE Windows > build tool. > > Craft offers recipes for many libraries and non KDE applications. > Additionally Craft offers support for Mac, Linux and FreeBSD. Neat! > In order to reach more people we intend to move the recipes to GitHub to > enable non KDE contributors to add their recipes. > Craft would continue to be a KDE Project on the KDE infrastructure, only > the recipes would move. Enough has probably been said about that. Maintaining the KDE buildscript on KDE infrastructure makes a ton of sense to me. Having a separate repository on github for more github focused projects also makes a lot of sense to me (the alternative being to have a read/write mirror). I think having to deal with multiple repositories will introduce some additional complexity as you might need to allow dependencies between them, but I also think it would be a very valuable feature. Anyways, I'd just put the KDE buildscripts on the KDE infra, create a github mirror for now, and then in the long run work on repository dependencies so it's not necessary to duplicate buildscripts in all repositories. Cheers, Christian
