Re: iso content review #2 report
On Tue, Mar 4, 2014 at 9:15 PM, Clay Weber c...@claydoh.com wrote: On Tuesday, March 04, 2014 07:01:48 PM Phil Wyett wrote: Ok, this may not be popular. We maybe could consider replacing amarok with a leaner alternative, for example juk. Regards Phil No, it will not be popular at all :p -1 y u hate on juk? :' -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: to be removed from the ISO krita kexi
On Wed, Mar 5, 2014 at 11:07 AM, Harald Sitter apachelog...@ubuntu.com wrote: On Tue, Mar 4, 2014 at 3:39 PM, Ovidiu-Florin Bogdan ovidiu@gmail.com wrote: On 04.03.2014 16:32, Phil Wyett wrote: If you cannot have a good image app then have none. kolourpaint is not up to being a well used default app, it just does not have the features. I would add krita as a featured app in discover. Regards Phil I dissagree. People need to have at least the basic image editing functionality. Similarly to how Windows comes with MS Paint. I believe that Kcolourpaint would fit this role. What for though? I absolutely fail to come up with an actual use case where you would want an application as simple as kolourpaint at all. On Windows it has sort of a use case for screenshots, since you need to paste them somewhere, so that usually ends up being Paint or Word. On Kubuntu that use case does not present because we have a nifty tool to manage screenshooting. For photo management/resizing/cropping you'll want to use Gwenview or Digikam. And as was mentioned, for actual drawing or pixel edition (a la photoshop) kolourpaint is not smart enough (i.e. lacks features and all that). Only thing that is left is not actual drawing (e.g. a child drawing random stuff to pass time, and no paper and pen were available...), hardly a use case TBH. So, again the question: what for does a Kubuntu user need a very dumb pixmap drawing application? Oh, FWIW, we do have libreoffice-draw (which is an equally simple drawing application) on the ISO (due to deps from Impress), so kolourpaint technically would duplicate that. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: to be removed from the ISO krita kexi
On 05.03.2014 12:11, Harald Sitter wrote: Oh, FWIW, we do have libreoffice-draw (which is an equally simple drawing application) on the ISO (due to deps from Impress), so kolourpaint technically would duplicate that. HS In this case, we can consider KColourPaint to be useless on the ISO. Any conclusions for Krita and Kexi? -- *Ovidiu-Florin Bogdan* GeekAliens.com http://geekaliens.com Kubuntu România http://ro.kubuntu.org -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: to be removed from the ISO krita kexi
On Wed, Mar 5, 2014 at 11:58 AM, Ovidiu-Florin Bogdan ovidiu@gmail.com wrote: On 05.03.2014 12:11, Harald Sitter wrote: Oh, FWIW, we do have libreoffice-draw (which is an equally simple drawing application) on the ISO (due to deps from Impress), so kolourpaint technically would duplicate that. HS In this case, we can consider KColourPaint to be useless on the ISO. Any conclusions for Krita and Kexi? Have been removed earlier today. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Call for translators!!
In data martedì 14 gennaio 2014 19:54:57, aaronhoneycutt ha scritto: Yes it is that point in the documentation's development. We need you translators to help us make our docs shine this release just head to userbase.kde.org/Kubuntu with your translator account and use your mojo! Let's make this a fantastic release guys and girls. Sent from my HTC - Reply message - From: Scarlett Clark scarl...@scarlettgatelyclark.com To: kubuntu-devel@lists.ubuntu.com Subject: Call for translators!! Date: Tue, Jan 14, 2014 5:47 PM Hi Aaron, I would like to translate this page. Is the translation manage by kubuntu-dev or do I need to work on Launchpad? AFAIK, these pages are managed directly by KDE, so maybe could be put inside the KDE translation process. Is is correct? Ciao -- Valter Open Source is better! KDE: www.kde.org Kubuntu: www.kubuntu.org LibreOffice: www.libreoffice.org -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Call for translators!!
In data mercoledì 5 marzo 2014 12:09:19, Valter Mura ha scritto: In data martedì 14 gennaio 2014 19:54:57, aaronhoneycutt ha scritto: Yes it is that point in the documentation's development. We need you translators to help us make our docs shine this release just head to userbase.kde.org/Kubuntu with your translator account and use your mojo! Let's make this a fantastic release guys and girls. Sent from my HTC - Reply message - From: Scarlett Clark scarl...@scarlettgatelyclark.com To: kubuntu-devel@lists.ubuntu.com Subject: Call for translators!! Date: Tue, Jan 14, 2014 5:47 PM Hi Aaron, I would like to translate this page. Is the translation manage by kubuntu-dev or do I need to work on Launchpad? AFAIK, these pages are managed directly by KDE, so maybe could be put inside the KDE translation process. Is is correct? Ok I found it, sorry for the post -- Valter Open Source is better! KDE: www.kde.org Kubuntu: www.kubuntu.org LibreOffice: www.libreoffice.org -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: iso content review #2 report
I will not offer a +-1 regarding Amarok (as I am currently not active in Kubuntu), but I, as a casual user, do find Juk to be a better - a more just play it oriented, less cluttered - option if I just want to listen to the music I have on my computer. Amarok is ok, but it also is quite formidable in that regard. I do appreciate Amarok's MTP support, though, that is the reason I still use it. Donatas Glodenis 2014-03-05 11:00 GMT+02:00 Harald Sitter apachelog...@ubuntu.com: On Tue, Mar 4, 2014 at 9:15 PM, Clay Weber c...@claydoh.com wrote: On Tuesday, March 04, 2014 07:01:48 PM Phil Wyett wrote: Ok, this may not be popular. We maybe could consider replacing amarok with a leaner alternative, for example juk. Regards Phil No, it will not be popular at all :p -1 y u hate on juk? :' -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
New list on Trello Board
Hi everyone After a brief discussion yesterday, it was decided to introduce a new list on trello labeled Review where cards can be moved if they require review. Preferably a reviewer should be assigned to each card along with appropriate links to branches/pastes/whatever mentioned in the comments section of the card. If cards do not require any review please move them directly from Doing to Done. Cheers Rohan Garg signature.asc Description: This is a digitally signed message part. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New list on Trello Board
On Wed, Mar 5, 2014 at 2:19 PM, Rohan Garg rohang...@kubuntu.org wrote: Hi everyone After a brief discussion yesterday, it was decided to introduce a new list on trello labeled Review where cards can be moved if they require review. Preferably a reviewer should be assigned to each card along with appropriate links to branches/pastes/whatever mentioned in the comments section of the card. If cards do not require any review please move them directly from Doing to Done. What if the review fails? back to todo or doing? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: New list on Trello Board
What if the review fails? back to todo or doing? Move back to TODO , card assignee then moves it to do Doing when he gets around to fixing bugs from review. Cheers Rohan Garg signature.asc Description: This is a digitally signed message part. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Kubuntu Testing and You
Ahoy everyone, As part of ongoing quality control measures for Kubuntu 14.04, we are introducing basic test cases that every user can run to ensure that core functionality such as instant messaging and playing MP3 files is working as expected. All tests are meant to take no more than 10 minutes and should be doable by just about everyone. They are the perfect way to get some basic testing done without all the hassle testing usually involves. If you are already testing Beta 1, head on over to our Quality Assurance Headquarters [1] to get the latest test cases. Feel free to run any test case, at any time. If you have any questions, send me a mail, reply to this thread, or stop by in #kubuntu-devel on irc.freenode.net. [1] http://qa.kubuntu.co.uk/smoke-tests.html HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: What does LTS *actually* mean
On Thu, Jan 30, 2014 at 12:38:45PM +0100, Harald Sitter wrote: On Wed, Jan 29, 2014 at 6:17 PM, Jonathan Riddell j...@jriddell.org wrote: What does support mean at all in respect to a Kubuntu release? We don't spend time fixing bugs in old releases generally. But if a fix is available and is requrested by a friendly user we should do the update. How would a user request a fix though? Usually that is a bug report, but we have a policy to move upstream reports upstream unless they are of considerable importance to us. So really there is no forum for the user to request a fix backport. We should evaluate any bugs to check if they are of considerable importance to us before moving upstream. In reality someone is more likely to ping on the mailing list or irc. On a general note though... should we? Because as I see it, if the user wants an update for an LTS release then we still need to SRU it through one or two not-lts releases. So someone will have to invest some time into verifying the SRU (assuming someone even could do it, which may not be possible if special hardware is required etc) and I am going to go out on a limb an say that this someone won't be the user who wanted to stick with LTS to begin with. As explained in some other mail, SRUs way too often go south because we are feeling particularly irie one day and want to fix the world by doing 30 SRUs and then later someone has to set aside time to do verfiication in a VM, for releases probably no one cares about to begin with. Generally they should be kept to a minimum except in the current stable release. Security fixes from KDE upstream and Qt upstream do get updated. Perhaps that should be the core target? Yep Jonathan -- 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 Wed, Feb 26, 2014 at 12:35:37PM +0100, Harald Sitter wrote: Allowing informal membership of kubuntu-packagers and kubuntu-ppa is a nice stepping stone to tell people they are valued and trusted contributors before we can give them full -membership or -dev privilages. (And I still think 6 months is too long for -membership or -dev, building community needs letting people in without too much barrier, one of the aims of Ubuntu was to allow a lower barrier of entry than Debian.) So it's a larger ubuntu issue and should be discussed as such. I don't have the energy to argue for a general ubuntu membership policy change to let in members with 6 months experience. But compared to KDE it's a long time to ask just to get on Planet ubuntu and a few other benefits. Bringing me back to the original argument that if a person cannot be formally trusted and accepted into one of the existing teams, then everyone must review all new changes in every bzr branch before uploading as otherwise they might be uploading something that is not as good as it ought to be, or at the worst malicious content. I would hope people to review changes of what they are uploading. But people can certainly be trusted to commit to bzr and upload to PPAs before they can be trusted to upload to the main Ubuntu archive. ~kubuntu-packagers holds the qt packaging which is also meddled with by ubuntu developers who would rightfully assume that only formally trusted people can commit changes there. However, that would no longer be the case if we add people informally to that team simply because we decide to trust their abilities enough. So we'd then potentially lure !kubuntu members into uploading potentially bad or malicious content because they did not know that we have a lax policy on who gets to change the official packaging branches. Again they should review what they are uploading. But anyone given access to ~kubuntu-packagers who didn't know about qt packaging and committed to qt packaging would not have access for very long. And that is why neither kubuntu-packagers nor kubuntu-ppa should be directly joined. We have trust validation processes in place (becoming kubuntu-dev or kubuntu-member), if the time barriers to join those are too long, then a resolution/exception should be sought in ubuntu at large, not work around the perhaps ludicrous barrier by allowing people to sneak in changes even though they really shouldn't be able to sneak in anything anywhere. I still strongly disagree, I think we should have a stepping stone to being able to upload to the Ubuntu archive and we should give people access where they have shown they are competant and know their own limits. In the case of Scarlett (sorry to use you as an example) she's rapidly learning the important points of library packaging so I hope to not have to review her changes soon and just let her upload to the PPA. Currently she has to wait around until I find time to review which blocks her and takes time from me. How would you handle her situation under your proposal? Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: What does LTS *actually* mean
On Wed, Mar 5, 2014 at 5:58 PM, Jonathan Riddell j...@jriddell.org wrote: On Thu, Jan 30, 2014 at 12:38:45PM +0100, Harald Sitter wrote: On Wed, Jan 29, 2014 at 6:17 PM, Jonathan Riddell j...@jriddell.org wrote: What does support mean at all in respect to a Kubuntu release? We don't spend time fixing bugs in old releases generally. But if a fix is available and is requrested by a friendly user we should do the update. How would a user request a fix though? Usually that is a bug report, but we have a policy to move upstream reports upstream unless they are of considerable importance to us. So really there is no forum for the user to request a fix backport. We should evaluate any bugs to check if they are of considerable importance to us before moving upstream. In reality someone is more likely to ping on the mailing list or irc. What is an important bug then? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: What does LTS *actually* mean
On Wed, Mar 05, 2014 at 06:41:58PM +0100, Harald Sitter wrote: On Wed, Mar 5, 2014 at 5:58 PM, Jonathan Riddell j...@jriddell.org wrote: On Thu, Jan 30, 2014 at 12:38:45PM +0100, Harald Sitter wrote: On Wed, Jan 29, 2014 at 6:17 PM, Jonathan Riddell j...@jriddell.org wrote: What does support mean at all in respect to a Kubuntu release? We don't spend time fixing bugs in old releases generally. But if a fix is available and is requrested by a friendly user we should do the update. How would a user request a fix though? Usually that is a bug report, but we have a policy to move upstream reports upstream unless they are of considerable importance to us. So really there is no forum for the user to request a fix backport. We should evaluate any bugs to check if they are of considerable importance to us before moving upstream. In reality someone is more likely to ping on the mailing list or irc. What is an important bug then? It's subjective but generally one guideline is one which if not fixed is important enough to be release noted. Jonathan -- 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 Wed, Mar 5, 2014 at 6:06 PM, Jonathan Riddell j...@jriddell.org wrote: I still strongly disagree, I think we should have a stepping stone to being able to upload to the Ubuntu archive and we should give people access where they have shown they are competant and know their own limits. In the case of Scarlett (sorry to use you as an example) she's rapidly learning the important points of library packaging so I hope to not have to review her changes soon and just let her upload to the PPA. Currently she has to wait around until I find time to review which blocks her and takes time from me. How would you handle her situation under your proposal? Let's repurpose kubuntu-ninjas the way it is practically used. ~kubuntu-ninjas becomes member of ~kubuntu-packagers and ~kubuntu-ppa. ~kubuntu-dev becomes admin of ~kubuntu-ninjas. Process for joining ninjas is a mail to the list asking to become ninja, as soon as 2 devs vouge for the candidate they may ascend to ninjahood gaining access to all our PPAs and the packaging branches. It doesn't really resolve my reservations about taking away the mandatory review process, but as long as ~kubuntu-dev and ~kubuntu-council feel this is an acceptable approach to pragmatic packaging, I am happy. This would however mean that someone who is not member, not dev, and cannot be accepted by dev (e.g. someone who is being brought in for testing), cannot join the private PPA. So, if that is something we want to do, an alternate approach would be to introduce a new group ~kubuntu-acolytes which is member of -ninjas, -packagers, -ppa. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: iso content review #2 report
On Thu, Mar 6, 2014 at 12:45 AM, Aleix Pol aleix...@kde.org wrote: Note that one of the best parts of using a GNU/Linux distribution is the possibility to install software easily, especially if you have Muon Discover (wink). omg :O Furthermore, I don't think it's that essential having a by-playlists player by default with the OS. There is dragon player as well right? Well, dragon player is no audio player and playlists for videos are only particularly useful for one type of video Anyway, IMO exchanging Amarok with JuK would not improve anything. Yes it would reduce ISO space consumption (amarok has a pile of icons and dependencies), but Amarok also has quite some critical features (e.g. the ability to syncing music stuff to an ipod). Iff there was a global workspace multimedia collection/database and a resonable GUI backing to address these use cases in other ways, or if JuK had this type of feature as well, the argument might look different. 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 Wed, Mar 5, 2014 at 7:05 PM, Jonathan Riddell j...@jriddell.org wrote: On Wed, Mar 05, 2014 at 06:57:45PM +0100, Harald Sitter wrote: Let's repurpose kubuntu-ninjas the way it is practically used. Yes that seems a promising idea. Any preference as to whether ~kubuntu-ninja membership should be restricted or a new ~kubuntu-acolytes team should be created? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: What does LTS *actually* mean
On Wed, Mar 5, 2014 at 6:51 PM, Jonathan Riddell j...@jriddell.org wrote: On Wed, Mar 05, 2014 at 06:41:58PM +0100, Harald Sitter wrote: On Wed, Mar 5, 2014 at 5:58 PM, Jonathan Riddell j...@jriddell.org wrote: On Thu, Jan 30, 2014 at 12:38:45PM +0100, Harald Sitter wrote: On Wed, Jan 29, 2014 at 6:17 PM, Jonathan Riddell j...@jriddell.org wrote: What does support mean at all in respect to a Kubuntu release? We don't spend time fixing bugs in old releases generally. But if a fix is available and is requrested by a friendly user we should do the update. How would a user request a fix though? Usually that is a bug report, but we have a policy to move upstream reports upstream unless they are of considerable importance to us. So really there is no forum for the user to request a fix backport. We should evaluate any bugs to check if they are of considerable importance to us before moving upstream. In reality someone is more likely to ping on the mailing list or irc. What is an important bug then? It's subjective but generally one guideline is one which if not fixed is important enough to be release noted. Raising the question what qualifies a bug as important enough to be release noted. That also seemed a bit oho, the day before release I found this bug report in my inbox, we should have a release note for it at times ;) ^ perhaps that should also be defined in some policy. Off the top of my head I'd say: - package is on the ISO/package-set or visibly promoted (e.g. the featured apps in discover) - bug breaks core functionality of the application (e.g. crash on startup or crash whenever one tries to use the core functionality, like trying to hit play in amarok) - OR bug hinders intended UX of the core functionality (e.g. amarok constantly popping up a messagebox when the track changes) - OR bug is causing substantial (relative) amounts of automated crash reports on errors.ubuntu (random number: top 5 crashers subscribed by kubuntu-bugs) - OR upstream requests the bug to be noted and resolved - AND upstream is aware and investigating ^ those are upstream bugs that *may* be tracked on launchpad for general interest and book keeping and eventually result in release notes when not resolved in time. since upstream must be aware and investigating we can expect some sort of fix at some point in the not too distant future which ultimately means that those types of bugs will and should not be open for more than 6 months and as such also perfectly align with the LTS policy as per the current draft. I actually have a definition for core functionality in case you are wondering (the dead upstream policy also mentions this concept, but I decided not to define it there as the dead upstream assessment can do with some leeway as it comes down to the developer's judgement at the end of the day): Core functionality of an *application* (note application, libraries are to be excluded; either a bug in a library afffects the core functionality of an application or it will not qualify) are all things one can see when opening the application (excluding menubar) as well as everything necessary to deliver basic core functionality. To give some examples for latter: - amarok is a music manager and *player*, hence playback is a core functionality as well as the collection - kde telepathy is an instant messaging system, hence the messaging must be working (although not part of the contact-list default view) - k3b is a burning application, hence it must be able to burn any old CD (also, technically not part of the default UI) In addition to that, the draft for Stable Updates outside the SC update policy explicitly allows a user to request a SRU for every bug that has a known upstream resolution as long as the target series is either current stable or the user is able to find testers for all supported release back to the one he wants the SRU for. So, this should permit your original assertation that we'd push an SRU if a user requests one, as those bug reports are then not considered actual reports but requests for a SRU (i.e. upstream fix is available, so as long as the testing requirement is met there is no reason not to resolve the request). 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 Thursday, March 06, 2014 01:54:59 Harald Sitter wrote: On Wed, Mar 5, 2014 at 7:05 PM, Jonathan Riddell j...@jriddell.org wrote: On Wed, Mar 05, 2014 at 06:57:45PM +0100, Harald Sitter wrote: Let's repurpose kubuntu-ninjas the way it is practically used. Yes that seems a promising idea. Any preference as to whether ~kubuntu-ninja membership should be restricted or a new ~kubuntu-acolytes team should be created? Since it grants access to the private PPA that we build/pull pre-release packages from, I think it needs to be restricted in some manner. I'm not sure how heavily. Scott K -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
