Re: Proposal unify back our release schedules
Hello, On Monday 22 April 2024 18:08:04 CEST Carl Schwan wrote: > On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote: > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker > > here I think. I'll try to add a couple of extra aspects to feed the > > thinking on this topic. > > Thanks you all for raising some important points. Taking into account the > feedback, I would like to slightly change my proposal. > > - Unify only the release schedule of Gear and Plasma with a frequency of > either 4 months or 6 months. This would follow the Fibonacci release > schedule. Sounds good to me, although we probably want others to chip in. > - Keep framework release once every month. But ensure that once every 4 (or > 6) months, it happens at the same time as Gear and Plasma. We can keep the > frequent features release of framework, which seems to be valuable for > people not compiling the whole stack from source. That doesn't sound too hard to achieve. Back when releases were done by David it was tagged at a fixed predictable day of the month. It seems this is not the case anymore (although it's hard to extrapolate from two data points: 6.0 and 6.1), so should make it easier to meeting Gear and Plasma releases if it's floating a bit. If there's a will to go back to a predictable day in the month, then we might want to instead have Gear and Plasma target this. It's merely details though, a question of putting new habits in place, nothing blocking IMHO even probably the right time to do so. > For the occasion where the Framework, Gear and Plasma, we should then ensure > that the framework release is done at the same time or slightly before the > gear and plasma release and ideally there is also a special beta release of > Framework done at the same time as the gear and Plasma beta, which can be > tested together with the other beta releases. I guess it depends on how long the beta phase is for Plasma and Gear at this point. If it's around a month you might want in fact this Frameworks n-1 to be the "beta" and having the n-1 to n month to be only about bugfixes and no features. It'd make for a regular "stabilization only" KDE Frameworks release. The alternative would be to add an extra beta release in between n-1 and n. So it's a question of the release team wanting to do it or not. > If Plasma decides to switch to a release every 6 months and Gear prefers to > keep a shorter release cycle, then I would suggest using 3 months for gear > so that we still have an unified released of framework, gear and plasma > once every 6 months. I'm less fan of this and if we have a very good reason > to switch to a 6 months release cycle for Plasma, this argument should also > apply to Gear. I have no strong opinion about the 4 vs 6 months. Having the frequency of Gear allowing of an alignment with Plasma from time to time definitely makes sense. > > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > > * We end up with 3 different products which are released at different > > > times but are connected together. Apps and Plasma both need Framework, > > > Plasma needs some packages from gear like kio-extra, Gear needs some > > > package from Plasma like Breeze. Coordinating all these inter-groups > > > dependencies is complex and was one the reason we had to do a > > > megarelease for Plasma 6. Also for the end user, one product is a lot > > > easier to understand. > > > > This is an engineering topic in this case. > > > > And, to me, this is an excellent reason not to reunify release schedules! > > Because what it tells me is that we're still having dependency issues > > which need to be solved. > > > > The example you give shows Plasma depending on Gear, this shouldn't > > happen, so I'd argue: let's fix that instead. > > > > Aligning the release schedules would only hide such structural issues. > > > > This was one of the main engineering motives to split things up: when it > > wasn't splitted this would stay hidden much longer everyone being comfy > > with it. > > > > Now it's creating pain: perfect, that makes the issue obvious, but it > > should be addressed not masked. > > > > This is in part what Volker highlighted pointing out this should be less > > of a problem with key components being moved to Plasma. Again, if there > > are more, let's just address them. > > > > So as pointed out by Sune and Volker: this is a feature (at least in the > > Frameworks case) not a bug. > > I'm been working a lot on the visual of applications across th
Re: Proposal unify back our release schedules
Hello, Wished to react to a point in there. :-) On Friday 19 April 2024 17:33:02 CEST Volker Krause wrote: > On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > > * We currently don't have a stable branch for Framework and it takes often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > The fast feature-releases of KF have major advantages though, comparing to > how things worked prior to 5. They allow apps to work against released (and > thus distro-packaged) frameworks while still making it practical to > contribute needed features to KF directly. > > The alternatives are: > * Depend on KF master (like Plasma does), significantly increasing the > threshold of entry for new contributors, especially for more self-contained > apps, where you'd now have to build 70+ repos rather than a few. > * Depend on the latest release but develop new features locally rather than > in KF. I'm not sure whether we have meanwhile finally cleaned up all the > forked kdelibs classes in PIM from the 3 and 4 era due to that. > * Depend on the latest release and wait for new features to become available > before making use of them in the app, effectively increasing the delay to > reach users to twice the release cycle. > > Ie. this makes contributing to KF less attractive from an app developer > perspective. > > > The main issues with out-of-sync KF and Plasma should have been solved with > some frameworks being moved to Plasma with KF6, if there is more of this > remaining we should look at the specific cases, for the vast majority of > frameworks I don't think we have a problem there. > > > * Helps with outside usage of our frameworks. These didn't get as much > > success as we were hoping when splitting. I think having a stable branch > > for Framework might help but this is only a guess. It would be interesting > > to know of cases where people considered using some Framework and to know > > why they decided against or for it and if this proposal would helps or > > not. > > I disagree with the often repeated statement that this wasn't successful. It > might not happened as widely and visibly as we might want, but KF is most > certainly used vastly more often than kdelibs ever was. And the release > schedule isn't the impediment here, it's things like dependencies and the > build system making it hard to vendor copies. > > > In effect this proposal would mean: > > > > * We do one major release every 4 months and then minor releases with a > > frequency based on the Fibonacci numbers as this releases cycle works very > > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We > > could > > unify that for one or the other one. Or let each component keep their > > current versioning scheme depending whether we want to merge Plama and > > Gear > > as product or keep it separate. I'm a bit undecided about this. > > From my app developer perspective that is fine, Fibonacci rather than > equidistant patch releases look like an improvement to me. However, assuming > the feature release interval basically remains the same. > > AFAIK Plasma is discussing a 6 month interval though, and I do understand > longer cycles are better for promo, but it means users have to wait longer > for features. It therefore also matters whether we are tying Plasma's > release to Gear or Gear's releases to Plasma here. Users waiting longer for features is not necessarily a bad thing though. One of the potential advantages is extra QA time, I assume people are happy to wait if there are less rough edges. Now if we assume the longer cycle don't lead to more QA, this becomes a balancing act... the burden on the users to discover and assimilate new features is real. So it's a bit of a trade-off between dropping a larger set of features on them increasing the chance of such features not being noticed, or pushing less features towards the user at higher frequency which is potentially higher cognitive load (they more likely to notice them all and be in a constant "learning new stuff" and "adapting to change" loop). > > * "KDE Framework" will still exists as an entity and its ABI and API > > > > compatibility requirement. Only change is the release frequency and the > > > > introduction of a stable branch in sync with the other components. > > That part I'm against for the above mentioned reasons, KF's release > frequency is a major feature of it. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
Hello, On Friday 19 April 2024 14:03:01 CEST Luigi Toscano wrote: > Nate Graham ha scritto: > > I expect a vast amount of discussion to result from this proposal, and I > > think that's great. It'll be good to talk about it. But I suspect in the > > end we'll likely not achieve 100% consensus, and in that event I'd like > > for us to put it to a formal KDE e.V. vote so that the topic doesn't > > become stale and die after everyone's exhausted from a long discussion. > > Is this an eV topic? I guess it was rhetorical in which case I'll humor you: no, it's not an e.V. topic. On a more serious tone: I'm actually concerned about such an early mention of an e.V. vote. This is the wrong tool and forum for this discussion. Also, I don't see the need to assume what early that it'll lead to "everyone's exhausted from a long discussion". This assumption and the mention of a vote is IMHO setting the stage for the conversation to get out of hand before any indication that it otherwise would... a bit like a self fulfilling prophecy unfortunately. I hope we won't collectively walk into it. I'd be more optimistic as despite initial push backs I see ways for a quick consensus to emerge on something different than the initial proposal. Anyway, if it would get out of hand nonetheless (I could be wrong and too optimistic after all), I'd propose to have a volunteer and *neutral* facilitator talking independently to the various parties and producing a final proposal with high chances of consensus reaching. A bit like we did at the time of the production of the KDE Manifesto. Note I wouldn't volunteer because obviously I got some more skin in the game this time and already engaged in the conversation. So if you're someone who didn't reply to this thread and have no strong opinion about the topic: keep monitoring that thread and maybe evaluate volunteering to facilitate if we start throwing mud at each other. ;-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
t only some of them (maybe)... and rub the rest under the carpet. To me the most likely outcome is old and tough issues creeping back up. Give it enough time and entropy will run its course getting us back to the kdelibs big ball of mud and high coupling of all apps Plasma and otherwise to this kdelibs-ng. We spent years trying to get out of this particular mess, I'd appreciate if we don't jump back into it. It'd also mean that the progress made on third parties using KDE Frameworks would completely go away. And in "fool me once, not twice" fashion we'd hardly get a chance of attracting them again. > In effect this proposal would mean: > > * We do one major release every 4 months and then minor releases with a > frequency based on the Fibonacci numbers as this releases cycle works very > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could > unify that for one or the other one. Or let each component keep their > current versioning scheme depending whether we want to merge Plama and Gear > as product or keep it separate. I'm a bit undecided about this. Indeed, the Fibonacci approach seems to work well for stabilizing minor releases of apps. Still, between minor releases the cadence should be constant. I think Gear and Plasma should be separate products. Which doesn't exclude moving some apps from Gear to Plasma. To me this both strengthen Plasma and Gear if we're clear where things stand. If an application is in Plasma it is expected to have a mandatory deep integration with Plasma sessions. If it's in Gear it is expected to be portable, maybe it does more under a Plasma session, but it shouldn't be crippled by running outside of a Plasma session. Also, on the Plasma and Gear products I think it should be clearer which KDE Frameworks version is targeted. > * "KDE Framework" will still exists as an entity and its ABI and API > compatibility requirement. Only change is the release frequency and the > introduction of a stable branch in sync with the other components. I hope by now I made the case clear that the release cadence of this one is an intended feature and not a bug. In my opinion, any pain KDE Frameworks being on its own cadence creates somewhere else should be treated as a symptom of a structural problem and addressed for what it is (decoupling required, some component in the wrong product being an issue in the dependency chain, missing QA or automated tests to catch regressions, etc.). Fun fact: "back then" we even toyed with the idea of an even faster cadence, it'd require quite some more automated QA and so was left on the side. I still think it would be a possibility for a subset of frameworks for go on a faster cadence, but let's not open that can of worms. > * Only have one release announcement on our website. We can call it > Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better name. > I would avoid reusing Software Collection first because the name is quite > technical and second because these was already used in the past. Sure, why not. This is not engineering I'm less opinionated about it. Apart from decoupling more between engineering effort and marketing announcements that is. Maybe reconsider the "Megarelease" term though... I've literally been laughed at for the use of that term outside of our community. Also, I think it was a fine term for a one off when moving on a major new version of Qt, but it'll get old quickly for the "business as usual". Again no strong opinion there, but I thought I'd mention what I've seen around me. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Friday, 29 March 2019 09:43:44 CET Volker Krause wrote: > On Friday, 29 March 2019 08:59:59 CET Kevin Ottens wrote: > > On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote: > > > Having mandatory reviews for a central and complex component like > > > akonadi > > > looks like a very good and obvious idea. > > > > Yep. > > Looking at the 18.12 -> 19.04 timeframe the majority of changes to Akonadi > went through pre-commit review, even more so if you discard commits doing > release work (version bumps etc) or similar maintenance not touching the > actual logic. > > And specifically the changes that caused us the most headaches due to > introducing a nasty regression went through review. > > Sure, nothing is perfect, but I don't think code review in Akonadi is the > most pressing issue here. Fair enough. I was thinking more PIM in general though than Akonadi in particular. > > > OTOH if there is only one developer who is really expert for akonadi, > > > this makes it kind of unfeasible. > > > > That's the chicken and egg problem we're in concerning KDEPIM. The > > developer story is frankly really harder than most software out there > > which makes it unlikely for people to pick it over something else for > > contributions. That's in part tied to your next point below and partly > > tied to > > documentation, on- boarding etc. The unwillingness to be slowed down is > > getting in the way of fixing that situation: to be a desirable project to > > contribute to you need to spend time advocating, documenting and taking > > newbies by the hand until they become regular contributors. > > > > Yes it's tough, and TBH I'm guilty of not doing this more on my own > > projects. But on such a strategic piece of software like KDEPIM there's > > some responsibility in carrying those duties for the well being of the > > project. > > How to address the issue of bus factor ~1 components in PIM is the real > question here, I completely agree. But this is getting way off topic from > Ben's original issue, and for the wide range of recipients. Yes, I realized only too late that I kind of hijacked the thread somehow. I apologies about that. > Also, I don't think overly generic statements on that help us much, so maybe > let's discuss concrete steps for this at the sprint next week? Definitely. It's in part because I know the sprint is coming that I started to wave that particular flag. :-) I wish Laurent was there though, it'll make that particular discussion harder to conclude without him... Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 20:35:11 CET Dr.-Ing. Christoph Cullmann wrote: > I and others tried to get more reviews done in the past, but actually I > merged more than once stuff that I reviewed but it did break the CI. That I hope we'll get fixed at some point. It's a big big advantage when you can get a CI run on reviews. I find it best when you get both humans and scripts looking at the code in a review. It helps a lot in having better quality reviews from the humans since they are relieved from the boring redundant nitpicking (catching warnings, basic code style, etc.). Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote: > On 2019 M03 28, Thu 16:04:01 CET Boudhayan Gupta wrote: > > As a user, I simply do not want unreviewed crap running on my computer. > > Yes, crap, because no software engineer writes bug-free code all the time, > > and if you're so overconfident that you don't need reviews on even your > > one-liners, you're probably too overconfident to be writing good code > > anyway, so I'm going to operate on the presumption that if the code hasn't > > had more than one pair of eyeballs ever looking at it, it's crap. > > If you put it that strong, it's wrong. > Code which has not been reviewed is not generally "crap". Code which has > been reviewed is not generally "high quality". > Unreviewed code can be good, and often is good, and reviews, maybe > especially if they are mandatory, *can* be crappy: just pointing out > formatting issues, Oking the patch without understanding the big picture > (and feeling somewhat pressured to accept a patch because the review is > mandatory and otherwise you are blocking the other developer, etc.) Hell yeah, it's not a silver bullet. Actually it can be only one safety net among others. None of them are perfect, none of them will catch it all or be of good quality all the time, it's just about mitigating risks as much as possible. > > As a developer, I know that even one-liners, and especially one-liners, > > the sort where you think "meh, this is a tiny little thing, I don't have > > to be careful" are the ones that have the most dangerous typos and > > unintended bugs. > > That's also a wrong argument. one-liners are not especially prone to causing > most bugs. They may introduce bugs, but I think, since they are small, this > is less likely than for bigger patches. I don't think that's true. It's a question of complexity in the system really. In a trivial system indeed they are less likely to introduce bugs than for bigger patches... but as the software grows and complexity rises (especially with the multiplication of mutable states) one liners tend to be as error- prone as bigger patches. > ... > > > In a project like PIM, if the code hasn't been through review, which > > independent party do I trust to verify that you're not, for example, > > leaking my Google password to some world-readable tempfile? > > Having mandatory reviews for a central and complex component like akonadi > looks like a very good and obvious idea. Yep. > OTOH if there is only one developer who is really expert for akonadi, this > makes it kind of unfeasible. That's the chicken and egg problem we're in concerning KDEPIM. The developer story is frankly really harder than most software out there which makes it unlikely for people to pick it over something else for contributions. That's in part tied to your next point below and partly tied to documentation, on- boarding etc. The unwillingness to be slowed down is getting in the way of fixing that situation: to be a desirable project to contribute to you need to spend time advocating, documenting and taking newbies by the hand until they become regular contributors. Yes it's tough, and TBH I'm guilty of not doing this more on my own projects. But on such a strategic piece of software like KDEPIM there's some responsibility in carrying those duties for the well being of the project. > IMO this specific case is also a technical issue. Akonadi makes things > complicated (and it's already 13 years old, so it should be mature in the > meantime). Yes, it's byzantine really. And the user experience is still not great (to be polite), had to setup some new hardware recently and I was honestly almost to the point of throwing it all through the window. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 16:11:12 CET Friedrich W. H. Kossebau wrote: > Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel: > > For example I works all days on kde (pim or other) when I wake up, or at > > noon after my lunch or the evening, I will not wait several days for a > > review because nobody has time to do it. > > > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't > > want to wait several days/weeks until someone wants to review my patchs) > > Something might be lost in translation here, do you think, because you work > daily on code of KDE projects, and other people (so potential reviewers) do > not, this is an argument to do instant pushes of unreviewed commits? > > While I understand one can get impatient if not getting instant review of > changes one would like to depend on with further changes (I know this well > :) ), That particular point is in part a tooling problem though. Phab doesn't make this situation easy to handle. I have to do very naughty things to git and arc to deal with those. I'm guilty of often piling a dozen patches and rewriting extensively my history locally before the lots hits the first round of reviews. :-) > still this seems a flawed argument at least for part-time-contributors based > KDE projects, where the people one co-operates with only have time now and > then, like once per week. It could be seen unfair & ignorant to them if one > simply ignores their opinion, because one has more time reserved/ available. This is one of the big flaws of self-proclaimed meritocratic communities. You can out-commit someone and end up being the big decision maker hard to convince. Doesn't happen by malice in most cases I think, but it's a clear slippery slope. > Not sure where this is from, but often I have seen an unwritten policy > applied where people for a patch uploaded for review after one week of no > response add a ping and then wait another week, before finally pushing the > change. To me this seems a fair and reasonable policy, only ignores people > who are on vacation for some more weeks or otherwise inactive, but I have > not seen that ever been a real issue. Agreed. It makes sense. > Given the actual purpose of this thread, I would be more curious how you > have CI integrated in your workflow? And where things could be improved, to > prevent the current state of unhappiness for people who care about CI some > more? Given you said you work daily on KDE projects, it seems that the > brokeness of those projects on the KDE CI has slipped your attention. So > how does this happen, and how could this be prevented, other than people > having to hunt you down on irc and tell you :) Definitely interested in this as well. It's not the first time we have Ben having to escalate to some form of threat regarding the state of the CI in PIM components. Although it's clear from the kde-pim list that the CI is making a lot of noise there. Either we collectively became too good at ignoring those emails, or it's too verbose (after all it's one email per component per build type, it piles up quickly). Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 14:33:59 CET laurent Montel wrote: > I am against to force mandatory review, as it will create a lot of lose of > time, As I said, unpopular. > and we will not be sure that review is correct (see comment from > Volker about "transaction lock regression") This argument is absurd: "Hey, this vest isn't 100% bullet-proof, thus I'll walk in the middle of a war naked". > It's necessary to having a big team for doing it. I agree having a team of 1 for each KDE PIM component is a problem (and often the same person). > Ok a repo was broken, but it was just that fix was created in master not > 19.04, I didn't see nobody on IRC told us "this package is always broken", > when I saw it this morning I just cherry pick (2 seconds for fixing it). > > For example I works all days on kde (pim or other) when I wake up, or at > noon after my lunch or the evening, I will not wait several days for a > review because nobody has time to do it. > (we can see a review from zanshin for example https://phabricator.kde.org/ > D16210 we can see that David waited 2 months until having an answer...). Unfair, if you read the comments you'll see that this particular patch didn't appear in my dashboard for some odd reason (I suspect it comes from how arc associates a patch to a repository or not, but I digress...). > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't > want to wait several days/weeks until someone wants to review my patchs) > > I will not lose my time to review some code that I don't understand... I > never reviewed Akonadi patch as I don't understand this code, and I will > take time on it just for the pleasure as I prefer fixing bug or adding new > features in components that I maintain. > > When we have a big team as Qt team it can help but in pim component where we > don't have any redundant guy, we will lose a lot of time. Ah, the mythical big team... Because it's well known that on Qt the reviewers aren't stretch thin and that patches never end up weeks in limbo... Also you know that if you don't change your way of working you'll stay alone on your components? I know, chicken and egg... but all those commits and stuff randomly changing all the time doesn't help people to get in even if they'd want to. But you know that very well, we just discussed it half a dozen times in the past... > So for each increase version for each package I will wait a review. For sure > not. > > Each time that I will improve code as coding style I will wait that someone > wants to review... > > > I know that it's easy to write "make reviews mandatory" there is not an > impact about your work as we know that you are not really active on kde at > the moment... Right, let's bring something irrelevant to the discussion. You know it's mainly due to health issues the past few months right? (yes, March has been a real joy again... it keeps on giving) Besides, I apply mandatory reviews to myself on zanshin. > For sure I broke kcontact 2 days ago, but as a friend told me when I started > to work on kde "We can't create a bug when we don't code..." And this is true, writing code will create bugs, that's why responsible people like safety nets even to the price of throughput. Now can we use a more adult tone again? Maybe re-read Dan's email again who has a more balanced view despite being in a similar situation? Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 11:27:44 CET Daniel Vrátil wrote: > I'm completely fine with mandatory code review for everything and I'd be > happy to have this in PIM. I think the biggest problem in PIM to overcome > will be finding the reviewers - I dare say I'm currently the only one who > has at least a little idea about what's going on in Akonadi, so getting for > instance Laurent to review my Akonadi patches might be hard - same for me > reviewing Laurent's KMail patches. This will require non-trivial amount of > effort for all members of the community to gain deeper understanding of the > other components within the project and a willingness to step up and do a > code review even if they don't feel 100% comfortable with the code base. > But I believe that in the long run the benefits clearly out-weight the > cost. This! :-) > Btw we practice this policy at work and I do truly appreciate it, not only > as a huge learning experience but so many times just having a second pair > of eyes to glance over my code has revealed issues that sometimes almost > make me question my career choice as a programmer :-) I think this is > especially important for projects like PIM, where most of us contribute at > work in between waiting for CI and replying to 15 Slack threads or in the > evening after a long day And this too of course. I fully support this message. ;-) Cheers. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 10:35:37 CET Luca Beltrame wrote: > In data giovedì 28 marzo 2019 10:32:39 CET, Kevin Ottens ha scritto: > > OK, to be fair not 100% today's situation because of the above. It was > > based on best judgment maybe we're missing such a set of guidelines. I > > admit I'm slightly doubtful though. > > I can't claim it may work 100%, but I've seen other communities (many, many > years ago) where a "semi anarchy" replaced by "iron-gripped rules" from one > day to another actually killed them. I wouldn't call that iron grip from one day to the other though. It's not like we've not been working toward mandatory review for the past ten years or so. Most KDE projects de facto apply mandatory reviews AFAICT. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 10:08:54 CET Luca Beltrame wrote: > In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto: > > I'd argue we're loosing more with the current state of PIM than we'd loose > > with mandatory reviews. > > Perhaps, instead of an all-or-nothing approach, why not a minimal set of > "requirements" that would require a review? Yes, it requires more discipline > from those involved, but at least it will help people getting "ingrained" > with the concept without being a wall. I'm almost tempted to reply "been there, done that". It's kind of the situation we have today. > Examples: > > - No review: typo fixes, compile errors, version bumps (internal) > - Review: build system adjustments (perhaps CC some people knowledgeable in > this case), non-trivial changes like patches > - "Deprecation" removals (as in the casus belli here) - review if touching > more than a handful of files / multiple repos > > (list made by someone who has a passing knowledge of C++, so feel free to > rip me to shreds) OK, to be fair not 100% today's situation because of the above. It was based on best judgment maybe we're missing such a set of guidelines. I admit I'm slightly doubtful though. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 09:41:29 CET Luca Beltrame wrote: > In data giovedì 28 marzo 2019 09:29:22 CET, Kevin Ottens ha scritto: > > at your screen or pair with you" in the past. Clearly this compromise gets > > somewhat exploited and that's especially bad in the case of a fragile and > > central component like KDE PIM. > > I'm not sure I agree. I can't speak for seasoned developers, but I've found > myself in a situation (more than once) where the fix is trivial (compile > error, missing ";", etc) and being forced to go through review would (IMO) > unnecessarily raise friction. I don't fully disagree with this (although I'd have stories on nefarious typos even for what was supposed to be a "trivial fix"). But it becomes a question of trade-off, IOW "how hurtful to the project mandatory reviews?" vs "how hurtful to the project a central component being very regularly broken?". I'd argue we're loosing more with the current state of PIM than we'd loose with mandatory reviews. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Hello, On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > Please note that the commits in this instance were pushed without > review, so restrictions on merge requests wouldn't make a difference > in this case unfortunately. Maybe it's about time to make reviews mandatory... I know it's unpopular in KDE, and I advocated for "don't force a tool if you can get someone to look at your screen or pair with you" in the past. Clearly this compromise gets somewhat exploited and that's especially bad in the case of a fragile and central component like KDE PIM. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes
Hello, On Friday, 12 May 2017 12:57:58 CEST Ben Cooksley wrote: > I've now added the following to the Extragear product as requested: > > - Skrooge > - Simon > - KMyMoney & Alkimia > - Krusader > > For Zanshin we have a slight hitch: it's in Playground. It's been > around for a while now so can it please transit through KDE Review > into Extragear? (More of a policy thing than anything else - we > shouldn't be releasing stuff directly from Playground) Requested just now on kde-core-devel a move to kdereview aiming at extragear/ pim. Let's see how it goes. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
Hello, On Monday, 11 July 2016 20:51:43 CEST Sune Vuorela wrote: > On 2016-07-07, Kevin Ottens wrote: > > There's two sides to that problem in fact, use from applications and > > the=20 > > service provided by our workspace. > > One issue that I'm a bit puzzled about is the following scenario: > > A user uses KMail for emails. > But switches between various desktop environments. > > Would he need to configure KMail in all of them? Depends how much effort we want to put into something like that really. Worst case scenario: he'd have to retype passwords in the various desktop environments. Best case scenario we magically find out that it'd find more passwords with a different backend and so nothing to retype. Personally, I'd put no effort in dealing with that. I have two reasons for that: 1) I don't think many users do that or should do that. Nowadays, most perceive the workspace as part of the OS stack. 2) On Linux, I'd expect those things to converge at one point (could be years of course[*]) and you'd have only one of the potential storages picked by the distro at installation, all the apps would use that one, whatever workspace you're running (talking about something I witnessed, I think it will be a bit like what happened with hardware detection: everyone has a wrongly designed solution, then hal emerged, then udisks and friends, everyone use those now). Regards. [*} But whatever solution we pick forward it'll take months to get there and be used by all our applications anyway. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
Hello, On Monday, 11 July 2016 21:58:34 CEST Thomas Pfeiffer wrote: > On 07.07.2016 19:50, Kevin Ottens wrote: > > There's two sides to that problem in fact, use from applications and the > > service provided by our workspace. > > > > I think that for applications the answer is neither KSecretService nor > > KWallet, etc. For the goal of making it easier for our applications to be > > shipped on more platforms, what we want in fact is to port them away from > > anything platform specific to something like QtKeyChain: > > https://inqlude.org/libraries/qtkeychain.html > > > > This way, the actual storage becomes a workspace decision. That could keep > > being KWallet if improved, or KSecretService, or a simple D-Bus service > > wrapping libsecret... For sure it would at least simplify things on the > > KWallet/KSecretService side, they wouldn't need to be frameworks anymore > > (QtKeyChain or equivalent would play that role) just to expose a D-Bus API > > (likely the Secret Service one in the end). > > Oh, indeed, that would absolutely make sense! Deploying and using > applications which use KWallet outside of Plasma must be a pain right now. Never tried, but I'd suspect it is indeed. > So how do we make that happen? Deprecate the KWallet framework and recommend > to use QtKeyChain instead, and then in parallel decide which bakcend to use > for QtKeyChain in Plasma? Probably something like that yes. Note that I'm not sure how active the QtKeyChain project is right now, so that might be something to evaluate I guess. > >> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secre > >> ts-> api-0.1.html> > > 0.1 being outdated, you probably want to link that one: > > https://standards.freedesktop.org/secret-service/ > > Ah yes, indeed. > > > Hope that somewhat made sense and helps. > > It made sense to me at least :) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
Hello, On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote: > I'm addressing both the Plasma team and kde-devel because this issue affects > Plasma as well as many applications, and Valentin as the current maintainer > of KWallet as well as KSecretService, a potential replacement for it. > > KWallet plays a central role in Plasma and many KDE applications as the > central password storage. However, it being very old and not having been > actively developed for a long time, it has lots of problems, including: > > - It has weak security, as it does not restrict applications accessing it by > default, and even when it does, it does so simply based on application name > which allows any malicious process to impersonate an allowed one > - The initial setup has huge usability problems, as it forces users to make > a choice on a very advanced technical level (encryption methods, no less!), > and the option it suggests (GPG) is a nightmare to set up for ordinary > users - It does support unlocking via PAM, but does not tell users what > they need to do to make that work, which results in most users having to > enter the KWallet password at each system start, which many find very > annoying (we get lots of negative feedback for that) > - It works only with KDE Frameworks-based applications > - One cannot easily write a QML GUI for it, making it unsuitable for mobile > > Valentin has been working on KSecretService for quite a while, which is > based on the freedesktop Secrets API [1] that is also supported in GNOME > Keyring, and would solve many (and ideally all) of the above problems. > However, Valentin told me he does not have the time to work on > KSecretService any more. > > This means we have to find a solution to these problems. The options I see > currently are > - Improve KWallet (unlikely to fix all the problems without massive changes > in it, though) > - Find someone to finish and maintain KSecretService > - Build a wrapper around one of the other existing keyring technologies > - Each application (and each Plasma component that stores passwords) > implements its own encrypted password storage > - We make encrypted password storage optional and non-default (easiest > solution, but not exactly in line with KDE's vision) > > So, what do we do? There's two sides to that problem in fact, use from applications and the service provided by our workspace. I think that for applications the answer is neither KSecretService nor KWallet, etc. For the goal of making it easier for our applications to be shipped on more platforms, what we want in fact is to port them away from anything platform specific to something like QtKeyChain: https://inqlude.org/libraries/qtkeychain.html This way, the actual storage becomes a workspace decision. That could keep being KWallet if improved, or KSecretService, or a simple D-Bus service wrapping libsecret... For sure it would at least simplify things on the KWallet/KSecretService side, they wouldn't need to be frameworks anymore (QtKeyChain or equivalent would play that role) just to expose a D-Bus API (likely the Secret Service one in the end). > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> > api-0.1.html 0.1 being outdated, you probably want to link that one: https://standards.freedesktop.org/secret-service/ Hope that somewhat made sense and helps. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Phabricator: Make it happen already!
Hello all, So we've been evaluating different options to modernize our tooling, and for some reason it looks like we're still waiting on some external pressure to pick one. I'll then try to be this external pressure with this war cry: Phaaab! Make it happen already! It is basically what I reported during the Phabricator BoF at Akademy this year. For some obscure (to me) reason, I ended up being one of those who tried all the contenders, and to me, Phabricator is the best fit for our community[*]. Also recently I'm seeing a surge of use in the test instance, so I'd say it is time to get it out of limbo and make it official. Sysadmins, could we move forward with it please and start migrating for real? Thanks for your attention. Regards. [*] Obviously I'm leaving plenty of details here, I'm not debating the why, I'm just trying to get the ball rolling. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [Kde-pim] The Future or KDE PIM Releases
Hello, On Tuesday 14 April 2015 09:44:19 Sandro Knauß wrote: > > What's meant by "KDE Accounts"? > > well we also had a look into the code. It is a resource that will adds all > local users from kde to your kaddressbook. Oooh, that one... it's very important to me, I rely a lot on it. Can we release it? I'm even willing to be signed up as maintainer. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: QAction and KGlobalAccel::globalShortcutChanged signal in KF5
Hello,
On Wednesday 07 August 2013 17:11:09 Reza Shah wrote:
> Below are the new codes(simplified), but i have doubt how to use
> globalShortcutChanged, and effectShortcutChanged properly.
> ---
> QList cubeShortcut;
> QList cylinderShortcut;
>
> QAction* cubeAction;
> QAction* cylinderAction;
>
> //Set shortcut
> KGlobalAccel::self()->setShortcut(cubeAction, QList() <<
> Qt::CTRL + Qt::Key_F11);
> KGlobalAccel::self()->setShortcut(cylinderAction, QList());
>
> //Get shortcut in new way.
> cubeShortcut = KGlobalAccel::self()->shortcut(cubeAction);
> cylinderShortcut = KGlobalAccel::self()->shortcut(cylinderAction);
>
> //Is this correct?, also if i have many QAction only one connect needed?
> connect(KGlobalAccel::self(), SIGNAL(globalShortcutChanged(QAction *,
> QKeySequence)), this, SLOT(effectShortcutChanged(QAction *, QKeySequence)));
>
> //Is this correct?
> void effectShortcutChanged(QAction * action, const QKeySequence& seq)
> {
> if (action == cubeAction) {
> cubeShortcut = QList() << seq;
> } else if (action == cylinderAction) {
> cubeShortcut = QList() << seq;
> }
> }
> --
Looks correct to me indeed.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: kde-workspace in KF5 cmake error
On Wednesday 07 August 2013 11:17:22 Reza Shah wrote: > I just updated kde-workspace from framework-scratch. > I got errors when building it as in http://paste.kde.org/pc4273542/, > something about KStyle. > > How to fix these errors? It was my fault, I just pushed a fix in kdelibs now, please update. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Call for Projects: University Collaboration in Toulouse
Hello, On Thursday 16 August 2012 20:23:24 Torsten Rahn wrote: > On Donnerstag, 16. August 2012 12:12:12 Kevin Ottens wrote: > On behalf of the Marble Team I'd like to express our highest interest in > participation! OK, you're on the list now! ;-) > The two mentors we'd provide are Dennis and me. OK, FYI I allocated to you the "customer" role and Dennis the technical mentor role, let me know if you prefer the other way around. > We have a very interesting topic going on that has a lot to offer for > students with different aspects of interest and varying capabilities: > > "OpenStreetMap Vector Rendering" > [...] I simplified that a bit in the proposal in three points: * Complete support for OSM vector tiles * Optimize the vector tile pipeline * Setup server for vector tiles This way I could pick a few topics on your list below to have some diversity in the proposal: > Of course other topics for Marble work are welcome as well. Possible > alternatives could cover Space + Astronomy, Historic Maps, Routing, > GeoCaching, Natural Earth vector tile rendering (topographic map), Time & > Animation KML enhancements, etc. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Call for Projects: University Collaboration in Toulouse
Hello, As a reminder: I need to close the list of projects real soon now. If you did send me your proposal yet please do so NOW! I'm especially looking at the ones who told me in private they wanted to participate but sent nothing. You know who you are. ;-) Of course if you didn't contact me yet, you still can send me a proposal, I'll gladly add it to the list. Regards. On Tuesday 07 August 2012 19:08:18 Kevin Ottens wrote: > Hello all, > > I have very good news, if everything goes well, I will have the opportunity > to setup student projects at the University in collaboration with KDE > again! We had a one year hiatus, and I have to admit I miss those projects > dearly, so it'd be nice to resume the effort... I'd quite some work ahead > as its a reboot and not much of my previous efforts is left. > > Anyway, if you are part of a KDE team, and you'd like to get some help from > a small team of students (not more than four or five) for a few months, > here is your chance! The requirements on your side if you volunteer are the > following: * Two mentors from your team (one will kind of play the customer > to the students, the other one more on the technical mentoring side); > * A list of features the students would have to work on (not more than a > dozen, not less than five). > > If you are interested, please contact me in private with the info mentionned > above (mentors + feature list with some details). Don't wait! I'll finalize > the list of chosen projects end of next week (and then push it to the > university), and I might have a few questions for you before picking your > proposal or not. > > Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Call for Projects: University Collaboration in Toulouse
Hello all, I have very good news, if everything goes well, I will have the opportunity to setup student projects at the University in collaboration with KDE again! We had a one year hiatus, and I have to admit I miss those projects dearly, so it'd be nice to resume the effort... I'd quite some work ahead as its a reboot and not much of my previous efforts is left. Anyway, if you are part of a KDE team, and you'd like to get some help from a small team of students (not more than four or five) for a few months, here is your chance! The requirements on your side if you volunteer are the following: * Two mentors from your team (one will kind of play the customer to the students, the other one more on the technical mentoring side); * A list of features the students would have to work on (not more than a dozen, not less than five). If you are interested, please contact me in private with the info mentionned above (mentors + feature list with some details). Don't wait! I'll finalize the list of chosen projects end of next week (and then push it to the university), and I might have a few questions for you before picking your proposal or not. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Rules to be approved as part of KDE Frameworks
Hello lists, As, Sebas pointed out we've been meeting here to work on plans to improve our frameworks offering leading to the decision of leaving the current "kdelibs model" behind and prepare for a more modular suite named KDE Frameworks. If you didn't read his email yet, please do so before going back to this email. Don't be afraid, this email is likely to be shorter than the previous one. ;-) It might also be easier to understand the content of this email if you first read my previous email about the KDE Frameworks, although that's probably not mandatory. Here, we'll be dealing with what will be part of the KDE Frameworks, the answer is two fold really and depends if we're talking about a library or smaller code contributions. The content is mostly common sense, it is about trying to make explicit the good practices already in place in our community. This email is a draft of a future wiki page to complete our policies (or to be integrated in the existing policy pages). = Library Quality Criteria = Any library should meet the quality criteria to get KDE Frameworks stamps (as described in my previous email). The criteria in question are the following: * the code should follow our license policy; * the code should follow a consistent coding standard (it is encouraged to follow the current kdelibs standard throughout our frameworks but is not mandatory); * the framework should have a scope (no dumping ground); * the code should meet all the dependency criteria of its intended Tier and Framework Type; * the library should maintain binary compatibility until the next major release of KDE Frameworks; * the code should be unit tested with a "sufficient" coverage (the exact number still needs to be determined); * the developers of the library should comply to the "code contribution quality criteria" described below. = Code Contribution Quality Criteria = Since we can expect all the libraries, old and new, to get code contributions, the following rules will be in effect for the "stamped" frameworks: * the "two apps rule" still applies and should be considered like a minimum; * the added code should comply to the dependency policy for the library Tier and Framework Type; * the added code should fit in the library scope; * the contributor has to commit to maintaining the contributed code or find someone to take it over (social contract); * all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one); * automated tests should be provided in the same commit as a fix; * commits meant to hit the master branch (bugfixes or merges) should contain a "Reviewed by" or "REVIEW:" in their commit log. = Conclusion = Those rules might seem like a strong departure from what we're used to. On the other hand, if you look at them closely, they are merely making explicit changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port. We're trying here to make them systematic to get even better frameworks than before. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Intended organization of KDE Frameworks
Hello lists, As, Sebas pointed out we've been meeting here to work on plans to improve our frameworks offering leading to the decision of leaving the current "kdelibs model" behind and prepare for a more modular suite named KDE Frameworks. If you didn't read his email yet, please do so before going back to this email. Currently, our set of base frameworks is mainly kdesupport, kdelibs and kdepimlibs. Apart from kdesupport which is now splitted, kdelibs and kdepimlibs are collections of libraries. That leads to hiding internal dependencies in those modules, especially in kdelibs, and some of the libraries are more dumping grounds than proper frameworks with a purpose. The new model we're moving to will help us have clearer dependencies and push us toward a more modularized offer. Among other benefits, it will make it easier for third party developers to use our frameworks, and it should also make contributions easier. = Overall organization = In the new KDE Frameworks organization, we're aiming at sorting our libraries along two axes. The first axis deals with the runtime dependencies (organized in Framework Types) while the second axis deals with the link time dependencies (organized in Tiers). The position of a library along of those two axis is mainly a stamp or a label we put on a library, it will come with responsibilities though, and will help us find how to improve a library. In the following lines, we're going to describe the rules summarized in this graph: http://files.kde.org/ervin/platform11/kde-frameworks-matrix.pdf == Framework Types == We will have now three Framework Types: Solutions, Qt Addons (OS Integration) and Qt Addons (Functional). They mainly differ in their runtime dependencies. * Functional Qt Addons shall not have any runtime dependency (think for instance of a split libkconfig, it would drag no runtime at all); * OS Integration Qt Addons can have optional runtime dependencies, if the OS supports the feature they shall use OS facilities, otherwise a runtime dependency might be used to implement the feature (think for instance of a split libkdatetime, it would use ktimezoned on Linux, but on Windows it would directly use Windows APIs); * Solutions implement a full technology or stack, including a library and mandatory runtime dependencies: plugins, servers, etc. (think for instance of Akonadi, KIO or Soprano). == Tiers == The goal of Tiers is to clarify the link time dependencies of our libraries. * Tier 1 frameworks depend only on Qt itself and no other Qt based framework; * Tier 2 frameworks depend only on Qt and Tier 1 frameworks; * Tier 3 frameworks can depend on any Tier 1, 2 or 3 frameworks. == Look & Feel + Consistency == Obviously the naming of that category is difficult. It will contain all the frameworks which won't fit in the nice categories described above. The purpose of those frameworks will be: * to ensure the behavior and look consistency between KDE Applications; * to integrate KDE Applications with the Workspaces. = Examples and Aims = Maybe after reading through all that, it still seems too abstract, that's understandable, so in this part of the email we'll cover a partial example of what our new organization will look like. Keep in mind that it is non exhaustive, and describes the intended situation rather than the current code structure. Work will be required to get there. Throughout this example we will refer to the following graph: http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf We will quickly present a few examples for some of the ten categories: * Tier 1, Functional Qt Addon: kcore libkcore will be a new library adding a few features on top of libQtCore. In particular, it will contain the job classes, handling of command line arguments, text handling classes, file locking, and not much more. Because of that, it will be fairly self contained and will depend only on libQtCore granting it the Tier 1 and Functional labels. * Tier 2, Functional Qt Addon: kconfig libkconfig will be a new library containing our good old KConfig* classes. It uses QtCore, but also the file locking mechanisms provided by libkcore. It brings no runtime payload. Because of that, it will be granted the Tier 2 and Functional labels. * Tier 2, OS Integration: Window Management The window management features of kdeui will be split out into their own library. It will depend on libkgui and Qt, granting it the Tier 2 label. As it provides integration with the OS which in particular might require a runtime payload (although not in that particular case), it is granted the OS Integration label. * Tier 3, Solution: KIO Widgets The current libkio will be split in several parts, one containing the core features, the one we're considering here will contain features like KRun and the other widgets you might want to use with KIO Jobs. It will depend on another Tier 3 framework (Services Traders) granting
Re: Thoughts from a former KDE, currently Mozilla developer
On Wednesday 8 December 2010 15:09:38 David Jarvie wrote: > On Wed, December 8, 2010 8:38 am, Kevin Ottens wrote: > > On Wednesday 8 December 2010 02:51:46 Aaron J. Seigo wrote: > >> On Tuesday, December 7, 2010, Benoit Jacob wrote: > >> > * > >> > 3. QA, Unit-testing, continuous testing (KDE: very little, Mozilla: a > >> > lot) > >> > > >> > Let's face it, KDE has always been deficient in the QA department. In > >> > > >> > order to ensure good QA, it needs: > >> > * a lot more unit tests than it currently has > >> > >> agreed. care to donate some resources? :) > >> > >> > * unit tests must be automatically run, frequently. > >> > >> agreed; people are working on automated unit test set ups for kde. we > >> have > >> > >> more variance than mozilla does however, which means this: > >> > In mozilla, > >> > > >> > everything is built and the unit tests run on 10 configs everytime you > >> > push to the repository, see http://tbpl.mozilla.org/ > >> > >> would be great. given our resources and the variety of our targets, > >> highly unlikely for now. in future, perhaps. > >> > >> > * regressions must never be tolerated. if a commit causes a > >> > > >> > regression, back it out. > >> > >> ah, blanket statements. as a rule of thumb: good idea. rigidly followed: > >> stupid, as it's an awesome way to discourage development contribution. > > > > Note that it piggy back to unit tests IMO. If a commit causes a > > regression caught by a unit test it should be reverted indeed. If that > > happens it's mainly a problem during the reviewing phase and so on. > > Going beyond than that > > could indeed discourage development contribution (unit tests are easy > > enough to run before you send the patch to be a good compromise). > > For smaller commits, it seems reasonable to demand that they don't cause > regressions. For larger commits, it won't always be possible to test > sufficiently for regressions before committing - there may be too many > affected apps if a change is made in the libraries, and a single developer > can't be expected to have the time or knowledge to test multiple apps. > [...] I didn't claim that. My point is that at least the unit tests shouldn't show any regressions, I never talked about getting to each application and test it manually. Really, running the automated tests before submitting is a low enough price to pay, but would improve the quality quite a bit. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Thoughts from a former KDE, currently Mozilla developer
On Wednesday 8 December 2010 02:51:46 Aaron J. Seigo wrote: > On Tuesday, December 7, 2010, Benoit Jacob wrote: > > * > > 3. QA, Unit-testing, continuous testing (KDE: very little, Mozilla: a > > lot) > > > > Let's face it, KDE has always been deficient in the QA department. In > > > > order to ensure good QA, it needs: > > * a lot more unit tests than it currently has > > agreed. care to donate some resources? :) > > > * unit tests must be automatically run, frequently. > > agreed; people are working on automated unit test set ups for kde. we have > > more variance than mozilla does however, which means this: > > In mozilla, > > > > everything is built and the unit tests run on 10 configs everytime you > > push to the repository, see http://tbpl.mozilla.org/ > > would be great. given our resources and the variety of our targets, highly > unlikely for now. in future, perhaps. > > > * regressions must never be tolerated. if a commit causes a > > > > regression, back it out. > > ah, blanket statements. as a rule of thumb: good idea. rigidly followed: > stupid, as it's an awesome way to discourage development contribution. Note that it piggy back to unit tests IMO. If a commit causes a regression caught by a unit test it should be reverted indeed. If that happens it's mainly a problem during the reviewing phase and so on. Going beyond than that could indeed discourage development contribution (unit tests are easy enough to run before you send the patch to be a good compromise). My 0.02€. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
