Re: Final thoughts/votes on Kubuntu Policy
On Wed, Aug 6, 2014 at 7:14 PM, Scott Kitterman wrote: > On Wednesday, August 06, 2014 18:05:20 Harald Sitter wrote: >> On Wed, Aug 6, 2014 at 3:24 PM, Scott Kitterman > wrote: >> > On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: >> >> On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman >> > >> > wrote: >> >> > On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: >> >> >> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman >> >> > >> >> > wrote: >> >> >> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: >> >> >> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman >> >> >> >> >> >> >> > >> >> >> > wrote: >> >> >> >> > I, for one, >> >> >> >> > think the notion that we won't apply known fixes because upstream >> >> >> >> > is >> >> >> >> > non- >> >> >> >> > responsive is silly. I don't intend to be bound by it. >> >> >> >> >> >> >> >> Where does the fix come from then? >> >> >> > >> >> >> > Could be defective Python code I figured out by myself (for >> >> >> > reference, >> >> >> > this >> >> >> > exact scenario is why we had an even sort of working displayconfig >> >> >> > in >> >> >> > hardy - if this policy had been in effect, it would have had to be >> >> >> > removed and not replaced since there was no replacement available). >> >> >> >> >> >> so why did you not pick up maintainership? >> >> > >> >> > Because it would have needed a full rewrite to work with the then brand >> >> > new X stack reliably. We were going to have a new tool for Intrepid >> >> > anyway, so beating it into sort of working was enough for Kubuntu and >> >> > I'm >> >> > certainly not qualified to take on upstream development for all of KDE. >> >> >> >> Why would you not be qualified? You created a Kubuntu specific fork of >> >> the software, so since you were fit to maintain that one I am sure the >> >> same would have worked upstream. Seeing as you were able to beat it >> >> into working state for Kubuntu it would appear to me that there is >> >> nothing that would have prevented you from doing the change upstream >> >> and releasing a new tarball. At worse you had to roll a tarball >> >> instead of dumping a patch into debian/ (which would then have had >> >> up-to-date translations thus possibly not being all that much of a >> >> waste of time to begin with), at best 3 other distributions had picked >> >> it up and thanks to that ended up with a working display config in >> >> their LTS release. >> > >> > Perhaps. That would have required some commitment on my part to do work >> > to >> > support other distros that I wasn't willing to take on. Since the X stuff >> > does vary from distro to distro, I had (and still have) no idea what of >> > what I was doing was Ubuntu specific and what might be generally >> > applicable. >> >> I hear kwin does fine without distribution specific solutions. At any >> rate, if a distro had not been able to use it because of compatibility >> issues and you were not willing or capable or whatever to resolve it, >> that would have been where they needed to make their own decisions on >> whether to patch it into working state and hopefully upstream that >> patch or not ship it at all or ship the old version or whatever. By >> not going out and saying "this here software is unmaintained, I made >> it so it works with kubuntu and relased version x.y which is less >> shitty than the previous release" you pretty much excluded others from >> an option to possibly use it as we cannot expect others to track what >> we patch or don't patch (just like we don't track every other distros >> patch work). So had another distro needed it worst case they'd have >> duplicated the work on their own or be lucky enough to find our patch >> through a web search. >> >> >> The reasons why we don't want to condone dead upstream pseudo >> >> maintenance patchy nonesense is multifaceted. The fact that distro >> >> patchy is selfish towards everyone else is one part of it. Another one >> >> is that the patch policy needs a responsible person up the stream to >> >> review and approve and possibly merge a patch, with out one the patch >> >> policy doesn't allow certain patches at all. >> >> Another important side of the argument is that of reliable and >> >> balanced quality. No one takes on responsibility for the quality, so >> >> we must assume it has excessively shitty quality or is of no use >> >> because otherwise someone were to feel the need to stand up and take >> >> on maintenance or at the very least care enough to fix startup >> >> crashes, data loss, bug triage etc.etc.. And ultimately that leads to >> >> the question of whether we should have a piece of software of >> >> obviously shitty quality under our wings to begin with considering no >> >> one else wants to care about it either. >> > >> > I generally agree with that, but there are cases where all the >> > alternatives >> > were worse. Shipping without any tool at all to configure a monitor was a >> > non- starter. >> >> There pret
Re: Final thoughts/votes on Kubuntu Policy
On Wednesday, August 06, 2014 18:05:20 Harald Sitter wrote: > On Wed, Aug 6, 2014 at 3:24 PM, Scott Kitterman wrote: > > On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: > >> On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman > > > > wrote: > >> > On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: > >> >> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman > >> > > >> > wrote: > >> >> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: > >> >> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman > >> >> >> > >> >> > > >> >> > wrote: > >> >> >> > I, for one, > >> >> >> > think the notion that we won't apply known fixes because upstream > >> >> >> > is > >> >> >> > non- > >> >> >> > responsive is silly. I don't intend to be bound by it. > >> >> >> > >> >> >> Where does the fix come from then? > >> >> > > >> >> > Could be defective Python code I figured out by myself (for > >> >> > reference, > >> >> > this > >> >> > exact scenario is why we had an even sort of working displayconfig > >> >> > in > >> >> > hardy - if this policy had been in effect, it would have had to be > >> >> > removed and not replaced since there was no replacement available). > >> >> > >> >> so why did you not pick up maintainership? > >> > > >> > Because it would have needed a full rewrite to work with the then brand > >> > new X stack reliably. We were going to have a new tool for Intrepid > >> > anyway, so beating it into sort of working was enough for Kubuntu and > >> > I'm > >> > certainly not qualified to take on upstream development for all of KDE. > >> > >> Why would you not be qualified? You created a Kubuntu specific fork of > >> the software, so since you were fit to maintain that one I am sure the > >> same would have worked upstream. Seeing as you were able to beat it > >> into working state for Kubuntu it would appear to me that there is > >> nothing that would have prevented you from doing the change upstream > >> and releasing a new tarball. At worse you had to roll a tarball > >> instead of dumping a patch into debian/ (which would then have had > >> up-to-date translations thus possibly not being all that much of a > >> waste of time to begin with), at best 3 other distributions had picked > >> it up and thanks to that ended up with a working display config in > >> their LTS release. > > > > Perhaps. That would have required some commitment on my part to do work > > to > > support other distros that I wasn't willing to take on. Since the X stuff > > does vary from distro to distro, I had (and still have) no idea what of > > what I was doing was Ubuntu specific and what might be generally > > applicable. > > I hear kwin does fine without distribution specific solutions. At any > rate, if a distro had not been able to use it because of compatibility > issues and you were not willing or capable or whatever to resolve it, > that would have been where they needed to make their own decisions on > whether to patch it into working state and hopefully upstream that > patch or not ship it at all or ship the old version or whatever. By > not going out and saying "this here software is unmaintained, I made > it so it works with kubuntu and relased version x.y which is less > shitty than the previous release" you pretty much excluded others from > an option to possibly use it as we cannot expect others to track what > we patch or don't patch (just like we don't track every other distros > patch work). So had another distro needed it worst case they'd have > duplicated the work on their own or be lucky enough to find our patch > through a web search. > > >> The reasons why we don't want to condone dead upstream pseudo > >> maintenance patchy nonesense is multifaceted. The fact that distro > >> patchy is selfish towards everyone else is one part of it. Another one > >> is that the patch policy needs a responsible person up the stream to > >> review and approve and possibly merge a patch, with out one the patch > >> policy doesn't allow certain patches at all. > >> Another important side of the argument is that of reliable and > >> balanced quality. No one takes on responsibility for the quality, so > >> we must assume it has excessively shitty quality or is of no use > >> because otherwise someone were to feel the need to stand up and take > >> on maintenance or at the very least care enough to fix startup > >> crashes, data loss, bug triage etc.etc.. And ultimately that leads to > >> the question of whether we should have a piece of software of > >> obviously shitty quality under our wings to begin with considering no > >> one else wants to care about it either. > > > > I generally agree with that, but there are cases where all the > > alternatives > > were worse. Shipping without any tool at all to configure a monitor was a > > non- starter. > > There pretty much always is an almost equally suitable alternative > (case in point: displayconfig-gtk). > > But yeah, let's assume there really is n
Re: Final thoughts/votes on Kubuntu Policy
On Wed, Aug 6, 2014 at 3:24 PM, Scott Kitterman wrote: > On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: >> On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman > wrote: >> > On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: >> >> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman >> > >> > wrote: >> >> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: >> >> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman >> >> > >> >> > wrote: >> >> >> > I, for one, >> >> >> > think the notion that we won't apply known fixes because upstream is >> >> >> > non- >> >> >> > responsive is silly. I don't intend to be bound by it. >> >> >> >> >> >> Where does the fix come from then? >> >> > >> >> > Could be defective Python code I figured out by myself (for reference, >> >> > this >> >> > exact scenario is why we had an even sort of working displayconfig in >> >> > hardy - if this policy had been in effect, it would have had to be >> >> > removed and not replaced since there was no replacement available). >> >> >> >> so why did you not pick up maintainership? >> > >> > Because it would have needed a full rewrite to work with the then brand >> > new X stack reliably. We were going to have a new tool for Intrepid >> > anyway, so beating it into sort of working was enough for Kubuntu and I'm >> > certainly not qualified to take on upstream development for all of KDE. >> >> Why would you not be qualified? You created a Kubuntu specific fork of >> the software, so since you were fit to maintain that one I am sure the >> same would have worked upstream. Seeing as you were able to beat it >> into working state for Kubuntu it would appear to me that there is >> nothing that would have prevented you from doing the change upstream >> and releasing a new tarball. At worse you had to roll a tarball >> instead of dumping a patch into debian/ (which would then have had >> up-to-date translations thus possibly not being all that much of a >> waste of time to begin with), at best 3 other distributions had picked >> it up and thanks to that ended up with a working display config in >> their LTS release. > > Perhaps. That would have required some commitment on my part to do work to > support other distros that I wasn't willing to take on. Since the X stuff > does > vary from distro to distro, I had (and still have) no idea what of what I was > doing was Ubuntu specific and what might be generally applicable. I hear kwin does fine without distribution specific solutions. At any rate, if a distro had not been able to use it because of compatibility issues and you were not willing or capable or whatever to resolve it, that would have been where they needed to make their own decisions on whether to patch it into working state and hopefully upstream that patch or not ship it at all or ship the old version or whatever. By not going out and saying "this here software is unmaintained, I made it so it works with kubuntu and relased version x.y which is less shitty than the previous release" you pretty much excluded others from an option to possibly use it as we cannot expect others to track what we patch or don't patch (just like we don't track every other distros patch work). So had another distro needed it worst case they'd have duplicated the work on their own or be lucky enough to find our patch through a web search. >> The reasons why we don't want to condone dead upstream pseudo >> maintenance patchy nonesense is multifaceted. The fact that distro >> patchy is selfish towards everyone else is one part of it. Another one >> is that the patch policy needs a responsible person up the stream to >> review and approve and possibly merge a patch, with out one the patch >> policy doesn't allow certain patches at all. >> Another important side of the argument is that of reliable and >> balanced quality. No one takes on responsibility for the quality, so >> we must assume it has excessively shitty quality or is of no use >> because otherwise someone were to feel the need to stand up and take >> on maintenance or at the very least care enough to fix startup >> crashes, data loss, bug triage etc.etc.. And ultimately that leads to >> the question of whether we should have a piece of software of >> obviously shitty quality under our wings to begin with considering no >> one else wants to care about it either. > > I generally agree with that, but there are cases where all the alternatives > were worse. Shipping without any tool at all to configure a monitor was a > non- > starter. There pretty much always is an almost equally suitable alternative (case in point: displayconfig-gtk). But yeah, let's assume there really is no replacement software available, and no one is willing to actually do an upstream commit (which is really a social problem as I am absolutely willing to go on record that there is next to no overhead when doing things upstream with no maintainer being there to stand in your way). We have then failed have w
Re: Final thoughts/votes on Kubuntu Policy
On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: > On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman wrote: > > On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: > >> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman > > > > wrote: > >> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: > >> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman > >> > > >> > wrote: > >> >> > I, for one, > >> >> > think the notion that we won't apply known fixes because upstream is > >> >> > non- > >> >> > responsive is silly. I don't intend to be bound by it. > >> >> > >> >> Where does the fix come from then? > >> > > >> > Could be defective Python code I figured out by myself (for reference, > >> > this > >> > exact scenario is why we had an even sort of working displayconfig in > >> > hardy - if this policy had been in effect, it would have had to be > >> > removed and not replaced since there was no replacement available). > >> > >> so why did you not pick up maintainership? > > > > Because it would have needed a full rewrite to work with the then brand > > new X stack reliably. We were going to have a new tool for Intrepid > > anyway, so beating it into sort of working was enough for Kubuntu and I'm > > certainly not qualified to take on upstream development for all of KDE. > > Why would you not be qualified? You created a Kubuntu specific fork of > the software, so since you were fit to maintain that one I am sure the > same would have worked upstream. Seeing as you were able to beat it > into working state for Kubuntu it would appear to me that there is > nothing that would have prevented you from doing the change upstream > and releasing a new tarball. At worse you had to roll a tarball > instead of dumping a patch into debian/ (which would then have had > up-to-date translations thus possibly not being all that much of a > waste of time to begin with), at best 3 other distributions had picked > it up and thanks to that ended up with a working display config in > their LTS release. Perhaps. That would have required some commitment on my part to do work to support other distros that I wasn't willing to take on. Since the X stuff does vary from distro to distro, I had (and still have) no idea what of what I was doing was Ubuntu specific and what might be generally applicable. > The reasons why we don't want to condone dead upstream pseudo > maintenance patchy nonesense is multifaceted. The fact that distro > patchy is selfish towards everyone else is one part of it. Another one > is that the patch policy needs a responsible person up the stream to > review and approve and possibly merge a patch, with out one the patch > policy doesn't allow certain patches at all. > Another important side of the argument is that of reliable and > balanced quality. No one takes on responsibility for the quality, so > we must assume it has excessively shitty quality or is of no use > because otherwise someone were to feel the need to stand up and take > on maintenance or at the very least care enough to fix startup > crashes, data loss, bug triage etc.etc.. And ultimately that leads to > the question of whether we should have a piece of software of > obviously shitty quality under our wings to begin with considering no > one else wants to care about it either. I generally agree with that, but there are cases where all the alternatives were worse. Shipping without any tool at all to configure a monitor was a non- starter. > All that being said, perhaps the policy ought to be amended to say > that instead of having the package removed from the archive it must > not be on our ISOs and Kubuntu should not be the maintainer. At the > end of the day what someone does because they want to is their own > business. So, if someone feels like foobar should be in the archive > and that they feel up to the task of keeping it not broken that's > their choice to make and execute. Even if it then reflects badly on > Kubuntu and Ubuntu at large if a user installs that software and finds > it to be unusable for whatever reason. There is not much one can do > about that, and this is a global problem to some extent anyway. That's true. It's definitely beyond the scope of what Kubuntu policy could mandate to insist on packages being removed from the archive if someone did not want them removed. That said, we still have the situation where the unmaintained crap we have is better than the alternatives available. > But, we as creators of Kubuntu however should not support selfish > life-support patching for the software we use to build our product on. > It does not benefit anyone to drag along broken unreliable software. > Giving it the boot on the other hand does not only free up resources > better spent elsewhere, it also makes people moan and whine about this > super important application that is now gone and this makes it all the > more likely that someone steps up and does what needs to be done to > make
Re: Final thoughts/votes on Kubuntu Policy
On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman wrote: > On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: >> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman > wrote: >> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: >> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman >> > >> > wrote: >> >> > I, for one, >> >> > think the notion that we won't apply known fixes because upstream is >> >> > non- >> >> > responsive is silly. I don't intend to be bound by it. >> >> >> >> Where does the fix come from then? >> > >> > Could be defective Python code I figured out by myself (for reference, >> > this >> > exact scenario is why we had an even sort of working displayconfig in >> > hardy - if this policy had been in effect, it would have had to be >> > removed and not replaced since there was no replacement available). >> >> so why did you not pick up maintainership? > > Because it would have needed a full rewrite to work with the then brand new X > stack reliably. We were going to have a new tool for Intrepid anyway, so > beating it into sort of working was enough for Kubuntu and I'm certainly not > qualified to take on upstream development for all of KDE. Why would you not be qualified? You created a Kubuntu specific fork of the software, so since you were fit to maintain that one I am sure the same would have worked upstream. Seeing as you were able to beat it into working state for Kubuntu it would appear to me that there is nothing that would have prevented you from doing the change upstream and releasing a new tarball. At worse you had to roll a tarball instead of dumping a patch into debian/ (which would then have had up-to-date translations thus possibly not being all that much of a waste of time to begin with), at best 3 other distributions had picked it up and thanks to that ended up with a working display config in their LTS release. The reasons why we don't want to condone dead upstream pseudo maintenance patchy nonesense is multifaceted. The fact that distro patchy is selfish towards everyone else is one part of it. Another one is that the patch policy needs a responsible person up the stream to review and approve and possibly merge a patch, with out one the patch policy doesn't allow certain patches at all. Another important side of the argument is that of reliable and balanced quality. No one takes on responsibility for the quality, so we must assume it has excessively shitty quality or is of no use because otherwise someone were to feel the need to stand up and take on maintenance or at the very least care enough to fix startup crashes, data loss, bug triage etc.etc.. And ultimately that leads to the question of whether we should have a piece of software of obviously shitty quality under our wings to begin with considering no one else wants to care about it either. All that being said, perhaps the policy ought to be amended to say that instead of having the package removed from the archive it must not be on our ISOs and Kubuntu should not be the maintainer. At the end of the day what someone does because they want to is their own business. So, if someone feels like foobar should be in the archive and that they feel up to the task of keeping it not broken that's their choice to make and execute. Even if it then reflects badly on Kubuntu and Ubuntu at large if a user installs that software and finds it to be unusable for whatever reason. There is not much one can do about that, and this is a global problem to some extent anyway. But, we as creators of Kubuntu however should not support selfish life-support patching for the software we use to build our product on. It does not benefit anyone to drag along broken unreliable software. Giving it the boot on the other hand does not only free up resources better spent elsewhere, it also makes people moan and whine about this super important application that is now gone and this makes it all the more likely that someone steps up and does what needs to be done to make it a super awesome piece of software again. The present policy is already given a lot of leeway to make sure the user doesn't need to suffer unless there really is no other way. But the must-not-be-patched thing is really not something that can be changed or removed IMO. If patching maintained software is semi-forking then patching unmaintained software that is entirely broken as per the presented check list is a definite fork because the patched version is then the only working version and thus the defacto source to be used. So, your concern is that this sort of short term workaround isn't possible with the presented policy, but really it is. Instead of making a distro patch you would commit your bandaid solution upstream, release a new tarball. By doing that you are making your work easily available to others and improve the quality of the upstream product. You'd then be a maintainer (of sorts). Other distros as well as our guys might have additional tweaks so they
Re: Final thoughts/votes on Kubuntu Policy
On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: > On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman wrote: > > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: > >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman > > > > wrote: > >> > I, for one, > >> > think the notion that we won't apply known fixes because upstream is > >> > non- > >> > responsive is silly. I don't intend to be bound by it. > >> > >> Where does the fix come from then? > > > > Could be defective Python code I figured out by myself (for reference, > > this > > exact scenario is why we had an even sort of working displayconfig in > > hardy - if this policy had been in effect, it would have had to be > > removed and not replaced since there was no replacement available). > > so why did you not pick up maintainership? Because it would have needed a full rewrite to work with the then brand new X stack reliably. We were going to have a new tool for Intrepid anyway, so beating it into sort of working was enough for Kubuntu and I'm certainly not qualified to take on upstream development for all of KDE. 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: Final thoughts/votes on Kubuntu Policy
On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman wrote: > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman > wrote: >> > I, for one, >> > think the notion that we won't apply known fixes because upstream is non- >> > responsive is silly. I don't intend to be bound by it. >> >> Where does the fix come from then? > > Could be defective Python code I figured out by myself (for reference, this > exact scenario is why we had an even sort of working displayconfig in hardy - > if this policy had been in effect, it would have had to be removed and not > replaced since there was no replacement available). so why did you not pick up maintainership? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Final thoughts/votes on Kubuntu Policy
On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: > On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman wrote: > > I, for one, > > think the notion that we won't apply known fixes because upstream is non- > > responsive is silly. I don't intend to be bound by it. > > Where does the fix come from then? Could be defective Python code I figured out by myself (for reference, this exact scenario is why we had an even sort of working displayconfig in hardy - if this policy had been in effect, it would have had to be removed and not replaced since there was no replacement available). 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: Final thoughts/votes on Kubuntu Policy
On Tuesday, August 05, 2014 19:36:43 Myriam Schweingruber wrote: > Hi all, > > On Tue, Aug 5, 2014 at 6:14 PM, Jonathan Riddell wrote: > > Update done, +1 from me. So that's me and Rohan. Other council members > > want to vote? > > > > Jonathan > > I just gave it a quick glance, until I missed something: > > +1 from me :) > > Regards, Myriam I think that there are some changes needed. 1. We have an agreed set of rules on what it takes to be a kubuntu-dev that the DMB approved. Any discussion of kubuntu-dev requirements should reference that. 2. Why is the KC the right level to decide on things like patch policy? I think the developers that have to do the work should decide. I, for one, think the notion that we won't apply known fixes because upstream is non- responsive is silly. I don't intend to be bound by it. There are other things, but I'm short on time to review it. Note: Nothing about how packages are updated really affect actions of other Ubuntu devs, so I'm not sure of the point. 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: Final thoughts/votes on Kubuntu Policy
On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman wrote: > I, for one, > think the notion that we won't apply known fixes because upstream is non- > responsive is silly. I don't intend to be bound by it. Where does the fix come from 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: Final thoughts/votes on Kubuntu Policy
Hi all, On Tue, Aug 5, 2014 at 6:14 PM, Jonathan Riddell wrote: > Update done, +1 from me. So that's me and Rohan. Other council members > want to vote? > > Jonathan > > I just gave it a quick glance, until I missed something: +1 from me :) Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Final thoughts/votes on Kubuntu Policy
On Tuesday 05 August 2014 18:14:57 Jonathan Riddell wrote: > Update done, +1 from me. So that's me and Rohan. Other council members > want to vote? > > Jonathan Sure, I'm fine with the changes and I'm +1 for the policy. > > > > On 26 July 2014 10:50, Valorie Zimmerman > wrote: > > > On Mon, Jul 21, 2014 at 4:20 AM, Jonathan Riddell wrote: > > > > > > Read it over again, looks great, some comments.. > > > > > > "Software that is not managed on KDE's infrastructure is considered > > unrelated to KDE. " > > > "Official KDE software is generally every piece of software that has an > > official VCS on KDE's infrastructure and/or uses KDE's bug tracker. " > > > KDE software is software that complies with the KDE manifesto, not > > necessarily on KDE's own infrastructure. > > > > > > "A bug is considered to have high impact if... AND upstream is aware > > and investigating " > > > Sometimes upstream won't care as it's a released version or it doesn't > > affect their distro, I think this bug requirement should be losened > > > > > > "Election Process ((TBD)) " > > > should say that it's ~kubuntu-members who vote on council members > > > > > > "This is limited to the packages inside the kubuntu package set. " > > > link to package set list? > > > > > > "Existing ~kubuntu-members member, survive an interview by > > ~kubuntu-dev, get accepted by >= 3 existing developers." > > > saying nothing about the 50 members who disapproved, should say a > > majority in favour > > > > > > "Stable Updates ... KDE SC" > > > this section will need to be reviewed and > > > updated for KF5 land including in the first case KDE Applications > > > which are due to replace KDE SC before the end of this year and > > > includes kdelibs4 software as well as KF5 software. A job for later, > > but not too much later. > > > > > > One question is how does all this apply to Qt? It's packaged by some > > > nice people working for Canonical and they generally work nicely with > > > Debian and upstream and we don't want to scare/piss them off, but they > > > can be lax at sending patches upstream. I think they should be asked > > > how much they feel able to comply to these policies. > > > > > > I can go ahead and make these changes if people agree. > > > > > > Jonathan > > > > Since there is no disagreement, (speak up if there is) please carry on > > Jonathan. We should get this published before we need to edit it to > > account for KF5, Plasma 5 & KDE Applications. > > > > Valorie > > > > -- > > 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
Re: Final thoughts/votes on Kubuntu Policy
Update done, +1 from me. So that's me and Rohan. Other council members want to vote? Jonathan On 26 July 2014 10:50, Valorie Zimmerman wrote: > On Mon, Jul 21, 2014 at 4:20 AM, Jonathan Riddell wrote: > > > > Read it over again, looks great, some comments.. > > > > "Software that is not managed on KDE's infrastructure is considered > unrelated to KDE. " > > "Official KDE software is generally every piece of software that has an > official VCS on KDE's infrastructure and/or uses KDE's bug tracker. " > > KDE software is software that complies with the KDE manifesto, not > necessarily on KDE's own infrastructure. > > > > "A bug is considered to have high impact if... AND upstream is aware > and investigating " > > Sometimes upstream won't care as it's a released version or it doesn't > affect their distro, I think this bug requirement should be losened > > > > "Election Process ((TBD)) " > > should say that it's ~kubuntu-members who vote on council members > > > > "This is limited to the packages inside the kubuntu package set. " > > link to package set list? > > > > "Existing ~kubuntu-members member, survive an interview by > ~kubuntu-dev, get accepted by >= 3 existing developers." > > saying nothing about the 50 members who disapproved, should say a > majority in favour > > > > "Stable Updates ... KDE SC" > > this section will need to be reviewed and > > updated for KF5 land including in the first case KDE Applications > > which are due to replace KDE SC before the end of this year and > > includes kdelibs4 software as well as KF5 software. A job for later, > but not too much later. > > > > One question is how does all this apply to Qt? It's packaged by some > > nice people working for Canonical and they generally work nicely with > > Debian and upstream and we don't want to scare/piss them off, but they > > can be lax at sending patches upstream. I think they should be asked > > how much they feel able to comply to these policies. > > > > I can go ahead and make these changes if people agree. > > > > Jonathan > > Since there is no disagreement, (speak up if there is) please carry on > Jonathan. We should get this published before we need to edit it to > account for KF5, Plasma 5 & KDE Applications. > > Valorie > > -- > 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
Re: Final thoughts/votes on Kubuntu Policy
On Mon, Jul 21, 2014 at 4:20 AM, Jonathan Riddell wrote: > > Read it over again, looks great, some comments.. > > "Software that is not managed on KDE's infrastructure is considered > unrelated to KDE. " > "Official KDE software is generally every piece of software that has an > official VCS on KDE's infrastructure and/or uses KDE's bug tracker. " > KDE software is software that complies with the KDE manifesto, not > necessarily on KDE's own infrastructure. > > "A bug is considered to have high impact if... AND upstream is aware and > investigating " > Sometimes upstream won't care as it's a released version or it doesn't affect > their distro, I think this bug requirement should be losened > > "Election Process ((TBD)) " > should say that it's ~kubuntu-members who vote on council members > > "This is limited to the packages inside the kubuntu package set. " > link to package set list? > > "Existing ~kubuntu-members member, survive an interview by ~kubuntu-dev, get > accepted by >= 3 existing developers." > saying nothing about the 50 members who disapproved, should say a majority in > favour > > "Stable Updates ... KDE SC" > this section will need to be reviewed and > updated for KF5 land including in the first case KDE Applications > which are due to replace KDE SC before the end of this year and > includes kdelibs4 software as well as KF5 software. A job for later, but not > too much later. > > One question is how does all this apply to Qt? It's packaged by some > nice people working for Canonical and they generally work nicely with > Debian and upstream and we don't want to scare/piss them off, but they > can be lax at sending patches upstream. I think they should be asked > how much they feel able to comply to these policies. > > I can go ahead and make these changes if people agree. > > Jonathan Since there is no disagreement, (speak up if there is) please carry on Jonathan. We should get this published before we need to edit it to account for KF5, Plasma 5 & KDE Applications. Valorie -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Final thoughts/votes on Kubuntu Policy
Read it over again, looks great, some comments.. "Software that is not managed on KDE's infrastructure is considered unrelated to KDE. " "Official KDE software is generally every piece of software that has an official VCS on KDE's infrastructure and/or uses KDE's bug tracker. " KDE software is software that complies with the KDE manifesto, not necessarily on KDE's own infrastructure. "A bug is considered to have high impact if... AND upstream is aware and investigating " Sometimes upstream won't care as it's a released version or it doesn't affect their distro, I think this bug requirement should be losened "Election Process ((TBD)) " should say that it's ~kubuntu-members who vote on council members "This is limited to the packages inside the kubuntu package set. " link to package set list? "Existing ~kubuntu-members member, survive an interview by ~kubuntu-dev, get accepted by >= 3 existing developers." saying nothing about the 50 members who disapproved, should say a majority in favour "Stable Updates ... KDE SC" this section will need to be reviewed and updated for KF5 land including in the first case KDE Applications which are due to replace KDE SC before the end of this year and includes kdelibs4 software as well as KF5 software. A job for later, but not too much later. One question is how does all this apply to Qt? It's packaged by some nice people working for Canonical and they generally work nicely with Debian and upstream and we don't want to scare/piss them off, but they can be lax at sending patches upstream. I think they should be asked how much they feel able to comply to these policies. I can go ahead and make these changes if people agree. Jonathan -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Final thoughts/votes on Kubuntu Policy
>> Still needs doing : >> >> https://community.kde.org/Kubuntu/Policies#Election_Process_.28.28TBD.29.29 >> and there's still no Category C patch, but both minor issues. +1 from >> me too. > > > So we postpone the vote until this is done or do we vote now? > I was told that no category C patches was a non issue. And the email stuff can be done later on as well, so I think we can vote. 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: Final thoughts/votes on Kubuntu Policy
Hi all, On Thu, Jul 17, 2014 at 11:15 AM, Rohan Garg wrote: > On Thu, Jul 17, 2014 at 11:08 AM, Valorie Zimmerman > wrote: > > Hi folks, the steam seems to have gone out of the discussion of our > > policy document, and the trello card is languishing in Review. > > > > https://trello.com/c/dW1BTbUG/32-create-policy-list-and-redo-policies > > > > Please review One More Time and if you are a Council member, please > > register your vote here. > > > > Still needs doing : > https://community.kde.org/Kubuntu/Policies#Election_Process_.28.28TBD.29.29 > and there's still no Category C patch, but both minor issues. +1 from > me too. > So we postpone the vote until this is done or do we vote now? Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Final thoughts/votes on Kubuntu Policy
On Thu, Jul 17, 2014 at 11:08 AM, Valorie Zimmerman wrote: > Hi folks, the steam seems to have gone out of the discussion of our > policy document, and the trello card is languishing in Review. > > https://trello.com/c/dW1BTbUG/32-create-policy-list-and-redo-policies > > Please review One More Time and if you are a Council member, please > register your vote here. > Still needs doing : https://community.kde.org/Kubuntu/Policies#Election_Process_.28.28TBD.29.29 and there's still no Category C patch, but both minor issues. +1 from me too. 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
Final thoughts/votes on Kubuntu Policy
Hi folks, the steam seems to have gone out of the discussion of our policy document, and the trello card is languishing in Review. https://trello.com/c/dW1BTbUG/32-create-policy-list-and-redo-policies Please review One More Time and if you are a Council member, please register your vote here. I vote we adopt these policies as our official Policies. 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
