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. > > 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 > :) ), 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. KPIM doesn't have a big active team... > 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. I know that I don't participate a lot on qtcreator dev as we need to wait long time to have some review... > > 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. > 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. If I received directly a message about kcontact 19.04 after 1 days I fixed it directly. Master build correctly and unfortunately I don't have 19.04 and master in parallel. Regards > > 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
