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
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. > > 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. 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? Regards, Volker signature.asc Description: This is a digitally signed message part.
Updating the Framework apidocs part 1: fixing the presentation
Hello everyone! It's that docs guy again! Hope you don't mind this brief interruption of coding activities to give our apidocs some TLC. I recently went over the KDE Frameworks apidocs, one framework and class at a time, to get an overview of what we're facing. And, to be honest, there's quite a lot to be done but we can probably already start with the lowest hanging fruit: the presentation/style. There are three things that seem to be off with the current design that we're using (I'll be filing bug reports as well): - All the class names at the top of their respective pages only show the Framework name. For example, instead of showing "KAboutData", it displays "KCoreAddons" only. [1] - The table-based layout for parameters/returns and their descriptions are too narrow and run into each other. [2] - The headers of Deprecated and Todo pages (of frameworks that have them) are unreadable. [3] Probably small stuff but enough to get started on making the apidocs look professional. On that note, is there someone I need to get in touch with about the design of the apidocs? ECM, for example, looks totally out of place. I'd love to hear your thoughts and suggestions on the current state of our Frameworks apidocs and how we can make them even better than before. I'm also on IRC (Jucato) and Matrix (also Jucato), though do note I live on UTC+8. 1. https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html 2. https://api.kde.org/frameworks/attica/html/classAttica_1_1AccountBalance.html#a71c29c3638accbd6216be60b08509b76 3. https://api.kde.org/frameworks/karchive/html/deprecated.html Regards, -- Juan Carlos Torres Jucato
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: Updating the Framework apidocs part 1: fixing the presentation
On Fri, Mar 29, 2019 at 9:47 PM Juan Carlos Torres wrote: > > Hello everyone! > > It's that docs guy again! Hope you don't mind this brief interruption of > coding activities to give our apidocs some TLC. > > I recently went over the KDE Frameworks apidocs, one framework and class at a > time, to get an overview of what we're facing. And, to be honest, there's > quite a lot to be done but we can probably already start with the lowest > hanging fruit: the presentation/style. There are three things that seem to be > off with the current design that we're using (I'll be filing bug reports as > well): > > - All the class names at the top of their respective pages only show the > Framework name. For example, instead of showing "KAboutData", it displays > "KCoreAddons" only. [1] > - The table-based layout for parameters/returns and their descriptions are > too narrow and run into each other. [2] > - The headers of Deprecated and Todo pages (of frameworks that have them) are > unreadable. [3] > > Probably small stuff but enough to get started on making the apidocs look > professional. On that note, is there someone I need to get in touch with > about the design of the apidocs? ECM, for example, looks totally out of place. >From my understanding ECM has a totally separate and different system for generating it's API Documentation (because Doxygen can't handle CMake files I believe) which is why it looks totally different. > > I'd love to hear your thoughts and suggestions on the current state of our > Frameworks apidocs and how we can make them even better than before. I'm also > on IRC (Jucato) and Matrix (also Jucato), though do note I live on UTC+8. > > 1. https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html > 2. > https://api.kde.org/frameworks/attica/html/classAttica_1_1AccountBalance.html#a71c29c3638accbd6216be60b08509b76 > 3. https://api.kde.org/frameworks/karchive/html/deprecated.html > > > Regards, Cheers, Ben > > -- > > Juan Carlos Torres > Jucato
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: Updating the Framework apidocs part 1: fixing the presentation
On Fri, Mar 29, 2019 at 5:01 PM Ben Cooksley wrote: > From my understanding ECM has a totally separate and different system > for generating it's API Documentation (because Doxygen can't handle > CMake files I believe) which is why it looks totally different. > Just as I feared. Hopefully we can create a suitable theme if we have to stick with using Sphinx in the foreseeable future. Or at least switch to the built-in bizstyle that is at least visually closer to our apidocs in the meantime. Thanks! -- Regards, Juan Carlos Torres Jucato
Re: CI system maintainability
Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel: > Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit : > > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel: > > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit : > > > > Given the actual purpose of this thread, I would be more curious how > > > > you > > > > have CI integrated in your workflow? > > > > > > CI: sometime I look at it, sometime not, sometime some guys informs me > > > that > > > it's broken (I remember that Luca told me some days ago that a package > > > didn't compile, so I fixed it). > > > Sometime my code compiles on local so for me it's ok but it's just that > > > I > > > forgot to trash my builddir. > > > > So you do not go on yourself to build.kde.org and check yourself? Does > > #kde- pim have a bot reporting build failures? > > Long time ago we had it in #kontact. > It's not the case now. Do you remember a reason why it is no longer the case? IMHO bringing the build report bot back to the chat channel could help with the issue this thread is about. People tend to look more often into the chat channel then in their email folder, so this bot would improve the visibility of the state on build.kde.org, also be in a public place so people can directly chat about any reasons. > > > > 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 :) > > > > > > I think that Luca idea to send an email directly to the people which > > > breaks > > > code when it breaks from several commit is a good idea. > > > > Noted. Personally I would also fancy that over the generic mass emailing, > > where most of the time it was somebody else breaking stuff, so they should > > care. Given the time-offset due to build times it is also unclear who > > broke > > things, given the email is not easy to parse, and one might already be off > > again to other things in life. > > > > Question is: when would you read the email, and how quick would you react? > > I read it sometime as it arrives in my kdepim-devel mailbox, but indeed > sometime we can have several mail in same time because we increase a package > dependancy and it breaks all other packages. So indeed I didn"t look at all > the time. > > But when a people signals me a problem I try to fix it quickly. > > An email send after 1 day that package is broken can be a good idea, so it > can't be a dependancy problem because we increase package version just that > it's really broken. Increasing the package version ideally should not result in CI breakages. Ideally CI only fails if there is a real issue, otherwise people just get used to it failing and do not give the deserved attention. What would prevent you to turn to a system like used with KDE Frameworks, where there is some internal dependency version and a separate actual version, with the actual version bumped earlier and the internal dependency version only bumped some days later? From what I saw, you increase versions quite often in PIM, so related breakages would happen quite often. Cheers Friedrich PS: Okay if we start to slim the list of CC:s a bit now? Would leave out plasma, kdevelop, frameworks-devel on any next reply at least.
Re: CI system maintainability
Hello, A Merge Request in GitLab does not necessarily imply the need for a review by e person. It can just run a pipeline to validate that the code isn't broken. If the pipeline fails, the merge button is not available. We use GitLab at work and we have it set up like this: * Main branches (develop/master/release/etc) are proteted and cannot be directly commited/pushed to, and only updated through MR * Each project defines what it's build/validate pipeline is (Jenkinsfile in project repo) * The pipeline is executed uppon creating the MR * if the Pipeline passes, the MR can be merged to the mainline branch This way we ensure that no code gets in that fails the build or with tests failing. P.S. We also store the build artifacts in a binary repository from where other pipelines can fetch them to be used in compiling other projects. P.P.S. This is the "DevOps" process used in most companies. The tools might differ, but the process is the same. It's the same for most FOSS projects as well. Regards, Ovidiu În ziua de joi, 28 martie 2019, la 10:29:22 EET, Kevin Ottens a scris: > 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. > signature.asc Description: This is a digitally signed message part.
Re: CI system maintainability
Am 2019-03-28 07:40, schrieb Ben Cooksley: Does anyone have any ideas for a long term, proper fix to this? At this point given the amount of effort required to maintain a CI system vs. the amount of care actually being given by some developers (who are ignoring it's failure emails) it becomes questionable whether the effort is worth the return (and if not, we should just shut it down) Hi Ben, I at least consider the CI system we have as super important and I'm super happy with it and extremely thankful for all the work you and the other sysadmins put into it. Given that I would find it sad if it were shut down because some devs are not playing along. Given the thread and what I read we seem to have here a case where a dev pushed a broken change without code review. That's IMHO not how we work in KDE. I don't think the complete community should be punished for misbehavior of some. My suggestion is that you get the right to revert broken changes. If it holds back everything and you sent a mail, what else should you do? Cheers Martin
Re: CI system maintainability
+1 for this. I think running tests before merging is more acceptable than having mandatory reviews. On 29 March 2019 11:10:52 GMT+00:00, Ovidiu-Florin Bogdan wrote: >Hello, > >A Merge Request in GitLab does not necessarily imply the need for a >review by e person. It can just run a pipeline to validate that the >code isn't broken. If the pipeline fails, the merge button is not >available. > >We use GitLab at work and we have it set up like this: > >* Main branches (develop/master/release/etc) are proteted and cannot be >directly commited/pushed to, and only updated through MR >* Each project defines what it's build/validate pipeline is >(Jenkinsfile in project repo) >* The pipeline is executed uppon creating the MR >* if the Pipeline passes, the MR can be merged to the mainline branch > >This way we ensure that no code gets in that fails the build or with >tests failing. > >P.S. We also store the build artifacts in a binary repository from >where other pipelines can fetch them to be used in compiling other >projects. > >P.P.S. This is the "DevOps" process used in most companies. The tools >might differ, but the process is the same. It's the same for most FOSS >projects as well. > >Regards, >Ovidiu > >În ziua de joi, 28 martie 2019, la 10:29:22 EET, Kevin Ottens a scris: >> 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. >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[ANNOUNCE] CMake 3.14.1 available for download
We are pleased to announce that CMake 3.14.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.14.1 since 3.14.0: Brad King (11): VS: Fix x64 host recognition by x86 cmake process find_program: Restore leading double slash on Windows network path Eclipse: Fix extra generator to not crash on interface libraries ARMCC: Fix identification of ARM compiler when it defines GNU macros Help: Clarify policy CMP0082 documentation Restore support for include_directories() in toolchain files CUDA: Tolerate square brackets in PROMPT environment variable cmake: Fix '-E copy foo .' to avoid clobbering file FindFontconfig: Convert module variables to camel case ParseImplicitIncludeInfo: Canonicalize implicit include dirs CMake 3.14.1 Clément Rezvoy (1): CPackIFW: Add missing cpack_ifw_configure_component_group option processing Marc Chevrier (1): FindPython*: ensure correct architecture is selected. Sebastian Holtermann (1): Autogen: Do not treat hard-coded -I/usr/include exclusion as implicit include Sylvain Joubert (1): ctest_coverage: fix out-of-bounds index in Jacoco parser
Re: CI system maintainability
On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl wrote: > > Hi, Hi, > > (Sorry for top-posting) > > I fear that a mandatory reviews would add too juch strain on smaller teams. > If there's just one person with an intimate knowledge of the code-base, plus > two co-developers, then who should do the reviews? > > How about a distinction based on importance of a project instead? I.e. > mandatory reviews for frameworks and any app that wants to be included in KDE > apps releases. Non-mandatory reviews can then also come with a "price" to > pay: if CI errors are not dealt with in a timely manner, you should be free > to disable the CI for administrative reasons... While this does seem like a nice solution, unfortunately for many repositories it isn't a case of disabling CI coverage for it, but also CI coverage for everything that depends on it. In the case of KContacts, this would also impact on parts of Extragear and Calligra (who depending on their exact requirements would either lose a dependency being available, or lose all of their CI coverage). This is why i've not pursued this as an option in the past, because it's not fair on other projects that don't have anything to do with another project aside from being a user of it's interfaces to lose their coverage, simply because the project they depend on is broken. > > Johannes Cheers, Ben > > Am 28. März 2019 10:17:18 MEZ schrieb Tomaz Canabrava : > >On Thu, Mar 28, 2019 at 10:09 AM 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. > >> > >> 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) > >> > >> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps > >direct > >> mailing to the user (as I suggested earlier) in case of continuous > >failures > >> will also help. > >> > >> If this thing works, one can gradually ramp up the requirements of > >things that > >> go through review when the "muscle memory" is formed. > > > >The problem is that a git comit is a git commit, there's no way that a > >typo will be treated differently then another commit. > >I strongly advocate for "reviews always", but since I was outvoted a > >few times on this I would at least say "can we at least have reviews > >for non project members" ? > > > > > >> -- > >> Luca Beltrame > >> GPG key ID: A29D259B
Re: CI system maintainability
On Fri, Mar 29, 2019 at 10:33 PM Friedrich W. H. Kossebau wrote: > > Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel: > > Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit : > > > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel: > > > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit : > > > > > Given the actual purpose of this thread, I would be more curious how > > > > > you > > > > > have CI integrated in your workflow? > > > > > > > > CI: sometime I look at it, sometime not, sometime some guys informs me > > > > that > > > > it's broken (I remember that Luca told me some days ago that a package > > > > didn't compile, so I fixed it). > > > > Sometime my code compiles on local so for me it's ok but it's just that > > > > I > > > > forgot to trash my builddir. > > > > > > So you do not go on yourself to build.kde.org and check yourself? Does > > > #kde- pim have a bot reporting build failures? > > > > Long time ago we had it in #kontact. > > It's not the case now. > > Do you remember a reason why it is no longer the case? > > IMHO bringing the build report bot back to the chat channel could help with > the issue this thread is about. It was quite possibly lost during one of the various refactors we've had to do of the CI system to solve maintainability issues. We've had a couple of generations of the CI system so far (by my count, we're on generation 4), and things have unfortunately been lost in between the switch between various generations. IRC channel notifications are currently governed by the rules in sysadmin/irc-notifications (which is also where commits and Bugzilla activity notifications for IRC channels are controlled from). See https://cgit.kde.org/sysadmin/irc-notifications.git/tree/jenkins/notifications.cfg > > People tend to look more often into the chat channel then in their email > folder, so this bot would improve the visibility of the state on > build.kde.org, also be in a public place so people can directly chat about > any reasons. > > > > > > 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 :) > > > > > > > > I think that Luca idea to send an email directly to the people which > > > > breaks > > > > code when it breaks from several commit is a good idea. > > > > > > Noted. Personally I would also fancy that over the generic mass emailing, > > > where most of the time it was somebody else breaking stuff, so they > should > > > care. Given the time-offset due to build times it is also unclear who > > > broke > > > things, given the email is not easy to parse, and one might already be > off > > > again to other things in life. > > > > > > Question is: when would you read the email, and how quick would you > react? > > > > I read it sometime as it arrives in my kdepim-devel mailbox, but indeed > > sometime we can have several mail in same time because we increase a > package > > dependancy and it breaks all other packages. So indeed I didn"t look at all > > the time. > > > > But when a people signals me a problem I try to fix it quickly. > > > > An email send after 1 day that package is broken can be a good idea, so it > > can't be a dependancy problem because we increase package version just that > > it's really broken. > > Increasing the package version ideally should not result in CI breakages. > Ideally CI only fails if there is a real issue, otherwise people just get > used to it failing and do not give the deserved attention. > > What would prevent you to turn to a system like used with KDE Frameworks, > where there is some internal dependency version and a separate actual > version, with the actual version bumped earlier and the internal dependency > version only bumped some days later? From what I saw, you increase versions > quite often in PIM, so related breakages would happen quite often. > > Cheers > Friedrich Cheers, Ben > > PS: Okay if we start to slim the list of CC:s a bit now? Would leave out > plasma, kdevelop, frameworks-devel on any next reply at least. > >
Re: CI system maintainability
On Fri, Mar 29, 2019 at 9:56 PM Kevin Ottens wrote: > > 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.). With the shift to Gitlab we should be able to provide this hopefully. We're still figuring out how to be able to provide CI in an easy to maintain manner (in terms of controlling platforms builds are done for, which branches, etc). This is a non-trivial problem (which is why Jenkins is only able to do master/trunk and stable builds currently) but it should be solvable. > > Regards. > -- > Kevin Ottens, http://ervin.ipsquad.net Cheers, Ben
