RESOLVED FIXED 184887
[GTK][WPE] Add Debug bots (build and tests) for WPE
https://bugs.webkit.org/show_bug.cgi?id=184887
Summary [GTK][WPE] Add Debug bots (build and tests) for WPE
Pablo Saavedra
Reported 2018-04-23 09:34:30 PDT
We have deployed 2 new bots for WPE Debug: * wpe-linux-bot-3 * wpe-linux-bot-4 Both bots have already the credentials ready to authenticated against build.webkit.org. They provides the bots for the "debug" configuration over the "WPE" platform and building for the "x86_64" architecture. *  WPE Linux 64-bit Debug (Build)  *  WPE Linux 64-bit Debug (Tests)  They have been tested with the trunk for several weeks already and it is in good shape. We would like to contribute them at build.webkit.org
Attachments
patch (6.63 KB, patch)
2018-04-23 09:54 PDT, Pablo Saavedra
no flags
patch (6.45 KB, patch)
2018-04-23 11:08 PDT, Pablo Saavedra
no flags
patch (6.49 KB, patch)
2018-04-23 13:38 PDT, Pablo Saavedra
no flags
Pablo Saavedra
Comment 1 2018-04-23 09:54:17 PDT
Carlos Alberto Lopez Perez
Comment 2 2018-04-23 11:01:45 PDT
Comment on attachment 338590 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=338590&action=review > Tools/BuildSlaveSupport/build.webkit.org-config/config.json:337 > - { > + { This change doesn't seem needed. > Tools/BuildSlaveSupport/build.webkit.org-config/config.json:342 > + { check also the ident level here (aka don't mix spaces and tabs please)
Pablo Saavedra
Comment 3 2018-04-23 11:08:39 PDT
Carlos Alberto Lopez Perez
Comment 4 2018-04-23 11:13:02 PDT
Comment on attachment 338595 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=338595&action=review > Tools/BuildSlaveSupport/build.webkit.org-config/config.json:360 > + "JSCOnly Linux MIPS32el Release", "WinCairo 64-Bit Release", "WinCairo 64-bit WKL Debug (Build)", > + "WPE Linux 64-bit Release (Build)", "WPE Linux 64-bit Debug (Build)"] Same issue with tabs here (use spaces please) > Tools/BuildSlaveSupport/build.webkit.org-config/config.json:449 > + { "type": "Triggerable", "name": "wpe-linux-64-debug-tests", Same ident-level issue here.
Pablo Saavedra
Comment 5 2018-04-23 13:38:22 PDT
Carlos Alberto Lopez Perez
Comment 6 2018-04-23 14:04:22 PDT
Comment on attachment 338600 [details] patch LGTM! thanks
WebKit Commit Bot
Comment 7 2018-04-23 14:41:47 PDT
Comment on attachment 338600 [details] patch Clearing flags on attachment: 338600 Committed r230925: <https://trac.webkit.org/changeset/230925>
WebKit Commit Bot
Comment 8 2018-04-23 14:41:49 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 9 2018-04-23 14:42:23 PDT
Michael Catanzaro
Comment 10 2018-04-23 17:37:34 PDT
They need to be added to the bot watcher's dashboard too, otherwise most of us will never see them. (I know clopez likes waterfall view, but I never look at it.) We might seriously consider removing the release bots from the dashboard, while we're at it, and making the debug bots our primary focus. I expect that would result in increased quality.
Carlos Alberto Lopez Perez
Comment 11 2018-04-23 18:56:09 PDT
(In reply to Michael Catanzaro from comment #10) > They need to be added to the bot watcher's dashboard too, otherwise most of > us will never see them. Do you have any statistics about how many developers use the dashboard vs the waterfall? I will be interested in seeing those statistics. But if you don't have that, then please don't make claims about what you don't know. > (I know clopez likes waterfall view, but I never > look at it.) > I also know you like it, and I also never look at the dashboard :) Adding the bots to there should be done in another patch, tough. Those are independent things. > We might seriously consider removing the release bots from the dashboard, > while we're at it, and making the debug bots our primary focus. I expect > that would result in increased quality. I don't think that is a serious suggestion :)
Michael Catanzaro
Comment 12 2018-04-24 05:53:16 PDT
(In reply to Carlos Alberto Lopez Perez from comment #11) > > We might seriously consider removing the release bots from the dashboard, > > while we're at it, and making the debug bots our primary focus. I expect > > that would result in increased quality. > > I don't think that is a serious suggestion :) No, it's a very serious suggestion... we'd still have the release bots, but they would not be as visible anymore. I think we should do it....
Carlos Alberto Lopez Perez
Comment 13 2018-04-24 07:39:16 PDT
(In reply to Michael Catanzaro from comment #12) > (In reply to Carlos Alberto Lopez Perez from comment #11) > > > We might seriously consider removing the release bots from the dashboard, > > > while we're at it, and making the debug bots our primary focus. I expect > > > that would result in increased quality. > > > > I don't think that is a serious suggestion :) > > No, it's a very serious suggestion... we'd still have the release bots, but > they would not be as visible anymore. I think we should do it.... I'm fine with adding the WPE debug bots, pretty much like there are debug (and release) bots for GTK there. But I don't think removing the release ones from there is something good, sincerely. And I don't think we should trick developers in paying attention to debug builds if they are not really interested in doing that. Which is something that is not going to work in any case, because sooner than later someone will complain why the release bot is not there, and then she will propose a patch to add it back, and then someome will r+ it. And if you oppose to that, then we will end in an unfruitful discussion that will not produce more than frustration on both sides of the argument. To have more attention to debug builds I suggest instead to look for ways to make debug builds more usable. Speaking for myself, I usually don't use debug builds for two reasons mainly: 1. Build webkit with -O0 makes the built product unbearably slow, just opening a website and trying to use the browser makes you want to cry. 2. Build webkit with -g (full -g) makes the built product very big, so the amount of free disk space you need to handle it is much bigger than on release. I don't have good solutions to the above problems, but I'm sure any proposal that is going to make me want to use debug builds by default will have to address some of the above points, as I won't get tricked (but annoyed instead) if we hide the release bot on the dashboard.
Michael Catanzaro
Comment 14 2018-04-24 09:25:21 PDT
(In reply to Carlos Alberto Lopez Perez from comment #13) > I don't have good solutions to the above problems, but I'm sure any proposal > that is going to make me want to use debug builds by default will have to > address some of the above points, I'm not going to propose that. > as I won't get tricked (but annoyed > instead) if we hide the release bot on the dashboard. I don't understand why; currently we are looking at the less-interesting bots and missing important problems.
Carlos Alberto Lopez Perez
Comment 15 2018-04-24 09:38:21 PDT
(In reply to Michael Catanzaro from comment #14) > (In reply to Carlos Alberto Lopez Perez from comment #13) > > I don't have good solutions to the above problems, but I'm sure any proposal > > that is going to make me want to use debug builds by default will have to > > address some of the above points, > > I'm not going to propose that. > > > as I won't get tricked (but annoyed > > instead) if we hide the release bot on the dashboard. > > I don't understand why; currently we are looking at the less-interesting > bots and missing important problems. Sincerely, If you don't understand my reasoning reached this point of the argument, then its better we stop this discussion here as I don't think I will manage to convince you, neither I think you will manage to convince me. Let's agree on disagreeing :) I may suggest you to propose a patch that allows to make the bots show on the dashboard configurable? That way you can opt-in to hide the release ones if you wish.
Michael Catanzaro
Comment 16 2018-04-24 10:36:29 PDT
I don't think I'm going to spend time on that, sorry. I don't understand why you think it's valuable to prominently display the release bots on the dashboard? Well, the buildbot is valuable, but the test bot always shows fewer failures than the debug bot and I don't think I've ever seen it the other way around. We could even keep the release test bot, but move it off to the side.
Carlos Alberto Lopez Perez
Comment 17 2018-04-24 10:50:17 PDT
(In reply to Michael Catanzaro from comment #16) > I don't think I'm going to spend time on that, sorry. > > I don't understand why you think it's valuable to prominently display the > release bots on the dashboard? Well, the buildbot is valuable, but the test > bot always shows fewer failures than the debug bot and I don't think I've > ever seen it the other way around. We could even keep the release test bot, > but move it off to the side. I find valuable to get all the possible information. Its not the same seeing the release bot aborting early than the Debug one. And I find zero reasons to hide that info. Its not like we are overwhelmed by the number of WPE bots, we only have 2 test bots. Also, if all the other ports are showing the info from the Debug and Release bots on the dashboard, why we should do different for WPE? Or are you going to propose also to hide all the release bots from the other ports on the dashboard? if not.. why only WPE?
Note You need to log in before you can comment on or make changes to this bug.