Re: Kubuntu Wiki (for council consideration)
On Mon, Feb 17, 2014 at 8:57 AM, Harald Sitter wrote: > Hola, > > TLDR: request for council to discuss and vote on whether we sould move > most of our wiki pages (internal) to http://community.kde.org. > > As outlined in a previous mail on this topic [1], I have gotten ever > so annoyed with our current wiki (powered by MoinMoin) that I started > playing with the idea of moving to the KDE wikis as they are well > maintained, we don't have a lot of pages, mediawiki is generally nicer > and KDE's wikis do have exctingly beautiful editorial templates (as a > result of userbase.kde being intented as user facing documentation). > > I would ask the council to take this to a vote. > > Currently we appear to have around 12 generally useful pages on the > wiki [2]. All of them contain internal team documentation rather than > anything user facing all of these could just as well be kept on a KDE > wiki. > > There are however pages (namely the pre-release wiki pages a la [3]) > that probably should not be moved. I would argue that most of these > probably should not be used anyway, but instead the content should be > copied to the actual website, or created there (pointing from the > website to the wiki is generally a bad thing because the wiki is > mostly for internal stuff and very confusing to people who try to look > at other stuff in the wiki). > > If there are any questions, please ask. > > [1] https://lists.ubuntu.com/archives/kubuntu-devel/2014-February/007935.html > [2] https://wiki.ubuntu.com/CategoryKubuntuUseful > [3] https://wiki.kubuntu.org/TrustyTahr/Alpha2/Kubuntu > > HS I vote yes, and my only question is: how soon are we doing this? I missed the first email about adding categories, which is a *great* idea. I haven't done that, but will start. Also, spiffing the filtering for my kubuntu-devel mails. Valorie -- http://about.me/valoriez -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Kubuntu Policies (for council consideration)
On Mon, Feb 17, 2014 at 8:47 AM, Harald Sitter wrote: > Salut, > > TLDR: request for the council to discuss and vote on new policies document. > > The past couple of weeks I worked towards rewriting and updating our > current Kubuntu specific policies of which [1] is the result. > > As with all policies all of it now requires approval by the Kubuntu > Council which I propose should be done on the list as meetings are > tedious to organize and some of the policies might require length > discussions (or hopefully not). > > For the better part these policies are either aligned with current > practise that we had not previously put into written policy or solve > problems to which we never had a best practise solution. Completely > new policies are marked with ((NEW)), all others were derived from > existing policies. > > New key policies: > > * Dead Upstream - how to deal with software that is unmaintained upstream. > > * Handlers - list of contact people for various important things > (requested by JR). > > * Kubuntu Council - I did not find a standing policy document on the > council, one may feel free to enhance it. > > * Kubuntu Teams - describing all Kubuntu teams, how to get it and what > they are there for (requested by JR) > > * Patching - while originally written 3 years ago the patch policy was > never actually approved so this is a slighly refined version of the > previous one. however equally restrictive in what patches can or > cannot do. > > * Stable Updates/Misc - when one may SRU software that is not covered > by our patch-update-exception (primarily KDE SC), it seeks to minimize > the amount of wasted time on SRUs that won't get verified. > > * Long Term Support - outlines what sets an LTS release apart from > other releases specifically for Kubuntu. > > Additionaly the bug triage policy has been changed to reflect what I > did for the past year or two (primarily streamlining over the previous > policy). > > The code style policy from Lucid has been dropped and instead a global > fallback policy was introduced making the upstream policies our > policies unless we have a policy of our own (e.g. upstream code style > and licensing policies apply now - again, what we have practised for > years anyway). > > [1] https://wiki.ubuntu.com/Kubuntu/Policies > > HS Thanks for doing this, Harald. I've taken the liberty of fixing a few spelling and grammar errors. If the Council is now voting on these policies, I vote +1. Valorie -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Kubuntu Wiki (for council consideration)
On Monday, February 17, 2014 17:57:45 Harald Sitter wrote: > Hola, > > TLDR: request for council to discuss and vote on whether we sould move > most of our wiki pages (internal) to http://community.kde.org. TLDR: Meh. Whatever. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: plasma-netbook startup cdrom detection
On Tuesday, February 25, 2014 15:26:04 Harald Sitter wrote: > On Tue, Feb 25, 2014 at 3:20 PM, Philip Muskovac wrote: > > Hi, > > > > To start plasma-netbook on 'Netbooks' we added a check to startkde that > > checks whether laptop-detect return true, whether the display height is > > between 0 and 700px, whether an optical drive exists or whether netbook > > was explicitely requested [1]. > > As the optical drive check depends on udisks, it's broken on new installs > > since we switched to udisks2. > > > > Why are we checking for an optical drive again? As I understand it, the > > plasma-netbook interface was mostly about efficient screen space usage. > > > > If someone remembers why checking for an optical drive is useful here I'll > > try to fix this, otherwise I'll just remove the udisks code from > > startkde. > virtual machines I think. > > though, IIRC there was also a general concern with pulling up the > netbook UI on not netbook machines and netbook machines do not ever > have a drive, hence that check. That's my recollection as well (to reduce false positives on small screen notebooks). Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Fwd [ubuntu-release] Re: LTS status for Ubuntu flavours]
On Tuesday, February 25, 2014 16:22:53 Rohan Garg wrote: > On Sun, Feb 23, 2014 at 1:09 AM, Scott Kitterman wrote: > > On Saturday, February 22, 2014 18:03:52 Phil Wyett wrote: > >> On Saturday 22 Feb 2014 11:48:13 Scott Kitterman wrote: > >> > On Saturday, February 22, 2014 12:08:35 Rohan Garg wrote: > >> > > > I think you are misreading that. It specifically talks about users > >> > > > >> > > potentially > >> > > > >> > > > needing to upgrade only every 4 years. > >> > > > >> > > Unless my eyes are deceiving me, the last line specifically talks > >> > > about > >> > > upgrading twice every 4 years, which equates to a support lifetime of > >> > > 2 > >> > > years? > >> > > >> > OK. In any case, I still have 5 year LTS. In addition to the reasons > >> > I > >> > mentioned previously, I don't want to accept Kubuntu being second class > >> > citizen in the Ubuntu project in any way I don't have to. > >> > > >> > I think 5 years is working out for 12.04 (so far) and I don't think we > >> > should change. > >> > > >> > Scott K > > Alright, after discussing this on IRC, a 5 year LTS should be doable. > However, IMHO we MUST transparently convey what a LTS means for > Kubuntu. Specifically, we should have a page outlining what support > means for Kubuntu specifically ( software is supported only when KDE > upstream supports it, there is absolutely NO support for software that > KDE deems unsupported ). No. We need to provide security support for sure and support for other severe issues on a best effort basis. We shouldn't over promise, but security we have to do. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Fwd [ubuntu-release] Re: LTS status for Ubuntu flavours]
On Sun, Feb 23, 2014 at 1:09 AM, Scott Kitterman wrote: > On Saturday, February 22, 2014 18:03:52 Phil Wyett wrote: >> On Saturday 22 Feb 2014 11:48:13 Scott Kitterman wrote: >> > On Saturday, February 22, 2014 12:08:35 Rohan Garg wrote: >> > > > I think you are misreading that. It specifically talks about users >> > > >> > > potentially >> > > >> > > > needing to upgrade only every 4 years. >> > > >> > > Unless my eyes are deceiving me, the last line specifically talks about >> > > upgrading twice every 4 years, which equates to a support lifetime of 2 >> > > years? >> > >> > OK. In any case, I still have 5 year LTS. In addition to the reasons I >> > mentioned previously, I don't want to accept Kubuntu being second class >> > citizen in the Ubuntu project in any way I don't have to. >> > >> > I think 5 years is working out for 12.04 (so far) and I don't think we >> > should change. >> > >> > Scott K Alright, after discussing this on IRC, a 5 year LTS should be doable. However, IMHO we MUST transparently convey what a LTS means for Kubuntu. Specifically, we should have a page outlining what support means for Kubuntu specifically ( software is supported only when KDE upstream supports it, there is absolutely NO support for software that KDE deems unsupported ). Cheers Rohan Garg -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: plasma-netbook startup cdrom detection
On Tue, Feb 25, 2014 at 3:20 PM, Philip Muskovac wrote: > Hi, > > To start plasma-netbook on 'Netbooks' we added a check to startkde that checks > whether laptop-detect return true, whether the display height is between 0 and > 700px, whether an optical drive exists or whether netbook was explicitely > requested [1]. > As the optical drive check depends on udisks, it's broken on new installs > since we switched to udisks2. > > Why are we checking for an optical drive again? As I understand it, the > plasma-netbook interface was mostly about efficient screen space usage. > > If someone remembers why checking for an optical drive is useful here I'll try > to fix this, otherwise I'll just remove the udisks code from startkde. virtual machines I think. though, IIRC there was also a general concern with pulling up the netbook UI on not netbook machines and netbook machines do not ever have a drive, hence that check. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
plasma-netbook startup cdrom detection
Hi, To start plasma-netbook on 'Netbooks' we added a check to startkde that checks whether laptop-detect return true, whether the display height is between 0 and 700px, whether an optical drive exists or whether netbook was explicitely requested [1]. As the optical drive check depends on udisks, it's broken on new installs since we switched to udisks2. Why are we checking for an optical drive again? As I understand it, the plasma-netbook interface was mostly about efficient screen space usage. If someone remembers why checking for an optical drive is useful here I'll try to fix this, otherwise I'll just remove the udisks code from startkde. Philip [1] http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kde-workspace/view/head:/debian/patches/kubuntu_plasma_netbook_for_small_screens.diff -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Kubuntu Policies (for council consideration)
On Mon, Feb 24, 2014 at 5:55 PM, Jonathan Riddell wrote: > On Wed, Feb 19, 2014 at 02:05:26PM +0100, Harald Sitter wrote: >> > As an exception where upstream bugs are due to be tracked until the >> > current release is out they can be filed, linked to upstream, tagged >> > ''kubuntu'' and milestoned to the next release. >> >> What is the benefit of that? > > So that bugs which need to be tracked for the release can be easily tracked. But what is the benefit of us tracking bugs we cannot do anything about? And that being said, which bugs would be considered trackworthy? And assuming the bugs do not get fixed upstream in time, what do we do? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Kubuntu Policies (for council consideration)
On Mon, Feb 24, 2014 at 7:09 PM, Scott Kitterman wrote: > On Monday, February 24, 2014 16:55:35 Jonathan Riddell wrote: >> > > ~kubuntu-members -> changed 6 months to "significant and sustained" >> > >> > >> > >> > ^ IMHO we really should have a hard value there, if 6 months seems to >> > long then perhaps 3 might be more acceptable, but I think a lot of the >> > recent candidates had a hard time knowing when exactly their >> > contirbution was sustained enough. the significance of things are hard >> > to define anyway, but one hard value seems better than a requirement >> > jellyfish. >> >> I'd prefer 3 months because I don't want to make it too hard to get >> membership, we should make it pretty easy to make people feel part of >> the gang. On the other hand I just checked Ubuntu which does say 6 >> months https://wiki.ubuntu.com/Membership/NewMember > > Since we are granting Ubuntu membership, I think the formal requirement needs > to be the same. My revised recommendation is we just copy from the Ubuntu > requirements and say: > >> We look for sustained and significant contributions. While there is no >> precise period that we look for, it is rare for applications to be accepted >> from people contributing for less than 6 months. > > We can decide how rare rare needs to be on a case by case basis. Page adjusted accordingly. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Kubuntu Policies (for council consideration)
On Mon, Feb 24, 2014 at 5:55 PM, Jonathan Riddell wrote: >> > It is useful to be able to add people to these teams where it eases >> > beginning to contribute to Kubuntu (thinking sgclark currently), bzr >> > branches can be easily reviewed. >> > ~kubuntu-packagers >> >> Indeed. There is a very discrete work flow for how one easily reviews >> a branch. That's a merge, and adding people to pseudo teams at the >> discretion of one council member is completely bypassing that. So, all >> that does is make it very convenient for people to not easily review >> the bzr branch at all, then upload, break things, giving me a >> heartattack. > > it's far more hassle to merge in a new branch, doing that 50 times makes a > lot of hassle. - bzr qdiff --new $REMOTE - (review) - bzr merge $REMOTE that seems considerably more convenient than: - bzr qlog - (find revisions that are different) - (review) former even can be scripted easily? >> > Merging >> > "When merging with Debian's packaging, each Kubuntu (and preferably >> > Debian) patch must be reviewed" >> >> ^ I think reviewing Debian's patches is out of scope TBH. While nice, >> it is completely pointless additional work we'd burden ourselfs with, >> which in turn will lead to people being sloppy about it and then >> retaining overall review quality at what we have right now with random >> patches doing random things floating about randomly for no reason >> whatsoever (e.g. the netbook favorites patch I recently ripped out >> workspace) > > that's why I say preferably, it's not a hard requirement, but it's not > uncommon to review Debian patches and find ones which should go > upstream. Why mention it then? If someone feels like reviewing those patches than they will do it anyway. Perhaps we shouldn't do review as part of merges to begin with but instead have a card for global patch review. That would reduce the time it takes to get merges done and at the same time makes us take the time to actually review all patches, not just ours (e.g. there's also upstream patches that somehow never actually got into upstream or weird stuff like that). HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
