Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit : > Thanks for reply. More below: > > 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 : > > > Hi Laurent, > > > > > > 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? > > > > I maintain pim* from several years, I fix bugs, I improve apps, I fix all > > bugs that I put in my code, so for this one I consider that I can commit > > without review them (as other guys on other project that they maintain). > > For framework I mainly use phabricator. > > I was thinking of projects where there are multiple persons contributing/ > maintaining, like Frameworks.
For framework I use mainly phabricator See https://phabricator.kde.org/people/revisions/196/ > > So for projects where you are the only person who has any real insight, > indeed I agree to pushing directly, as I do that as well :) > > Because IMHO the costs for having to hope & wait for somebody else to do a > "review", where one then spends lots of time rather explaining things to > someone, who is not really into the project and also never might be, is not > anywhere worth the time one could have otherwise invested in fixing other > existing bugs or adding new features or improving code quality. > > If people want to get into a project, doing own patches or just watching the > commits and asking normally on irc or by email about the architecture > should work good enough. Abusing reviews for teaching about some project > would annoy me at least, usually the patch is to fix some annoying bug or > add a wanted feature, so it should get in as early as possible. > > > > 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. > > > > 2 weeks for a commit, for me it's too long. > > I understand why people can be demotivated when they must wait long time > > until having an answer. > > Well, 2 weeks is the time-out, only reached in worst case. Ideally people > give some feedback before, which often enough happens. And indeed one also > has to hunt people down to get a review, like at meetings or in chat (or > trade review work with each other :) ). But isn't this the same also at > work- work, unless there is a dedicated review team which needs to react by > itself? Co-operating on something needs social interaction after all. > > > > 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. > > For what I can tell e.g. for KDevelop, personally I rely on the bot on > #kdevelop reporting the CI state/build results, as I only look at emails > rather once a day, while the chat channel is more real-time, and one also > can immediately talk to peers about why some build now fails, as well as > coordinate who will fix that. > > > > 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 :) > > > > 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. > > One could say, Ben has had to simulate such a email bot already a few times, > and seems that worked to some degree (and I do not want to say we respect > Ben as much as we would respect a bot sending such email, hm, how do I get > out of this logic... ;) ) > > Cheers > Friedrich -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent software solutions