On Fri, Oct 4, 2013 at 9:58 AM, Menard, Alexis <alexis.men...@intel.com>wrote:
> > On Oct 4, 2013, at 1:54 AM, Raphael Kubo da Costa < > raphael.kubo.da.co...@intel.com> wrote: > > > (Changing subject to something more on-topic) > > > > "Ketrenos, James P" <james.p.ketre...@intel.com> writes: > >> On Thu, Oct 3, 2013 at 1:14 PM, Caio Marcelo de Oliveira Filho < > >> caio.olive...@intel.com> wrote: > >> > >>> On Thu, Oct 03, 2013 at 11:09:59PM +0300, Raphael Kubo da Costa wrote: > >>>> While this is technically possible, it goes in the opposite direction > of > >>>> what we've been doing so far and what we've agreed upon: > >> > >> When requirements for the automated Canary build system were originally > >> discussed, it was indicated that if the build for a platform fails, that > >> platform won't have a Canary release that day. If that changed, I wasn't > >> aware of it. > > > > Sigh, apparently this is something I discussed in private with Alexis, > > so I apologize if you weren't aware of it. > > > > So your suggestion for the long-term is to bump the versions in the > > repository and publish canaries if at least one of the platforms builds > > succesfully, right? > > > > For example, there could be no crosswalk-1.29.25.0.zip for Android even > > if crosswalk-1.29.25.0-0-i586.rpm was published and the version files in > > the crosswalk repository say it is at 1.29.25.0. > > I don't think this is the way it works for Chromium and I strongly > disagree with bumping the canary if only one platform build/work. > The Canary build number should be bumped any time there is an attempt at a build, regardless of the binary publication policy. Chromium has this policy of closing the tree when it gets on fire, we don't > have this mechanism but we should at least aim for something similar in > another way. If the Canaries are not building it's a big red flag for the > project. We broke our top important platforms. > I completely agree if commits are landing which are breaking the build on different platforms, those commits need to be fixed. However, the Canary release point is not the correct process location for this enforcement to occur. Failures in the Canary build system may not be in the code; it could be the hardware, it could be a network connection issue, it could be any random assortment of reasons. If a canary try fails to build for a given platform we should all try to > fix the broken stuff no matter what it is. Who is "we" ? The entire Crosswalk development community? Not everyone in the Crosswalk community is a core developer of Crosswalk itself; you have application developers, extension developers, validation teams, etc. > It may be that an hypothetical patch broke Android and it was not related > to Android specific files, we should all care about the entire product. > Ideally that patch should be reverted by "infrastructure" (human, buildbot, whatever) before the Canary build ever kicks in. If the Canary happens to fire off after a broken commit has landed and before it has been reverted, that sucks--no canary for that platform on that day. 24 hours, and there will be a new Canary. The timing of when the Canary build fires off is such that it will minimize the time when patches are actively landing in tree--so ideally any breakage would have been reverted before the Canary is executed. It's giving a confusing message to the public : why Tizen is version XXX > and Android is version XXX+2 (or 3, or 4) for example if they get out of > sync. Keep the target audience in mind -- the "public" (HTML5 Application Writers and end-users looking to run those applications) should be pulling Beta (and eventually Stable) images. Canaries are not advertised for platforms that have stabilization branches (which is all of them right now.) Canaries are for active developers, most likely extension developers (since "core" developers would be building their own Crosswalk from source). For an extension developer, if new functionality I need landed in tree Monday, and the Canary the next day doesn't exist on Android, I can still load the Tizen version in my Tizen emulator and continue my extension development. And if the Tizen version explodes on me, hey, its a Canary. YMMV. > In the reports of QA at least they will test the same canary version with > no potential intermediate patches in between. What if these delta of > patches fixes bugs, Let's go through a use case: If validation tests on Monday and there wasn't an Android build on Monday, Monday won't have any validation results for Android. For that, validation can file one bug "crosswalk-2.31.7.0 does not exist for Android". Ideally, they would have crosswalk-2.31.7.0 for the Tizen platform they can test. If they find a bug on Monday with crosswalk-2.31.7.0 on Tizen, the bug filed would be "Feature X is broken" and it would state "Tested on 2.31.7.0 on Tizen". The developers for feature X saw the bug reported against 2.31.7.0 and fixed it. They mark it Fixed in 2.31.8.0 (the next canary scheduled at the time they fixed the bug.) On Tuesday, there would be a new Canary (crosswalk-2.31.8.0). Hopefully the build for Android is fixed and QA can again validate on Android. QA verifies the fix in crosswalk-2.31.8.0 on Tizen. It works! Yay. They add a comment to the bug "verified on crosswalk-2.31.8.0 on Tizen" At this point they also have an Android build, and they attempt the functionality there. Yay it works, or crikey its broken! Either direction--they can add a note to the bug providing that information, and re-open the bug if appropriate. it's going to be a nightmare to understand why it passes on Android and not > on Tizen, you'll have to manually think "oh yes the canary of Tizen is > older so it doesn't contain the patch" making QA reports confusing at best. > There isn't a generic "canary of Tizen" there is crosswalk-2.31.7.0 on Tizen, or crosswalk-2.31.6.0 on Tizen, or crosswalk-2.31.8.0 on Android. All Issues filed and QA reports, to be useful, must explicitly reference the specific crosswalk version. In all of this, ideally, Canary builds should never be breaking for one platform and not another--that should be caught and corrected by other layers of SCM. However, if they do break, it shouldn't be blocking forward progress of individuals that could have benefited by having the latest Canary for *any* platform. The above process is similar for the Beta branches as well, only not necessarily only in regard to whether it builds, but whether it passes validation. Should crosswalk-1.29.5.0 be blocked for Tizen if on Android 1.29.5.0 crashes? What if 1.29.5.0 is fixing a bug that only existed on Tizen and there is no reason to update Android to 1.29.5.0? Should a new 25M binary be pushed to every Android device even though there was no actual change? James > Thanks. > > > _______________________________________________ > > Crosswalk-dev mailing list > > Crosswalk-dev@lists.crosswalk-project.org > > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
