You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2020/04/02 05:58:46 UTC
Royale Releases
Hi,
This is my attempt to explain what goes into a release in hopes that we can understand and agree on what our release process is. It became apparent in my reading of the wiki page with the new Maven steps and in talking with Harbs today that there are still many misunderstandings about what we do to create a release. I don't generally like writing instructions in English because it is easy to be ambiguous. All of the steps that we use to create releases had been captured in Ant scripts in a much more explicit way, IMO, but I took the time to write them down in English here: https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
I did this quickly by scanning the CI steps, the new Maven steps and the Ant scripts used in prior releases so there could certainly be mistakes and missed steps. If I did my math right, the RM for 0.9.7 will have to complete over 100 tasks (essentially, typing a command-line 100 times). Future RMs, when we don't have to release build-tools, will have about 92 steps. And I did not include voter verification checks the RM should run before opening a vote (verifying that the artifacts download and match their checksums, etc). As an RM, I run a bunch of tests on the RC before sending out the vote. Maybe we should add those to the task list.
I think there has been confusion about the use of Ant in the release process. Because I was the RM for the first set of FlexJS/Royale releases, and I'm a lazy person who hates typing at the command line, I created Ant scripts to execute these 100 steps. But I agree that it is not a requirement that other RMs must use the Ant scripts for these commands. If you are the RM and like typing, go ahead.
Then we found out that other people couldn't get through this task list. I think the 3 people who tried were having trouble with Maven uploads and downloads. So what I did was put the first 40 steps or so into Jenkins jobs. And by doing that, Piotr was able to produce our last release. And that also saves on manually typing commands. But again, going forward, the RM gets to choose how they want to execute these steps.
If you scan the set of steps, you'll see that "ant" is only in there once. I believe the recent threads have been about this single command out of the 100+ commands. This is why this has been so frustrating to me. I believe there is a solid technical reason for that one command: it proves that the build.xml files in the source packages can build the .tar.gz that are useful to NPM and IDE users who use Ant and want to test a change.
I think of it as code-coverage. If we had code-coverage tools, we would ask that the RM complete as much of the automated code-coverage testing as possible before posting the release for a vote. That one command increases our code coverage by running the build.xml files. We should be always working to increase automated code coverage in the RC. Certainly for me as RM, I will gladly watch TV as the automated tests run because a failed RC means going back through many of the first 25 commands again and wastes other people's time. Each RC is more emails to read and more time from the voters and testers.
If there are other ways for the RM to get the same or better code coverage on the build.xml files before posting the RC, we can discuss those options.
I am hopeful we can all agree on these simple principles: Strive for better code coverage and fewer failed RCs. Royale's main purpose is to save other people time. Let's do that in creating releases too.
One issue that was brought up recently was whether it is a good decision to have the RM test all of the build platforms we support. Suppose we add some other build system support or more in the future? Again, the code coverage principle applies here, but also, I would like us to retain feature parity, and I also hope for as few RCs and votes as possible. So instead of having separate votes/features/release-dates for the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech artifacts, I think we should have one vote and keep them all in sync. If we do ever get around to monthly or bi-monthly releases, I think separate build platform releases would be too much work.
But consider this thought I just had today: the RM doesn't really have to choose to do all 100 commands on a local machine or with Ant scripts or do the first 40 via CI. The RM can actually pick and choose commands to run on the CI server. The CI Jenkins jobs are not a separate/alternative release process, they are just another way of executing the first 40 steps. Using CI jobs actually requires additional command-line cut-and-paste to push commits on the CI server and to sign and validate binaries locally, but that's the trade-off of not having to configure your machine to successfully run all of the automated tests and build systems, and being able to run a command by filling in the version number and rc number and hitting the "ok" button instead of making sure you got the whole command typed in correctly.
So, an RM can run the first 25 steps locally, then go the CI server and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run the first 12) and it will run tasks 26 through 32, and if it is successful, then the RM has proven code coverage of the build.xml files. (If the resulting tar.gz and zips are not posted, then the RM should verify that they match the ones from Maven distribution). I would encourage RMs to also use the CI jobs that generate the emails to make sure the subject and content is correct and contains the usual instructions so we have consistency. Maybe someday there will be CI jobs to do the last 60+ steps if that helps. We could add a Jenkins job that runs an Ant build on RC artifacts on dist.a.o as well.
I would like you all to help maintain the list of 100 steps and other documents related to the release process, and improve the CI jobs and Ant steps if it helps you be a more efficient RM. I am hopeful that now that I have hopefully explained our release process better, that we can see that these 100+ steps just have to be done in some way. The RM can figure out what way works best for them, but they must get through all of them.
Thanks,
-Alex
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The 100 steps do not include verifying the reproducible binaries. We've had around 100 commands for each Royale release. The Maven changes Chris put together added another 10 or so but actually allows us to have a flat list without "if/else" branches so that's probably worth it. Each command produces something our users need or Apache requires, or saves the voters time. That's why I honestly don't think there is anything we can/should drop. You can wish it was 15 commands, or do 15 commands when you are an RM, and you will find out that the release is not complete.
Royale is not a standard Java project, so releasing it will not be as simple. Royale has 3 repos (probably should be 5). I believe that the Java code in the one repo is turned in to Maven release artifacts in the standard Maven way. The other Maven release artifacts are more-or-less generated in a standard Maven way. But Royale is here to support legacy technology in order to attract migrating Flex users. So we support ActionScript, MXML, and Ant. And we want to support some new technology like NPM. That adds complexity. And we use the Git branching model. That adds more commands to the list. It just adds up.
Reproducibility was working in 0.9.6 but it looks like there was a bug around the Daylight Savings/Summer Time transition. I already pushed what I hope will fix that. Changes to the Ant scripts so that the Java jars binary match whether built in Ant or Maven are welcome and useful but not necessary. The main goal of reproducible binaries is to prove that the binaries actually did come from the source given you use some set of invariants (build tools, compiler versions, etc) to build it. It is a lesser goal to have the binaries produced by different build tools to match. Right now, I'm not sure that tests for reproducibility needs to be added to the list of 100 commands (it is required for using the CI jobs) but I think the day will come when we'll need to add it because some distributor requires it so it can be digitally signed. AIUI, that's why so many people, not just Royale, have invested in reproducible binaries. We may be the only project at Apache that does it, but the mainstream Apache Java projects may not need to distribute via npm or the Apple App Store.
In summary, we have different requirements, and thus, a longer set of release tasks.
I would like to see acknowledgement from as many PMC members as possible that they understand this reality and that this makes sense from a technical perspective and isn't just my opinion.
Thanks,
-Alex
On 4/3/20, 5:00 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Harbs,
for me ok. My point is just that Alex, Yishay and you (and any other want)
that thinks all that is needed want to go with that steps, it's totally ok.
Other like me will want just the simpler method since don't see a reason to
do in other way. At the end, this is open source and while the release is
ok, it should be ok for all of us.
Just please, don't try to impose complex methods to the rest. Ant build
will be ensure that is working properly as well as Maven.
Each RM must try different methods and see how works better for him, since
I'm sure both will be equally valid, since this is the ASF and the rules
are clear.
For me I just want to have that point clear, and we can stop this
discussion and let Yishay do its work on release.
As well, if you all think it can be last many time, maybe would be good for
our users that I do 0.9.7 and then Yishay go within a month with 0.9.8 and
you then in other month with 0.9.9. People is waiting for us. Just a
suggestion from my part. That probably will give you time to improve that
100 commands process.
Thanks!
El vie., 3 abr. 2020 a las 11:37, Harbs (<ha...@gmail.com>) escribió:
> Why don’t we hold off on discussing this until Yishay and I have both gone
> through a release process?
>
> I’m sure the necessity (or lack thereof) will become clear to us once
> we’ve done it.
>
> > On Apr 3, 2020, at 11:23 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > trying to summarize again with this plan seems to me unnecessary, in a
> way
> > that maybe until now nobody exposed and could be the key to understand
> the
> > problem:
> >
> > if we ask ourselves: "Are we generating the same artifacts between build
> > systems at bit level?", the response is "No". They should be mostly the
> > same for an user to work with it, but after working on a release it was
> > clear to me that each build system has its own "idiosyncrasy" (to say it
> > some way), since we us to have files like metainfs, xmls, or other things
> > that are not generated the same way.
> >
> > "are we creating reproducible builds?". "No". Since the compiler is not
> > prepared for it. Due to differences in OS (and possibly JDK Vendor) the
> > order generated in some files is different (as already exposed many days
> > ago). So reproducible builds in 0.9.6 are not real. "what needs to be
> made
> > to have reproducible builds?". "Fix the compiler is needed to implement
> > it".
> >
> > Far beyond, "If we fix the compiler to have real reproducible builds will
> > we have reproducible builds between build systems?". "No, will be only
> > reproducible from a concrete build system perspective". So builds for Ant
> > are reproducible for Ant, and builds done with Maven are reproducible
> with
> > Maven, but are not comparable between them due to latest point, each
> build
> > system generate slightly different artifacts. Checking jars for binary
> > equality will fail (just opening with a tool like intellij will show you
> > the problem easily).
> >
> > (subsection: since reproducibility seems more work we can left for post
> > 1.0.0)
> >
> > So "if you make a release using one build system have sense to mix with
> > other build system during the release?", "No, since as we are creating
> > different artifacts, just running a full build, when release is done, to
> > test the rest of build systems are working is enough to check it". Or "it
> > no has sense to do release steps for all build systems since we just need
> > to push one set of artifacts and we are really not checking any relation
> > between them since are different things at byte level although can work
> the
> > same for an user"
> >
> > If the problem is to save time to the rest of people verifying the
> release,
> > the RM can do a full build with *all* build systems to check the
> integrity
> > and that build systems are working as we all expect, so RCs are in the
> same
> > state as running the 100 steps. That will far easy and quick than doing
> 100
> > commands that really are not performing what we expect from what I
> > explained here.
> >
> > In resume, both ways are the same, since reproducible builds are only
> > affecting to the build system from what you're building and the so-called
> > "reproducible artifacts" and not "comparable" with same artifacts
> generated
> > by other build systems, so artifacts done with different systems are
> > essentially (bit level) not equal).
> >
> > If after all the evidences exposed here, you still insists in impose a
> 100
> > command recipe, I honestly will not understand.
> >
> > In exchange, if you (or other) feels better doing 100 commands when
> acting
> > as RM, is completely up to you, while don't try to impose to the rest of
> > the project.
> >
> > HTH
> >
> > Thanks
> >
> > Carlos
> >
> >
> >
> >
> >
> > El vie., 3 abr. 2020 a las 6:35, Alex Harui (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> I honestly can't think of any steps we can do without. If you can
> explain
> >> technically why some step isn't needed, then we can discuss it. I'm
> sorry
> >> you don't agree. I hope the rest of the PMC will agree that we have to
> do
> >> all of these steps and support the RM in doing so.
> >>
> >> One way to not have to actually type 90+ command is to use the Ant steps
> >> or CI jobs. Ideas on how to do less typing to execute these 90+
> commands
> >> are welcome.
> >>
> >> -Alex
> >>
> >> On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >>
> >> Hi Alex,
> >>
> >> sincerely, I don't understand that, and was not what I understand for
> >> your
> >> first email. I must say that I completely disagree that we need to do
> >> 90 or
> >> 100 commands to get a release that should be around 15. I think we
> >> have a
> >> problem with what we really need here.
> >>
> >> Maybe the solution is to get some external mediator that have a good
> >> experience with multiple build systems and releases and could give us
> >> his
> >> opinion from outside, so we can have the most logic option. I think
> if
> >> we
> >> can get someone that could give a hand could be very good for us.
> >>
> >> Can we ask in Apache for someone that review it? Maybe this will be
> the
> >> only solution to avoid going in circles again, since I'm afraid that
> my
> >> response will not be what you expect, but sorry, don't see this as
> you.
> >>
> >> I think this shouldn't be a requirement to all RMs, so people that
> >> wants to
> >> do all that commands can do it, but I sincerely prefer to stick with
> >> the
> >> recipe that is the current standard in all projects (even the ones
> that
> >> have more than one build systems). Take for sure that if I see a need
> >> to do
> >> all of that I'll be glad to do it. But sincerily is something I don't
> >> share.
> >>
> >> Anyway for people that wants to do that kind of checking I think you
> >> get a
> >> good advance from the previous solution.
> >>
> >> Thanks
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> El jue., 2 abr. 2020 a las 21:50, Alex Harui
> (<aharui@adobe.com.invalid
> >>> )
> >> escribió:
> >>
> >>> Hi Carlos,
> >>>
> >>> The command lines in [1] have been added to [2]. [1] is only a
> >> partial
> >>> list of the things to do, but includes some helpful setup information
> >>> Hopefully in June we won't need to release build-tools so you will
> >> only
> >>> have about 90 steps to do, but we may have added more commands as we
> >>> improve our automated test infrastructure.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> [2]
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133509630&sdata=7b2QP82q07l8uJ%2FHLDf%2BYLEgFipHWraeImDXnYfukDE%3D&reserved=0
> >>>
> >>> On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org>
> >> wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> to understand your long email. Lets say that when I'll go to
> >> release in
> >>> June (0.9.9), I'll use instructions described in [1].
> >>> So that will create the sources needed to post. Then, to avouid
> >> later
> >>> problems for people verifying I'll verify it with Maven and Ant
> >> (build
> >>> with
> >>> both, and test SDK generated in example apps. Then push to
> >> dist.a.o,
> >>> create
> >>> discuss and vote threads, and start the vote.
> >>>
> >>> Is that ok?
> >>>
> >>> Thanks
> >>>
> >>> [1]
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133509630&sdata=7Gg6XZYyuNXyptEFKXSqqNwQsLXA9bIKP9Xrraji2CA%3D&reserved=0
> >>>
> >>> El jue., 2 abr. 2020 a las 19:16, Alex Harui
> >> (<aharui@adobe.com.invalid
> >>>> )
> >>> escribió:
> >>>
> >>>> I'm not sure I understand the distinction. I think we want to
> >> do
> >>> both.
> >>>> The goal of code coverage is to try to exercise paths. We
> >> want to
> >>> run "ant
> >>>> release" because our Ant users might want to do that. And Ant
> >> does
> >>> have
> >>>> assertions AFAICT. It will report errors. Meanwhile, the
> >> standard
> >>> for
> >>>> the .tar.gz package is the one produced by "ant release"
> >> because
> >>> that's the
> >>>> recipe we've been using for years now. The Maven
> >> distribution's
> >>> .tar.gz
> >>>> has been shown to work in most cases, but AFAICT, is nearly as
> >> well
> >>> tested
> >>>> and has not been binary-compared. Ways to compare the two
> >> .tar.gz
> >>> files
> >>>> are needed and welcome.
> >>>>
> >>>> More and better tests are welcome.
> >>>>
> >>>> Do we have agreement? It sounds like it. So I will now be
> >> spending
> >>> my
> >>>> evenings on the release instead of writing lists of 100 things.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com>
> >> wrote:
> >>>>
> >>>> Chris, I think you’re missing Alex’s point. We’re not
> >> running
> >>> Ant to
> >>>> make sure it doesn’t blow up. We’re running it to make sure the
> >>> resultant
> >>>> tar.gz/zip files are identical to the ones created by Maven.
> >> Alex,
> >>> please
> >>>> correct me if I’m wrong.
> >>>>
> >>>> ________________________________
> >>>> From: Christofer Dutz <ch...@c-ware.de>
> >>>> Sent: Thursday, April 2, 2020 4:42:00 PM
> >>>> To: dev@royale.apache.org <de...@royale.apache.org>
> >>>> Subject: Re: Royale Releases
> >>>>
> >>>> And to add a little to that [1]
> >>>>
> >>>> "In computer science, test coverage is a measure used to
> >>> describe the
> >>>> degree to which the source code of a program is executed when a
> >>> particular
> >>>> test suite runs."
> >>>>
> >>>> So no test, no coverage. Just using something and it's not
> >>> blowing up
> >>>> isn't a test for me. It's better than nothing however.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133509630&sdata=uTPNlW8%2FCs719Wtlf73RaOaCxFd2tupCCoRgCuV9hno%3D&reserved=0
> >>>>
> >>>> Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> >>>> christofer.dutz@c-ware.de>:
> >>>>
> >>>> Hi folks,
> >>>>
> >>>> I would say we have coverage for both maven ant
> >> equally as
> >>> we're
> >>>> building the same code.
> >>>>
> >>>> However we are missing the important assertions. It's
> >> not
> >>> that the
> >>>> Ant build is running some tests Maven isn't.
> >>>> It's just that the settings for Ant seem to be
> >> different
> >>> than for
> >>>> Maven and the Ant ones happen to work.
> >>>>
> >>>> Ideally there would be real tests that test the output
> >> of
> >>> both to
> >>>> see if it works in both cases.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> Am 02.04.20, 15:15 schrieb "Harbs" <
> >> harbs.lists@gmail.com>:
> >>>>
> >>>> Adding more coverage for Maven is good.
> >>>>
> >>>> Removing coverage for Ant is not.
> >>>>
> >>>> Do you agree?
> >>>>
> >>>>> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> >>>> carlosrovira@apache.org> wrote:
> >>>>>
> >>>>> Hi Harbs,
> >>>>>
> >>>>> I think what we're trying to say is that until
> >> now we
> >>>> released with Maven
> >>>>> and Ant, and that was hiding a flaw in Maven (SVG
> >>> example).
> >>>> So that means
> >>>>> what we were trying to cover was not covered
> >> clearly,
> >>> so the
> >>>> premise is not
> >>>>> right.
> >>>>>
> >>>>>
> >>>>>
> >>>>> El jue., 2 abr. 2020 a las 14:56, Harbs (<
> >>>> harbs.lists@gmail.com>) escribió:
> >>>>>
> >>>>>> No one is arguing that we shouldn’t add more
> >> tests.
> >>>>>>
> >>>>>> Please let’s not make it seem like there’s a
> >>> disagreement
> >>>> about that.
> >>>>>>
> >>>>>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> >>>> carlosrovira@apache.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Alex,
> >>>>>>>
> >>>>>>> first, many thanks for the detailed email. I'll
> >>> comment on
> >>>> this later as
> >>>>>> I
> >>>>>>> have more time.
> >>>>>>>
> >>>>>>> For now, to add up a recent example on what
> >> Chris
> >>>> commented: If you all
> >>>>>>> remember a week ago I was trying to use SVG
> >> Images
> >>> in a
> >>>> blog example that
> >>>>>>> was published 2 days ago. Nobody tried SVG
> >> Images
> >>> before
> >>>> building with
> >>>>>>> maven, I know that since maven was not properly
> >>> configured
> >>>> and using that
> >>>>>>> component from Maven was failing with an RTE.
> >>> Probably we
> >>>> have more
> >>>>>> things
> >>>>>>> not working the same way when build from Maven
> >> and
> >>> Ant,
> >>>> and that's
> >>>>>>> something that will need people using that code
> >>> paths in
> >>>> test
> >>>>>> applications
> >>>>>>> (or in their own apps) to see if things works
> >>> properly.
> >>>>>>>
> >>>>>>> I was recently introduced to
> >>> "examples-integrationtest" by
> >>>> Chris, that I
> >>>>>>> plan to use soon as I can. I think is a great
> >> idea,
> >>> since
> >>>> you get a
> >>>>>> Firefox
> >>>>>>> running test interface of the real use of some
> >>> concrete
> >>>> royale code. I
> >>>>>>> think passed until now unnoticed by all of us,
> >> and
> >>> seems a
> >>>> powerful tool.
> >>>>>>> There's already an example about FlexStore
> >> with some
> >>> basic
> >>>> assertions.
> >>>>>>>
> >>>>>>> Again, thanks, and will comment on the rest
> >> later
> >>>>>>>
> >>>>>>> Carlos
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> El jue., 2 abr. 2020 a las 9:20, Christofer
> >> Dutz (<
> >>>>>> christofer.dutz@c-ware.de>)
> >>>>>>> escribió:
> >>>>>>>
> >>>>>>>> Hi Alex,
> >>>>>>>>
> >>>>>>>> just a point you are bringing up: "Code
> >> coverage".
> >>>>>>>>
> >>>>>>>> I strongly dislike the idea of "asjs"
> >> effectively
> >>> being
> >>>> the test for the
> >>>>>>>> compiler. The reasoning behind this is: yes
> >> you do
> >>> get
> >>>> more code
> >>>>>> covered,
> >>>>>>>> but only the happy-path (ideally) and even if
> >>> things go
> >>>> wrong, the end
> >>>>>>>> results aren't tested. Did add a module to
> >> asjs
> >>> years ago
> >>>>>>>> ("examples-integrationtest") that deployed the
> >>> examples
> >>>> in a tomcat
> >>>>>> server
> >>>>>>>> then opens a Firefox browser and clicks
> >> through 2
> >>> of the
> >>>> examples (I
> >>>>>> added
> >>>>>>>> two dummy tests as an example, but seems no
> >> one
> >>> touched
> >>>> this after me).
> >>>>>> I
> >>>>>>>> did this because I remember us working on
> >> asjs for
> >>> weeks
> >>>> without anyone
> >>>>>>>> noticing the compiler wasn't producing
> >> runnable
> >>> code ...
> >>>> same with the
> >>>>>>>> little unit-tests that are still run for every
> >>> example,
> >>>> that simply
> >>>>>> check
> >>>>>>>> if an output is generated, because we had a
> >>> prolonged
> >>>> period of time
> >>>>>> where
> >>>>>>>> we were all working on different parts, but
> >> for
> >>> quite
> >>>> some time the
> >>>>>>>> application compilation just didn't output
> >> anything
> >>> and
> >>>> no one noticed.
> >>>>>>>>
> >>>>>>>> So coverage is nothing without assertions (my
> >>> opinion)
> >>>> ... ok ... it's
> >>>>>>>> slightly better than no coverage, but not
> >> much, in
> >>> my
> >>>> opinion.
> >>>>>>>>
> >>>>>>>> I think in parallel to this release
> >> discussions I
> >>> have
> >>>> seen numerous
> >>>>>>>> threads about someone doing something that
> >> broke
> >>>> something for someone
> >>>>>>>> else. This could be addressed by increasing
> >>> coverage by
> >>>> providing
> >>>>>> explicit
> >>>>>>>> tests.
> >>>>>>>>
> >>>>>>>> Coming back to the releases:
> >>>>>>>> I have no objections, if you do a "release"
> >> locally
> >>> and
> >>>> automate the
> >>>>>>>> validation on the CI server (Which effectively
> >>> would be
> >>>> your proposal
> >>>>>> to do
> >>>>>>>> the first 12 steps on local hardware and the
> >> 13th
> >>> on the
> >>>> CI server). I
> >>>>>> even
> >>>>>>>> think that's a good idea ... There could be
> >> one
> >>> step for
> >>>> building a
> >>>>>> release
> >>>>>>>> from a given "git tag" for every build system
> >> and
> >>> generic
> >>>> means to
> >>>>>> compare
> >>>>>>>> tar.gz and zips produced by any build system
> >> with
> >>> that of
> >>>> another
> >>>>>> (ideally
> >>>>>>>> with better output than just a plain
> >> "true/false").
> >>> This
> >>>> would even
> >>>>>> help to
> >>>>>>>> iron out the last potentially existing bumps
> >> out of
> >>> the
> >>>> Maven
> >>>>>> distribution.
> >>>>>>>>
> >>>>>>>> Chris
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> >>>> <ah...@adobe.com.INVALID>:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> This is my attempt to explain what goes
> >> into a
> >>> release
> >>>> in hopes that
> >>>>>>>> we can understand and agree on what our
> >> release
> >>> process
> >>>> is. It became
> >>>>>>>> apparent in my reading of the wiki page with
> >> the new
> >>>> Maven steps and in
> >>>>>>>> talking with Harbs today that there are still
> >> many
> >>>> misunderstandings
> >>>>>> about
> >>>>>>>> what we do to create a release. I don't
> >> generally
> >>> like
> >>>> writing
> >>>>>>>> instructions in English because it is easy to
> >> be
> >>>> ambiguous. All of the
> >>>>>>>> steps that we use to create releases had been
> >>> captured in
> >>>> Ant scripts
> >>>>>> in a
> >>>>>>>> much more explicit way, IMO, but I took the
> >> time to
> >>> write
> >>>> them down in
> >>>>>>>> English here:
> >>>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133509630&sdata=7b2QP82q07l8uJ%2FHLDf%2BYLEgFipHWraeImDXnYfukDE%3D&reserved=0
> >>>>>>>>
> >>>>>>>> I did this quickly by scanning the CI
> >> steps, the
> >>> new
> >>>> Maven steps and
> >>>>>>>> the Ant scripts used in prior releases so
> >> there
> >>> could
> >>>> certainly be
> >>>>>> mistakes
> >>>>>>>> and missed steps. If I did my math right,
> >> the RM
> >>> for
> >>>> 0.9.7 will have to
> >>>>>>>> complete over 100 tasks (essentially, typing a
> >>>> command-line 100 times).
> >>>>>>>> Future RMs, when we don't have to release
> >>> build-tools,
> >>>> will have about
> >>>>>> 92
> >>>>>>>> steps. And I did not include voter
> >> verification
> >>> checks
> >>>> the RM should
> >>>>>> run
> >>>>>>>> before opening a vote (verifying that the
> >> artifacts
> >>>> download and match
> >>>>>>>> their checksums, etc). As an RM, I run a
> >> bunch of
> >>> tests
> >>>> on the RC
> >>>>>> before
> >>>>>>>> sending out the vote. Maybe we should add
> >> those to
> >>> the
> >>>> task list.
> >>>>>>>>
> >>>>>>>> I think there has been confusion about the
> >> use of
> >>> Ant
> >>>> in the release
> >>>>>>>> process. Because I was the RM for the first
> >> set of
> >>>> FlexJS/Royale
> >>>>>> releases,
> >>>>>>>> and I'm a lazy person who hates typing at the
> >>> command
> >>>> line, I created
> >>>>>> Ant
> >>>>>>>> scripts to execute these 100 steps. But I
> >> agree
> >>> that it
> >>>> is not a
> >>>>>>>> requirement that other RMs must use the Ant
> >> scripts
> >>> for
> >>>> these
> >>>>>> commands. If
> >>>>>>>> you are the RM and like typing, go ahead.
> >>>>>>>>
> >>>>>>>> Then we found out that other people
> >> couldn't get
> >>>> through this task
> >>>>>>>> list. I think the 3 people who tried were
> >> having
> >>> trouble
> >>>> with Maven
> >>>>>>>> uploads and downloads. So what I did was put
> >> the
> >>> first
> >>>> 40 steps or so
> >>>>>> into
> >>>>>>>> Jenkins jobs. And by doing that, Piotr was
> >> able to
> >>>> produce our last
> >>>>>>>> release. And that also saves on manually
> >> typing
> >>>> commands. But again,
> >>>>>>>> going forward, the RM gets to choose how they
> >> want
> >>> to
> >>>> execute these
> >>>>>> steps.
> >>>>>>>>
> >>>>>>>> If you scan the set of steps, you'll see
> >> that
> >>> "ant" is
> >>>> only in there
> >>>>>>>> once. I believe the recent threads have been
> >> about
> >>> this
> >>>> single command
> >>>>>> out
> >>>>>>>> of the 100+ commands. This is why this has
> >> been so
> >>>> frustrating to me.
> >>>>>> I
> >>>>>>>> believe there is a solid technical reason for
> >> that
> >>> one
> >>>> command: it
> >>>>>> proves
> >>>>>>>> that the build.xml files in the source
> >> packages can
> >>> build
> >>>> the .tar.gz
> >>>>>> that
> >>>>>>>> are useful to NPM and IDE users who use Ant
> >> and
> >>> want to
> >>>> test a change.
> >>>>>>>>
> >>>>>>>> I think of it as code-coverage. If we had
> >>>> code-coverage tools, we
> >>>>>>>> would ask that the RM complete as much of the
> >>> automated
> >>>> code-coverage
> >>>>>>>> testing as possible before posting the
> >> release for a
> >>>> vote. That one
> >>>>>>>> command increases our code coverage by
> >> running the
> >>>> build.xml files. We
> >>>>>>>> should be always working to increase
> >> automated code
> >>>> coverage in the RC.
> >>>>>>>> Certainly for me as RM, I will gladly watch
> >> TV as
> >>> the
> >>>> automated tests
> >>>>>> run
> >>>>>>>> because a failed RC means going back through
> >> many
> >>> of the
> >>>> first 25
> >>>>>> commands
> >>>>>>>> again and wastes other people's time. Each
> >> RC is
> >>> more
> >>>> emails to read
> >>>>>> and
> >>>>>>>> more time from the voters and testers.
> >>>>>>>>
> >>>>>>>> If there are other ways for the RM to get
> >> the
> >>> same or
> >>>> better code
> >>>>>>>> coverage on the build.xml files before
> >> posting the
> >>> RC, we
> >>>> can discuss
> >>>>>> those
> >>>>>>>> options.
> >>>>>>>>
> >>>>>>>> I am hopeful we can all agree on these
> >> simple
> >>>> principles: Strive for
> >>>>>>>> better code coverage and fewer failed RCs.
> >>> Royale's main
> >>>> purpose is to
> >>>>>>>> save other people time. Let's do that in
> >> creating
> >>>> releases too.
> >>>>>>>>
> >>>>>>>> One issue that was brought up recently was
> >>> whether it
> >>>> is a good
> >>>>>>>> decision to have the RM test all of the build
> >>> platforms
> >>>> we support.
> >>>>>>>> Suppose we add some other build system
> >> support or
> >>> more in
> >>>> the future?
> >>>>>>>> Again, the code coverage principle applies
> >> here, but
> >>>> also, I would like
> >>>>>> us
> >>>>>>>> to retain feature parity, and I also hope for
> >> as
> >>> few RCs
> >>>> and votes as
> >>>>>>>> possible. So instead of having separate
> >>>> votes/features/release-dates
> >>>>>> for
> >>>>>>>> the Maven artifacts vs the Ant artifacts vs
> >> the
> >>>> SomeFutureBuildTech
> >>>>>>>> artifacts, I think we should have one vote
> >> and keep
> >>> them
> >>>> all in sync.
> >>>>>> If
> >>>>>>>> we do ever get around to monthly or bi-monthly
> >>> releases,
> >>>> I think
> >>>>>> separate
> >>>>>>>> build platform releases would be too much
> >> work.
> >>>>>>>>
> >>>>>>>> But consider this thought I just had
> >> today: the
> >>> RM
> >>>> doesn't really
> >>>>>>>> have to choose to do all 100 commands on a
> >> local
> >>> machine
> >>>> or with Ant
> >>>>>>>> scripts or do the first 40 via CI. The RM can
> >>> actually
> >>>> pick and choose
> >>>>>>>> commands to run on the CI server. The CI
> >> Jenkins
> >>> jobs
> >>>> are not a
> >>>>>>>> separate/alternative release process, they
> >> are just
> >>>> another way of
> >>>>>>>> executing the first 40 steps. Using CI jobs
> >>> actually
> >>>> requires
> >>>>>> additional
> >>>>>>>> command-line cut-and-paste to push commits on
> >> the CI
> >>>> server and to sign
> >>>>>> and
> >>>>>>>> validate binaries locally, but that's the
> >> trade-off
> >>> of
> >>>> not having to
> >>>>>>>> configure your machine to successfully run
> >> all of
> >>> the
> >>>> automated tests
> >>>>>> and
> >>>>>>>> build systems, and being able to run a
> >> command by
> >>> filling
> >>>> in the version
> >>>>>>>> number and rc number and hitting the "ok"
> >> button
> >>> instead
> >>>> of making sure
> >>>>>> you
> >>>>>>>> got the whole command typed in correctly.
> >>>>>>>>
> >>>>>>>> So, an RM can run the first 25 steps
> >> locally,
> >>> then go
> >>>> the CI server
> >>>>>>>> and run what is now Jenkins Job
> >>> "Royale_Release_Step_013"
> >>>> (no need to
> >>>>>> run
> >>>>>>>> the first 12) and it will run tasks 26
> >> through 32,
> >>> and if
> >>>> it is
> >>>>>> successful,
> >>>>>>>> then the RM has proven code coverage of the
> >>> build.xml
> >>>> files. (If the
> >>>>>>>> resulting tar.gz and zips are not posted,
> >> then the
> >>> RM
> >>>> should verify that
> >>>>>>>> they match the ones from Maven
> >> distribution). I
> >>> would
> >>>> encourage RMs to
> >>>>>>>> also use the CI jobs that generate the emails
> >> to
> >>> make
> >>>> sure the subject
> >>>>>> and
> >>>>>>>> content is correct and contains the usual
> >>> instructions so
> >>>> we have
> >>>>>>>> consistency. Maybe someday there will be CI
> >> jobs
> >>> to do
> >>>> the last 60+
> >>>>>> steps
> >>>>>>>> if that helps. We could add a Jenkins job
> >> that
> >>> runs an
> >>>> Ant build on RC
> >>>>>>>> artifacts on dist.a.o as well.
> >>>>>>>>
> >>>>>>>> I would like you all to help maintain the
> >> list of
> >>> 100
> >>>> steps and other
> >>>>>>>> documents related to the release process, and
> >>> improve the
> >>>> CI jobs and
> >>>>>> Ant
> >>>>>>>> steps if it helps you be a more efficient
> >> RM. I am
> >>>> hopeful that now
> >>>>>> that I
> >>>>>>>> have hopefully explained our release process
> >>> better, that
> >>>> we can see
> >>>>>> that
> >>>>>>>> these 100+ steps just have to be done in some
> >> way.
> >>> The
> >>>> RM can figure
> >>>>>> out
> >>>>>>>> what way works best for them, but they must
> >> get
> >>> through
> >>>> all of them.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> -Alex
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carlos Rovira
> >>>>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133509630&sdata=mPuTunrw%2FKFjgcCEgGFvH6bpRNl3dgmWqUmpEC2YNZE%3D&reserved=0
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Carlos Rovira
> >>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133519628&sdata=7IaQsmSHt%2FIV%2BkZpYrmUUWAbcOo1inElsdsjOLBdaeM%3D&reserved=0
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133519628&sdata=7IaQsmSHt%2FIV%2BkZpYrmUUWAbcOo1inElsdsjOLBdaeM%3D&reserved=0
> >>>
> >>>
> >>>
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133519628&sdata=7IaQsmSHt%2FIV%2BkZpYrmUUWAbcOo1inElsdsjOLBdaeM%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133519628&sdata=7IaQsmSHt%2FIV%2BkZpYrmUUWAbcOo1inElsdsjOLBdaeM%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc5d5ca6e49d47749dce08d7d7c68fd4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637215120133519628&sdata=7IaQsmSHt%2FIV%2BkZpYrmUUWAbcOo1inElsdsjOLBdaeM%3D&reserved=0
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
for me ok. My point is just that Alex, Yishay and you (and any other want)
that thinks all that is needed want to go with that steps, it's totally ok.
Other like me will want just the simpler method since don't see a reason to
do in other way. At the end, this is open source and while the release is
ok, it should be ok for all of us.
Just please, don't try to impose complex methods to the rest. Ant build
will be ensure that is working properly as well as Maven.
Each RM must try different methods and see how works better for him, since
I'm sure both will be equally valid, since this is the ASF and the rules
are clear.
For me I just want to have that point clear, and we can stop this
discussion and let Yishay do its work on release.
As well, if you all think it can be last many time, maybe would be good for
our users that I do 0.9.7 and then Yishay go within a month with 0.9.8 and
you then in other month with 0.9.9. People is waiting for us. Just a
suggestion from my part. That probably will give you time to improve that
100 commands process.
Thanks!
El vie., 3 abr. 2020 a las 11:37, Harbs (<ha...@gmail.com>) escribió:
> Why don’t we hold off on discussing this until Yishay and I have both gone
> through a release process?
>
> I’m sure the necessity (or lack thereof) will become clear to us once
> we’ve done it.
>
> > On Apr 3, 2020, at 11:23 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > trying to summarize again with this plan seems to me unnecessary, in a
> way
> > that maybe until now nobody exposed and could be the key to understand
> the
> > problem:
> >
> > if we ask ourselves: "Are we generating the same artifacts between build
> > systems at bit level?", the response is "No". They should be mostly the
> > same for an user to work with it, but after working on a release it was
> > clear to me that each build system has its own "idiosyncrasy" (to say it
> > some way), since we us to have files like metainfs, xmls, or other things
> > that are not generated the same way.
> >
> > "are we creating reproducible builds?". "No". Since the compiler is not
> > prepared for it. Due to differences in OS (and possibly JDK Vendor) the
> > order generated in some files is different (as already exposed many days
> > ago). So reproducible builds in 0.9.6 are not real. "what needs to be
> made
> > to have reproducible builds?". "Fix the compiler is needed to implement
> > it".
> >
> > Far beyond, "If we fix the compiler to have real reproducible builds will
> > we have reproducible builds between build systems?". "No, will be only
> > reproducible from a concrete build system perspective". So builds for Ant
> > are reproducible for Ant, and builds done with Maven are reproducible
> with
> > Maven, but are not comparable between them due to latest point, each
> build
> > system generate slightly different artifacts. Checking jars for binary
> > equality will fail (just opening with a tool like intellij will show you
> > the problem easily).
> >
> > (subsection: since reproducibility seems more work we can left for post
> > 1.0.0)
> >
> > So "if you make a release using one build system have sense to mix with
> > other build system during the release?", "No, since as we are creating
> > different artifacts, just running a full build, when release is done, to
> > test the rest of build systems are working is enough to check it". Or "it
> > no has sense to do release steps for all build systems since we just need
> > to push one set of artifacts and we are really not checking any relation
> > between them since are different things at byte level although can work
> the
> > same for an user"
> >
> > If the problem is to save time to the rest of people verifying the
> release,
> > the RM can do a full build with *all* build systems to check the
> integrity
> > and that build systems are working as we all expect, so RCs are in the
> same
> > state as running the 100 steps. That will far easy and quick than doing
> 100
> > commands that really are not performing what we expect from what I
> > explained here.
> >
> > In resume, both ways are the same, since reproducible builds are only
> > affecting to the build system from what you're building and the so-called
> > "reproducible artifacts" and not "comparable" with same artifacts
> generated
> > by other build systems, so artifacts done with different systems are
> > essentially (bit level) not equal).
> >
> > If after all the evidences exposed here, you still insists in impose a
> 100
> > command recipe, I honestly will not understand.
> >
> > In exchange, if you (or other) feels better doing 100 commands when
> acting
> > as RM, is completely up to you, while don't try to impose to the rest of
> > the project.
> >
> > HTH
> >
> > Thanks
> >
> > Carlos
> >
> >
> >
> >
> >
> > El vie., 3 abr. 2020 a las 6:35, Alex Harui (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> I honestly can't think of any steps we can do without. If you can
> explain
> >> technically why some step isn't needed, then we can discuss it. I'm
> sorry
> >> you don't agree. I hope the rest of the PMC will agree that we have to
> do
> >> all of these steps and support the RM in doing so.
> >>
> >> One way to not have to actually type 90+ command is to use the Ant steps
> >> or CI jobs. Ideas on how to do less typing to execute these 90+
> commands
> >> are welcome.
> >>
> >> -Alex
> >>
> >> On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >>
> >> Hi Alex,
> >>
> >> sincerely, I don't understand that, and was not what I understand for
> >> your
> >> first email. I must say that I completely disagree that we need to do
> >> 90 or
> >> 100 commands to get a release that should be around 15. I think we
> >> have a
> >> problem with what we really need here.
> >>
> >> Maybe the solution is to get some external mediator that have a good
> >> experience with multiple build systems and releases and could give us
> >> his
> >> opinion from outside, so we can have the most logic option. I think
> if
> >> we
> >> can get someone that could give a hand could be very good for us.
> >>
> >> Can we ask in Apache for someone that review it? Maybe this will be
> the
> >> only solution to avoid going in circles again, since I'm afraid that
> my
> >> response will not be what you expect, but sorry, don't see this as
> you.
> >>
> >> I think this shouldn't be a requirement to all RMs, so people that
> >> wants to
> >> do all that commands can do it, but I sincerely prefer to stick with
> >> the
> >> recipe that is the current standard in all projects (even the ones
> that
> >> have more than one build systems). Take for sure that if I see a need
> >> to do
> >> all of that I'll be glad to do it. But sincerily is something I don't
> >> share.
> >>
> >> Anyway for people that wants to do that kind of checking I think you
> >> get a
> >> good advance from the previous solution.
> >>
> >> Thanks
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> El jue., 2 abr. 2020 a las 21:50, Alex Harui
> (<aharui@adobe.com.invalid
> >>> )
> >> escribió:
> >>
> >>> Hi Carlos,
> >>>
> >>> The command lines in [1] have been added to [2]. [1] is only a
> >> partial
> >>> list of the things to do, but includes some helpful setup information
> >>> Hopefully in June we won't need to release build-tools so you will
> >> only
> >>> have about 90 steps to do, but we may have added more commands as we
> >>> improve our automated test infrastructure.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> [2]
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> >>>
> >>> On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org>
> >> wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> to understand your long email. Lets say that when I'll go to
> >> release in
> >>> June (0.9.9), I'll use instructions described in [1].
> >>> So that will create the sources needed to post. Then, to avouid
> >> later
> >>> problems for people verifying I'll verify it with Maven and Ant
> >> (build
> >>> with
> >>> both, and test SDK generated in example apps. Then push to
> >> dist.a.o,
> >>> create
> >>> discuss and vote threads, and start the vote.
> >>>
> >>> Is that ok?
> >>>
> >>> Thanks
> >>>
> >>> [1]
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=IBIgHvzutG7YtH27kxyD5tyaQyjBe6QetVWWsrSxF9w%3D&reserved=0
> >>>
> >>> El jue., 2 abr. 2020 a las 19:16, Alex Harui
> >> (<aharui@adobe.com.invalid
> >>>> )
> >>> escribió:
> >>>
> >>>> I'm not sure I understand the distinction. I think we want to
> >> do
> >>> both.
> >>>> The goal of code coverage is to try to exercise paths. We
> >> want to
> >>> run "ant
> >>>> release" because our Ant users might want to do that. And Ant
> >> does
> >>> have
> >>>> assertions AFAICT. It will report errors. Meanwhile, the
> >> standard
> >>> for
> >>>> the .tar.gz package is the one produced by "ant release"
> >> because
> >>> that's the
> >>>> recipe we've been using for years now. The Maven
> >> distribution's
> >>> .tar.gz
> >>>> has been shown to work in most cases, but AFAICT, is nearly as
> >> well
> >>> tested
> >>>> and has not been binary-compared. Ways to compare the two
> >> .tar.gz
> >>> files
> >>>> are needed and welcome.
> >>>>
> >>>> More and better tests are welcome.
> >>>>
> >>>> Do we have agreement? It sounds like it. So I will now be
> >> spending
> >>> my
> >>>> evenings on the release instead of writing lists of 100 things.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com>
> >> wrote:
> >>>>
> >>>> Chris, I think you’re missing Alex’s point. We’re not
> >> running
> >>> Ant to
> >>>> make sure it doesn’t blow up. We’re running it to make sure the
> >>> resultant
> >>>> tar.gz/zip files are identical to the ones created by Maven.
> >> Alex,
> >>> please
> >>>> correct me if I’m wrong.
> >>>>
> >>>> ________________________________
> >>>> From: Christofer Dutz <ch...@c-ware.de>
> >>>> Sent: Thursday, April 2, 2020 4:42:00 PM
> >>>> To: dev@royale.apache.org <de...@royale.apache.org>
> >>>> Subject: Re: Royale Releases
> >>>>
> >>>> And to add a little to that [1]
> >>>>
> >>>> "In computer science, test coverage is a measure used to
> >>> describe the
> >>>> degree to which the source code of a program is executed when a
> >>> particular
> >>>> test suite runs."
> >>>>
> >>>> So no test, no coverage. Just using something and it's not
> >>> blowing up
> >>>> isn't a test for me. It's better than nothing however.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=ohLzW9qtDjCrsy8mHX47Z2qkWR4me5giS%2BSEGSUSWKQ%3D&reserved=0
> >>>>
> >>>> Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> >>>> christofer.dutz@c-ware.de>:
> >>>>
> >>>> Hi folks,
> >>>>
> >>>> I would say we have coverage for both maven ant
> >> equally as
> >>> we're
> >>>> building the same code.
> >>>>
> >>>> However we are missing the important assertions. It's
> >> not
> >>> that the
> >>>> Ant build is running some tests Maven isn't.
> >>>> It's just that the settings for Ant seem to be
> >> different
> >>> than for
> >>>> Maven and the Ant ones happen to work.
> >>>>
> >>>> Ideally there would be real tests that test the output
> >> of
> >>> both to
> >>>> see if it works in both cases.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> Am 02.04.20, 15:15 schrieb "Harbs" <
> >> harbs.lists@gmail.com>:
> >>>>
> >>>> Adding more coverage for Maven is good.
> >>>>
> >>>> Removing coverage for Ant is not.
> >>>>
> >>>> Do you agree?
> >>>>
> >>>>> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> >>>> carlosrovira@apache.org> wrote:
> >>>>>
> >>>>> Hi Harbs,
> >>>>>
> >>>>> I think what we're trying to say is that until
> >> now we
> >>>> released with Maven
> >>>>> and Ant, and that was hiding a flaw in Maven (SVG
> >>> example).
> >>>> So that means
> >>>>> what we were trying to cover was not covered
> >> clearly,
> >>> so the
> >>>> premise is not
> >>>>> right.
> >>>>>
> >>>>>
> >>>>>
> >>>>> El jue., 2 abr. 2020 a las 14:56, Harbs (<
> >>>> harbs.lists@gmail.com>) escribió:
> >>>>>
> >>>>>> No one is arguing that we shouldn’t add more
> >> tests.
> >>>>>>
> >>>>>> Please let’s not make it seem like there’s a
> >>> disagreement
> >>>> about that.
> >>>>>>
> >>>>>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> >>>> carlosrovira@apache.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Alex,
> >>>>>>>
> >>>>>>> first, many thanks for the detailed email. I'll
> >>> comment on
> >>>> this later as
> >>>>>> I
> >>>>>>> have more time.
> >>>>>>>
> >>>>>>> For now, to add up a recent example on what
> >> Chris
> >>>> commented: If you all
> >>>>>>> remember a week ago I was trying to use SVG
> >> Images
> >>> in a
> >>>> blog example that
> >>>>>>> was published 2 days ago. Nobody tried SVG
> >> Images
> >>> before
> >>>> building with
> >>>>>>> maven, I know that since maven was not properly
> >>> configured
> >>>> and using that
> >>>>>>> component from Maven was failing with an RTE.
> >>> Probably we
> >>>> have more
> >>>>>> things
> >>>>>>> not working the same way when build from Maven
> >> and
> >>> Ant,
> >>>> and that's
> >>>>>>> something that will need people using that code
> >>> paths in
> >>>> test
> >>>>>> applications
> >>>>>>> (or in their own apps) to see if things works
> >>> properly.
> >>>>>>>
> >>>>>>> I was recently introduced to
> >>> "examples-integrationtest" by
> >>>> Chris, that I
> >>>>>>> plan to use soon as I can. I think is a great
> >> idea,
> >>> since
> >>>> you get a
> >>>>>> Firefox
> >>>>>>> running test interface of the real use of some
> >>> concrete
> >>>> royale code. I
> >>>>>>> think passed until now unnoticed by all of us,
> >> and
> >>> seems a
> >>>> powerful tool.
> >>>>>>> There's already an example about FlexStore
> >> with some
> >>> basic
> >>>> assertions.
> >>>>>>>
> >>>>>>> Again, thanks, and will comment on the rest
> >> later
> >>>>>>>
> >>>>>>> Carlos
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> El jue., 2 abr. 2020 a las 9:20, Christofer
> >> Dutz (<
> >>>>>> christofer.dutz@c-ware.de>)
> >>>>>>> escribió:
> >>>>>>>
> >>>>>>>> Hi Alex,
> >>>>>>>>
> >>>>>>>> just a point you are bringing up: "Code
> >> coverage".
> >>>>>>>>
> >>>>>>>> I strongly dislike the idea of "asjs"
> >> effectively
> >>> being
> >>>> the test for the
> >>>>>>>> compiler. The reasoning behind this is: yes
> >> you do
> >>> get
> >>>> more code
> >>>>>> covered,
> >>>>>>>> but only the happy-path (ideally) and even if
> >>> things go
> >>>> wrong, the end
> >>>>>>>> results aren't tested. Did add a module to
> >> asjs
> >>> years ago
> >>>>>>>> ("examples-integrationtest") that deployed the
> >>> examples
> >>>> in a tomcat
> >>>>>> server
> >>>>>>>> then opens a Firefox browser and clicks
> >> through 2
> >>> of the
> >>>> examples (I
> >>>>>> added
> >>>>>>>> two dummy tests as an example, but seems no
> >> one
> >>> touched
> >>>> this after me).
> >>>>>> I
> >>>>>>>> did this because I remember us working on
> >> asjs for
> >>> weeks
> >>>> without anyone
> >>>>>>>> noticing the compiler wasn't producing
> >> runnable
> >>> code ...
> >>>> same with the
> >>>>>>>> little unit-tests that are still run for every
> >>> example,
> >>>> that simply
> >>>>>> check
> >>>>>>>> if an output is generated, because we had a
> >>> prolonged
> >>>> period of time
> >>>>>> where
> >>>>>>>> we were all working on different parts, but
> >> for
> >>> quite
> >>>> some time the
> >>>>>>>> application compilation just didn't output
> >> anything
> >>> and
> >>>> no one noticed.
> >>>>>>>>
> >>>>>>>> So coverage is nothing without assertions (my
> >>> opinion)
> >>>> ... ok ... it's
> >>>>>>>> slightly better than no coverage, but not
> >> much, in
> >>> my
> >>>> opinion.
> >>>>>>>>
> >>>>>>>> I think in parallel to this release
> >> discussions I
> >>> have
> >>>> seen numerous
> >>>>>>>> threads about someone doing something that
> >> broke
> >>>> something for someone
> >>>>>>>> else. This could be addressed by increasing
> >>> coverage by
> >>>> providing
> >>>>>> explicit
> >>>>>>>> tests.
> >>>>>>>>
> >>>>>>>> Coming back to the releases:
> >>>>>>>> I have no objections, if you do a "release"
> >> locally
> >>> and
> >>>> automate the
> >>>>>>>> validation on the CI server (Which effectively
> >>> would be
> >>>> your proposal
> >>>>>> to do
> >>>>>>>> the first 12 steps on local hardware and the
> >> 13th
> >>> on the
> >>>> CI server). I
> >>>>>> even
> >>>>>>>> think that's a good idea ... There could be
> >> one
> >>> step for
> >>>> building a
> >>>>>> release
> >>>>>>>> from a given "git tag" for every build system
> >> and
> >>> generic
> >>>> means to
> >>>>>> compare
> >>>>>>>> tar.gz and zips produced by any build system
> >> with
> >>> that of
> >>>> another
> >>>>>> (ideally
> >>>>>>>> with better output than just a plain
> >> "true/false").
> >>> This
> >>>> would even
> >>>>>> help to
> >>>>>>>> iron out the last potentially existing bumps
> >> out of
> >>> the
> >>>> Maven
> >>>>>> distribution.
> >>>>>>>>
> >>>>>>>> Chris
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> >>>> <ah...@adobe.com.INVALID>:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> This is my attempt to explain what goes
> >> into a
> >>> release
> >>>> in hopes that
> >>>>>>>> we can understand and agree on what our
> >> release
> >>> process
> >>>> is. It became
> >>>>>>>> apparent in my reading of the wiki page with
> >> the new
> >>>> Maven steps and in
> >>>>>>>> talking with Harbs today that there are still
> >> many
> >>>> misunderstandings
> >>>>>> about
> >>>>>>>> what we do to create a release. I don't
> >> generally
> >>> like
> >>>> writing
> >>>>>>>> instructions in English because it is easy to
> >> be
> >>>> ambiguous. All of the
> >>>>>>>> steps that we use to create releases had been
> >>> captured in
> >>>> Ant scripts
> >>>>>> in a
> >>>>>>>> much more explicit way, IMO, but I took the
> >> time to
> >>> write
> >>>> them down in
> >>>>>>>> English here:
> >>>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> >>>>>>>>
> >>>>>>>> I did this quickly by scanning the CI
> >> steps, the
> >>> new
> >>>> Maven steps and
> >>>>>>>> the Ant scripts used in prior releases so
> >> there
> >>> could
> >>>> certainly be
> >>>>>> mistakes
> >>>>>>>> and missed steps. If I did my math right,
> >> the RM
> >>> for
> >>>> 0.9.7 will have to
> >>>>>>>> complete over 100 tasks (essentially, typing a
> >>>> command-line 100 times).
> >>>>>>>> Future RMs, when we don't have to release
> >>> build-tools,
> >>>> will have about
> >>>>>> 92
> >>>>>>>> steps. And I did not include voter
> >> verification
> >>> checks
> >>>> the RM should
> >>>>>> run
> >>>>>>>> before opening a vote (verifying that the
> >> artifacts
> >>>> download and match
> >>>>>>>> their checksums, etc). As an RM, I run a
> >> bunch of
> >>> tests
> >>>> on the RC
> >>>>>> before
> >>>>>>>> sending out the vote. Maybe we should add
> >> those to
> >>> the
> >>>> task list.
> >>>>>>>>
> >>>>>>>> I think there has been confusion about the
> >> use of
> >>> Ant
> >>>> in the release
> >>>>>>>> process. Because I was the RM for the first
> >> set of
> >>>> FlexJS/Royale
> >>>>>> releases,
> >>>>>>>> and I'm a lazy person who hates typing at the
> >>> command
> >>>> line, I created
> >>>>>> Ant
> >>>>>>>> scripts to execute these 100 steps. But I
> >> agree
> >>> that it
> >>>> is not a
> >>>>>>>> requirement that other RMs must use the Ant
> >> scripts
> >>> for
> >>>> these
> >>>>>> commands. If
> >>>>>>>> you are the RM and like typing, go ahead.
> >>>>>>>>
> >>>>>>>> Then we found out that other people
> >> couldn't get
> >>>> through this task
> >>>>>>>> list. I think the 3 people who tried were
> >> having
> >>> trouble
> >>>> with Maven
> >>>>>>>> uploads and downloads. So what I did was put
> >> the
> >>> first
> >>>> 40 steps or so
> >>>>>> into
> >>>>>>>> Jenkins jobs. And by doing that, Piotr was
> >> able to
> >>>> produce our last
> >>>>>>>> release. And that also saves on manually
> >> typing
> >>>> commands. But again,
> >>>>>>>> going forward, the RM gets to choose how they
> >> want
> >>> to
> >>>> execute these
> >>>>>> steps.
> >>>>>>>>
> >>>>>>>> If you scan the set of steps, you'll see
> >> that
> >>> "ant" is
> >>>> only in there
> >>>>>>>> once. I believe the recent threads have been
> >> about
> >>> this
> >>>> single command
> >>>>>> out
> >>>>>>>> of the 100+ commands. This is why this has
> >> been so
> >>>> frustrating to me.
> >>>>>> I
> >>>>>>>> believe there is a solid technical reason for
> >> that
> >>> one
> >>>> command: it
> >>>>>> proves
> >>>>>>>> that the build.xml files in the source
> >> packages can
> >>> build
> >>>> the .tar.gz
> >>>>>> that
> >>>>>>>> are useful to NPM and IDE users who use Ant
> >> and
> >>> want to
> >>>> test a change.
> >>>>>>>>
> >>>>>>>> I think of it as code-coverage. If we had
> >>>> code-coverage tools, we
> >>>>>>>> would ask that the RM complete as much of the
> >>> automated
> >>>> code-coverage
> >>>>>>>> testing as possible before posting the
> >> release for a
> >>>> vote. That one
> >>>>>>>> command increases our code coverage by
> >> running the
> >>>> build.xml files. We
> >>>>>>>> should be always working to increase
> >> automated code
> >>>> coverage in the RC.
> >>>>>>>> Certainly for me as RM, I will gladly watch
> >> TV as
> >>> the
> >>>> automated tests
> >>>>>> run
> >>>>>>>> because a failed RC means going back through
> >> many
> >>> of the
> >>>> first 25
> >>>>>> commands
> >>>>>>>> again and wastes other people's time. Each
> >> RC is
> >>> more
> >>>> emails to read
> >>>>>> and
> >>>>>>>> more time from the voters and testers.
> >>>>>>>>
> >>>>>>>> If there are other ways for the RM to get
> >> the
> >>> same or
> >>>> better code
> >>>>>>>> coverage on the build.xml files before
> >> posting the
> >>> RC, we
> >>>> can discuss
> >>>>>> those
> >>>>>>>> options.
> >>>>>>>>
> >>>>>>>> I am hopeful we can all agree on these
> >> simple
> >>>> principles: Strive for
> >>>>>>>> better code coverage and fewer failed RCs.
> >>> Royale's main
> >>>> purpose is to
> >>>>>>>> save other people time. Let's do that in
> >> creating
> >>>> releases too.
> >>>>>>>>
> >>>>>>>> One issue that was brought up recently was
> >>> whether it
> >>>> is a good
> >>>>>>>> decision to have the RM test all of the build
> >>> platforms
> >>>> we support.
> >>>>>>>> Suppose we add some other build system
> >> support or
> >>> more in
> >>>> the future?
> >>>>>>>> Again, the code coverage principle applies
> >> here, but
> >>>> also, I would like
> >>>>>> us
> >>>>>>>> to retain feature parity, and I also hope for
> >> as
> >>> few RCs
> >>>> and votes as
> >>>>>>>> possible. So instead of having separate
> >>>> votes/features/release-dates
> >>>>>> for
> >>>>>>>> the Maven artifacts vs the Ant artifacts vs
> >> the
> >>>> SomeFutureBuildTech
> >>>>>>>> artifacts, I think we should have one vote
> >> and keep
> >>> them
> >>>> all in sync.
> >>>>>> If
> >>>>>>>> we do ever get around to monthly or bi-monthly
> >>> releases,
> >>>> I think
> >>>>>> separate
> >>>>>>>> build platform releases would be too much
> >> work.
> >>>>>>>>
> >>>>>>>> But consider this thought I just had
> >> today: the
> >>> RM
> >>>> doesn't really
> >>>>>>>> have to choose to do all 100 commands on a
> >> local
> >>> machine
> >>>> or with Ant
> >>>>>>>> scripts or do the first 40 via CI. The RM can
> >>> actually
> >>>> pick and choose
> >>>>>>>> commands to run on the CI server. The CI
> >> Jenkins
> >>> jobs
> >>>> are not a
> >>>>>>>> separate/alternative release process, they
> >> are just
> >>>> another way of
> >>>>>>>> executing the first 40 steps. Using CI jobs
> >>> actually
> >>>> requires
> >>>>>> additional
> >>>>>>>> command-line cut-and-paste to push commits on
> >> the CI
> >>>> server and to sign
> >>>>>> and
> >>>>>>>> validate binaries locally, but that's the
> >> trade-off
> >>> of
> >>>> not having to
> >>>>>>>> configure your machine to successfully run
> >> all of
> >>> the
> >>>> automated tests
> >>>>>> and
> >>>>>>>> build systems, and being able to run a
> >> command by
> >>> filling
> >>>> in the version
> >>>>>>>> number and rc number and hitting the "ok"
> >> button
> >>> instead
> >>>> of making sure
> >>>>>> you
> >>>>>>>> got the whole command typed in correctly.
> >>>>>>>>
> >>>>>>>> So, an RM can run the first 25 steps
> >> locally,
> >>> then go
> >>>> the CI server
> >>>>>>>> and run what is now Jenkins Job
> >>> "Royale_Release_Step_013"
> >>>> (no need to
> >>>>>> run
> >>>>>>>> the first 12) and it will run tasks 26
> >> through 32,
> >>> and if
> >>>> it is
> >>>>>> successful,
> >>>>>>>> then the RM has proven code coverage of the
> >>> build.xml
> >>>> files. (If the
> >>>>>>>> resulting tar.gz and zips are not posted,
> >> then the
> >>> RM
> >>>> should verify that
> >>>>>>>> they match the ones from Maven
> >> distribution). I
> >>> would
> >>>> encourage RMs to
> >>>>>>>> also use the CI jobs that generate the emails
> >> to
> >>> make
> >>>> sure the subject
> >>>>>> and
> >>>>>>>> content is correct and contains the usual
> >>> instructions so
> >>>> we have
> >>>>>>>> consistency. Maybe someday there will be CI
> >> jobs
> >>> to do
> >>>> the last 60+
> >>>>>> steps
> >>>>>>>> if that helps. We could add a Jenkins job
> >> that
> >>> runs an
> >>>> Ant build on RC
> >>>>>>>> artifacts on dist.a.o as well.
> >>>>>>>>
> >>>>>>>> I would like you all to help maintain the
> >> list of
> >>> 100
> >>>> steps and other
> >>>>>>>> documents related to the release process, and
> >>> improve the
> >>>> CI jobs and
> >>>>>> Ant
> >>>>>>>> steps if it helps you be a more efficient
> >> RM. I am
> >>>> hopeful that now
> >>>>>> that I
> >>>>>>>> have hopefully explained our release process
> >>> better, that
> >>>> we can see
> >>>>>> that
> >>>>>>>> these 100+ steps just have to be done in some
> >> way.
> >>> The
> >>>> RM can figure
> >>>>>> out
> >>>>>>>> what way works best for them, but they must
> >> get
> >>> through
> >>>> all of them.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> -Alex
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carlos Rovira
> >>>>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Carlos Rovira
> >>>>>
> >>>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >>>
> >>>
> >>>
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Harbs <ha...@gmail.com>.
Why don’t we hold off on discussing this until Yishay and I have both gone through a release process?
I’m sure the necessity (or lack thereof) will become clear to us once we’ve done it.
> On Apr 3, 2020, at 11:23 AM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Alex,
>
> trying to summarize again with this plan seems to me unnecessary, in a way
> that maybe until now nobody exposed and could be the key to understand the
> problem:
>
> if we ask ourselves: "Are we generating the same artifacts between build
> systems at bit level?", the response is "No". They should be mostly the
> same for an user to work with it, but after working on a release it was
> clear to me that each build system has its own "idiosyncrasy" (to say it
> some way), since we us to have files like metainfs, xmls, or other things
> that are not generated the same way.
>
> "are we creating reproducible builds?". "No". Since the compiler is not
> prepared for it. Due to differences in OS (and possibly JDK Vendor) the
> order generated in some files is different (as already exposed many days
> ago). So reproducible builds in 0.9.6 are not real. "what needs to be made
> to have reproducible builds?". "Fix the compiler is needed to implement
> it".
>
> Far beyond, "If we fix the compiler to have real reproducible builds will
> we have reproducible builds between build systems?". "No, will be only
> reproducible from a concrete build system perspective". So builds for Ant
> are reproducible for Ant, and builds done with Maven are reproducible with
> Maven, but are not comparable between them due to latest point, each build
> system generate slightly different artifacts. Checking jars for binary
> equality will fail (just opening with a tool like intellij will show you
> the problem easily).
>
> (subsection: since reproducibility seems more work we can left for post
> 1.0.0)
>
> So "if you make a release using one build system have sense to mix with
> other build system during the release?", "No, since as we are creating
> different artifacts, just running a full build, when release is done, to
> test the rest of build systems are working is enough to check it". Or "it
> no has sense to do release steps for all build systems since we just need
> to push one set of artifacts and we are really not checking any relation
> between them since are different things at byte level although can work the
> same for an user"
>
> If the problem is to save time to the rest of people verifying the release,
> the RM can do a full build with *all* build systems to check the integrity
> and that build systems are working as we all expect, so RCs are in the same
> state as running the 100 steps. That will far easy and quick than doing 100
> commands that really are not performing what we expect from what I
> explained here.
>
> In resume, both ways are the same, since reproducible builds are only
> affecting to the build system from what you're building and the so-called
> "reproducible artifacts" and not "comparable" with same artifacts generated
> by other build systems, so artifacts done with different systems are
> essentially (bit level) not equal).
>
> If after all the evidences exposed here, you still insists in impose a 100
> command recipe, I honestly will not understand.
>
> In exchange, if you (or other) feels better doing 100 commands when acting
> as RM, is completely up to you, while don't try to impose to the rest of
> the project.
>
> HTH
>
> Thanks
>
> Carlos
>
>
>
>
>
> El vie., 3 abr. 2020 a las 6:35, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> I honestly can't think of any steps we can do without. If you can explain
>> technically why some step isn't needed, then we can discuss it. I'm sorry
>> you don't agree. I hope the rest of the PMC will agree that we have to do
>> all of these steps and support the RM in doing so.
>>
>> One way to not have to actually type 90+ command is to use the Ant steps
>> or CI jobs. Ideas on how to do less typing to execute these 90+ commands
>> are welcome.
>>
>> -Alex
>>
>> On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> sincerely, I don't understand that, and was not what I understand for
>> your
>> first email. I must say that I completely disagree that we need to do
>> 90 or
>> 100 commands to get a release that should be around 15. I think we
>> have a
>> problem with what we really need here.
>>
>> Maybe the solution is to get some external mediator that have a good
>> experience with multiple build systems and releases and could give us
>> his
>> opinion from outside, so we can have the most logic option. I think if
>> we
>> can get someone that could give a hand could be very good for us.
>>
>> Can we ask in Apache for someone that review it? Maybe this will be the
>> only solution to avoid going in circles again, since I'm afraid that my
>> response will not be what you expect, but sorry, don't see this as you.
>>
>> I think this shouldn't be a requirement to all RMs, so people that
>> wants to
>> do all that commands can do it, but I sincerely prefer to stick with
>> the
>> recipe that is the current standard in all projects (even the ones that
>> have more than one build systems). Take for sure that if I see a need
>> to do
>> all of that I'll be glad to do it. But sincerily is something I don't
>> share.
>>
>> Anyway for people that wants to do that kind of checking I think you
>> get a
>> good advance from the previous solution.
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>> El jue., 2 abr. 2020 a las 21:50, Alex Harui (<aharui@adobe.com.invalid
>>> )
>> escribió:
>>
>>> Hi Carlos,
>>>
>>> The command lines in [1] have been added to [2]. [1] is only a
>> partial
>>> list of the things to do, but includes some helpful setup information
>>> Hopefully in June we won't need to release build-tools so you will
>> only
>>> have about 90 steps to do, but we may have added more commands as we
>>> improve our automated test infrastructure.
>>>
>>> HTH,
>>> -Alex
>>>
>>> [2]
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
>>>
>>> On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> to understand your long email. Lets say that when I'll go to
>> release in
>>> June (0.9.9), I'll use instructions described in [1].
>>> So that will create the sources needed to post. Then, to avouid
>> later
>>> problems for people verifying I'll verify it with Maven and Ant
>> (build
>>> with
>>> both, and test SDK generated in example apps. Then push to
>> dist.a.o,
>>> create
>>> discuss and vote threads, and start the vote.
>>>
>>> Is that ok?
>>>
>>> Thanks
>>>
>>> [1]
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=IBIgHvzutG7YtH27kxyD5tyaQyjBe6QetVWWsrSxF9w%3D&reserved=0
>>>
>>> El jue., 2 abr. 2020 a las 19:16, Alex Harui
>> (<aharui@adobe.com.invalid
>>>> )
>>> escribió:
>>>
>>>> I'm not sure I understand the distinction. I think we want to
>> do
>>> both.
>>>> The goal of code coverage is to try to exercise paths. We
>> want to
>>> run "ant
>>>> release" because our Ant users might want to do that. And Ant
>> does
>>> have
>>>> assertions AFAICT. It will report errors. Meanwhile, the
>> standard
>>> for
>>>> the .tar.gz package is the one produced by "ant release"
>> because
>>> that's the
>>>> recipe we've been using for years now. The Maven
>> distribution's
>>> .tar.gz
>>>> has been shown to work in most cases, but AFAICT, is nearly as
>> well
>>> tested
>>>> and has not been binary-compared. Ways to compare the two
>> .tar.gz
>>> files
>>>> are needed and welcome.
>>>>
>>>> More and better tests are welcome.
>>>>
>>>> Do we have agreement? It sounds like it. So I will now be
>> spending
>>> my
>>>> evenings on the release instead of writing lists of 100 things.
>>>>
>>>> -Alex
>>>>
>>>> On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com>
>> wrote:
>>>>
>>>> Chris, I think you’re missing Alex’s point. We’re not
>> running
>>> Ant to
>>>> make sure it doesn’t blow up. We’re running it to make sure the
>>> resultant
>>>> tar.gz/zip files are identical to the ones created by Maven.
>> Alex,
>>> please
>>>> correct me if I’m wrong.
>>>>
>>>> ________________________________
>>>> From: Christofer Dutz <ch...@c-ware.de>
>>>> Sent: Thursday, April 2, 2020 4:42:00 PM
>>>> To: dev@royale.apache.org <de...@royale.apache.org>
>>>> Subject: Re: Royale Releases
>>>>
>>>> And to add a little to that [1]
>>>>
>>>> "In computer science, test coverage is a measure used to
>>> describe the
>>>> degree to which the source code of a program is executed when a
>>> particular
>>>> test suite runs."
>>>>
>>>> So no test, no coverage. Just using something and it's not
>>> blowing up
>>>> isn't a test for me. It's better than nothing however.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> [1]
>>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=ohLzW9qtDjCrsy8mHX47Z2qkWR4me5giS%2BSEGSUSWKQ%3D&reserved=0
>>>>
>>>> Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
>>>> christofer.dutz@c-ware.de>:
>>>>
>>>> Hi folks,
>>>>
>>>> I would say we have coverage for both maven ant
>> equally as
>>> we're
>>>> building the same code.
>>>>
>>>> However we are missing the important assertions. It's
>> not
>>> that the
>>>> Ant build is running some tests Maven isn't.
>>>> It's just that the settings for Ant seem to be
>> different
>>> than for
>>>> Maven and the Ant ones happen to work.
>>>>
>>>> Ideally there would be real tests that test the output
>> of
>>> both to
>>>> see if it works in both cases.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Am 02.04.20, 15:15 schrieb "Harbs" <
>> harbs.lists@gmail.com>:
>>>>
>>>> Adding more coverage for Maven is good.
>>>>
>>>> Removing coverage for Ant is not.
>>>>
>>>> Do you agree?
>>>>
>>>>> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
>>>> carlosrovira@apache.org> wrote:
>>>>>
>>>>> Hi Harbs,
>>>>>
>>>>> I think what we're trying to say is that until
>> now we
>>>> released with Maven
>>>>> and Ant, and that was hiding a flaw in Maven (SVG
>>> example).
>>>> So that means
>>>>> what we were trying to cover was not covered
>> clearly,
>>> so the
>>>> premise is not
>>>>> right.
>>>>>
>>>>>
>>>>>
>>>>> El jue., 2 abr. 2020 a las 14:56, Harbs (<
>>>> harbs.lists@gmail.com>) escribió:
>>>>>
>>>>>> No one is arguing that we shouldn’t add more
>> tests.
>>>>>>
>>>>>> Please let’s not make it seem like there’s a
>>> disagreement
>>>> about that.
>>>>>>
>>>>>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
>>>> carlosrovira@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> first, many thanks for the detailed email. I'll
>>> comment on
>>>> this later as
>>>>>> I
>>>>>>> have more time.
>>>>>>>
>>>>>>> For now, to add up a recent example on what
>> Chris
>>>> commented: If you all
>>>>>>> remember a week ago I was trying to use SVG
>> Images
>>> in a
>>>> blog example that
>>>>>>> was published 2 days ago. Nobody tried SVG
>> Images
>>> before
>>>> building with
>>>>>>> maven, I know that since maven was not properly
>>> configured
>>>> and using that
>>>>>>> component from Maven was failing with an RTE.
>>> Probably we
>>>> have more
>>>>>> things
>>>>>>> not working the same way when build from Maven
>> and
>>> Ant,
>>>> and that's
>>>>>>> something that will need people using that code
>>> paths in
>>>> test
>>>>>> applications
>>>>>>> (or in their own apps) to see if things works
>>> properly.
>>>>>>>
>>>>>>> I was recently introduced to
>>> "examples-integrationtest" by
>>>> Chris, that I
>>>>>>> plan to use soon as I can. I think is a great
>> idea,
>>> since
>>>> you get a
>>>>>> Firefox
>>>>>>> running test interface of the real use of some
>>> concrete
>>>> royale code. I
>>>>>>> think passed until now unnoticed by all of us,
>> and
>>> seems a
>>>> powerful tool.
>>>>>>> There's already an example about FlexStore
>> with some
>>> basic
>>>> assertions.
>>>>>>>
>>>>>>> Again, thanks, and will comment on the rest
>> later
>>>>>>>
>>>>>>> Carlos
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El jue., 2 abr. 2020 a las 9:20, Christofer
>> Dutz (<
>>>>>> christofer.dutz@c-ware.de>)
>>>>>>> escribió:
>>>>>>>
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> just a point you are bringing up: "Code
>> coverage".
>>>>>>>>
>>>>>>>> I strongly dislike the idea of "asjs"
>> effectively
>>> being
>>>> the test for the
>>>>>>>> compiler. The reasoning behind this is: yes
>> you do
>>> get
>>>> more code
>>>>>> covered,
>>>>>>>> but only the happy-path (ideally) and even if
>>> things go
>>>> wrong, the end
>>>>>>>> results aren't tested. Did add a module to
>> asjs
>>> years ago
>>>>>>>> ("examples-integrationtest") that deployed the
>>> examples
>>>> in a tomcat
>>>>>> server
>>>>>>>> then opens a Firefox browser and clicks
>> through 2
>>> of the
>>>> examples (I
>>>>>> added
>>>>>>>> two dummy tests as an example, but seems no
>> one
>>> touched
>>>> this after me).
>>>>>> I
>>>>>>>> did this because I remember us working on
>> asjs for
>>> weeks
>>>> without anyone
>>>>>>>> noticing the compiler wasn't producing
>> runnable
>>> code ...
>>>> same with the
>>>>>>>> little unit-tests that are still run for every
>>> example,
>>>> that simply
>>>>>> check
>>>>>>>> if an output is generated, because we had a
>>> prolonged
>>>> period of time
>>>>>> where
>>>>>>>> we were all working on different parts, but
>> for
>>> quite
>>>> some time the
>>>>>>>> application compilation just didn't output
>> anything
>>> and
>>>> no one noticed.
>>>>>>>>
>>>>>>>> So coverage is nothing without assertions (my
>>> opinion)
>>>> ... ok ... it's
>>>>>>>> slightly better than no coverage, but not
>> much, in
>>> my
>>>> opinion.
>>>>>>>>
>>>>>>>> I think in parallel to this release
>> discussions I
>>> have
>>>> seen numerous
>>>>>>>> threads about someone doing something that
>> broke
>>>> something for someone
>>>>>>>> else. This could be addressed by increasing
>>> coverage by
>>>> providing
>>>>>> explicit
>>>>>>>> tests.
>>>>>>>>
>>>>>>>> Coming back to the releases:
>>>>>>>> I have no objections, if you do a "release"
>> locally
>>> and
>>>> automate the
>>>>>>>> validation on the CI server (Which effectively
>>> would be
>>>> your proposal
>>>>>> to do
>>>>>>>> the first 12 steps on local hardware and the
>> 13th
>>> on the
>>>> CI server). I
>>>>>> even
>>>>>>>> think that's a good idea ... There could be
>> one
>>> step for
>>>> building a
>>>>>> release
>>>>>>>> from a given "git tag" for every build system
>> and
>>> generic
>>>> means to
>>>>>> compare
>>>>>>>> tar.gz and zips produced by any build system
>> with
>>> that of
>>>> another
>>>>>> (ideally
>>>>>>>> with better output than just a plain
>> "true/false").
>>> This
>>>> would even
>>>>>> help to
>>>>>>>> iron out the last potentially existing bumps
>> out of
>>> the
>>>> Maven
>>>>>> distribution.
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
>>>> <ah...@adobe.com.INVALID>:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This is my attempt to explain what goes
>> into a
>>> release
>>>> in hopes that
>>>>>>>> we can understand and agree on what our
>> release
>>> process
>>>> is. It became
>>>>>>>> apparent in my reading of the wiki page with
>> the new
>>>> Maven steps and in
>>>>>>>> talking with Harbs today that there are still
>> many
>>>> misunderstandings
>>>>>> about
>>>>>>>> what we do to create a release. I don't
>> generally
>>> like
>>>> writing
>>>>>>>> instructions in English because it is easy to
>> be
>>>> ambiguous. All of the
>>>>>>>> steps that we use to create releases had been
>>> captured in
>>>> Ant scripts
>>>>>> in a
>>>>>>>> much more explicit way, IMO, but I took the
>> time to
>>> write
>>>> them down in
>>>>>>>> English here:
>>>>>>>>
>>>>>>
>>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
>>>>>>>>
>>>>>>>> I did this quickly by scanning the CI
>> steps, the
>>> new
>>>> Maven steps and
>>>>>>>> the Ant scripts used in prior releases so
>> there
>>> could
>>>> certainly be
>>>>>> mistakes
>>>>>>>> and missed steps. If I did my math right,
>> the RM
>>> for
>>>> 0.9.7 will have to
>>>>>>>> complete over 100 tasks (essentially, typing a
>>>> command-line 100 times).
>>>>>>>> Future RMs, when we don't have to release
>>> build-tools,
>>>> will have about
>>>>>> 92
>>>>>>>> steps. And I did not include voter
>> verification
>>> checks
>>>> the RM should
>>>>>> run
>>>>>>>> before opening a vote (verifying that the
>> artifacts
>>>> download and match
>>>>>>>> their checksums, etc). As an RM, I run a
>> bunch of
>>> tests
>>>> on the RC
>>>>>> before
>>>>>>>> sending out the vote. Maybe we should add
>> those to
>>> the
>>>> task list.
>>>>>>>>
>>>>>>>> I think there has been confusion about the
>> use of
>>> Ant
>>>> in the release
>>>>>>>> process. Because I was the RM for the first
>> set of
>>>> FlexJS/Royale
>>>>>> releases,
>>>>>>>> and I'm a lazy person who hates typing at the
>>> command
>>>> line, I created
>>>>>> Ant
>>>>>>>> scripts to execute these 100 steps. But I
>> agree
>>> that it
>>>> is not a
>>>>>>>> requirement that other RMs must use the Ant
>> scripts
>>> for
>>>> these
>>>>>> commands. If
>>>>>>>> you are the RM and like typing, go ahead.
>>>>>>>>
>>>>>>>> Then we found out that other people
>> couldn't get
>>>> through this task
>>>>>>>> list. I think the 3 people who tried were
>> having
>>> trouble
>>>> with Maven
>>>>>>>> uploads and downloads. So what I did was put
>> the
>>> first
>>>> 40 steps or so
>>>>>> into
>>>>>>>> Jenkins jobs. And by doing that, Piotr was
>> able to
>>>> produce our last
>>>>>>>> release. And that also saves on manually
>> typing
>>>> commands. But again,
>>>>>>>> going forward, the RM gets to choose how they
>> want
>>> to
>>>> execute these
>>>>>> steps.
>>>>>>>>
>>>>>>>> If you scan the set of steps, you'll see
>> that
>>> "ant" is
>>>> only in there
>>>>>>>> once. I believe the recent threads have been
>> about
>>> this
>>>> single command
>>>>>> out
>>>>>>>> of the 100+ commands. This is why this has
>> been so
>>>> frustrating to me.
>>>>>> I
>>>>>>>> believe there is a solid technical reason for
>> that
>>> one
>>>> command: it
>>>>>> proves
>>>>>>>> that the build.xml files in the source
>> packages can
>>> build
>>>> the .tar.gz
>>>>>> that
>>>>>>>> are useful to NPM and IDE users who use Ant
>> and
>>> want to
>>>> test a change.
>>>>>>>>
>>>>>>>> I think of it as code-coverage. If we had
>>>> code-coverage tools, we
>>>>>>>> would ask that the RM complete as much of the
>>> automated
>>>> code-coverage
>>>>>>>> testing as possible before posting the
>> release for a
>>>> vote. That one
>>>>>>>> command increases our code coverage by
>> running the
>>>> build.xml files. We
>>>>>>>> should be always working to increase
>> automated code
>>>> coverage in the RC.
>>>>>>>> Certainly for me as RM, I will gladly watch
>> TV as
>>> the
>>>> automated tests
>>>>>> run
>>>>>>>> because a failed RC means going back through
>> many
>>> of the
>>>> first 25
>>>>>> commands
>>>>>>>> again and wastes other people's time. Each
>> RC is
>>> more
>>>> emails to read
>>>>>> and
>>>>>>>> more time from the voters and testers.
>>>>>>>>
>>>>>>>> If there are other ways for the RM to get
>> the
>>> same or
>>>> better code
>>>>>>>> coverage on the build.xml files before
>> posting the
>>> RC, we
>>>> can discuss
>>>>>> those
>>>>>>>> options.
>>>>>>>>
>>>>>>>> I am hopeful we can all agree on these
>> simple
>>>> principles: Strive for
>>>>>>>> better code coverage and fewer failed RCs.
>>> Royale's main
>>>> purpose is to
>>>>>>>> save other people time. Let's do that in
>> creating
>>>> releases too.
>>>>>>>>
>>>>>>>> One issue that was brought up recently was
>>> whether it
>>>> is a good
>>>>>>>> decision to have the RM test all of the build
>>> platforms
>>>> we support.
>>>>>>>> Suppose we add some other build system
>> support or
>>> more in
>>>> the future?
>>>>>>>> Again, the code coverage principle applies
>> here, but
>>>> also, I would like
>>>>>> us
>>>>>>>> to retain feature parity, and I also hope for
>> as
>>> few RCs
>>>> and votes as
>>>>>>>> possible. So instead of having separate
>>>> votes/features/release-dates
>>>>>> for
>>>>>>>> the Maven artifacts vs the Ant artifacts vs
>> the
>>>> SomeFutureBuildTech
>>>>>>>> artifacts, I think we should have one vote
>> and keep
>>> them
>>>> all in sync.
>>>>>> If
>>>>>>>> we do ever get around to monthly or bi-monthly
>>> releases,
>>>> I think
>>>>>> separate
>>>>>>>> build platform releases would be too much
>> work.
>>>>>>>>
>>>>>>>> But consider this thought I just had
>> today: the
>>> RM
>>>> doesn't really
>>>>>>>> have to choose to do all 100 commands on a
>> local
>>> machine
>>>> or with Ant
>>>>>>>> scripts or do the first 40 via CI. The RM can
>>> actually
>>>> pick and choose
>>>>>>>> commands to run on the CI server. The CI
>> Jenkins
>>> jobs
>>>> are not a
>>>>>>>> separate/alternative release process, they
>> are just
>>>> another way of
>>>>>>>> executing the first 40 steps. Using CI jobs
>>> actually
>>>> requires
>>>>>> additional
>>>>>>>> command-line cut-and-paste to push commits on
>> the CI
>>>> server and to sign
>>>>>> and
>>>>>>>> validate binaries locally, but that's the
>> trade-off
>>> of
>>>> not having to
>>>>>>>> configure your machine to successfully run
>> all of
>>> the
>>>> automated tests
>>>>>> and
>>>>>>>> build systems, and being able to run a
>> command by
>>> filling
>>>> in the version
>>>>>>>> number and rc number and hitting the "ok"
>> button
>>> instead
>>>> of making sure
>>>>>> you
>>>>>>>> got the whole command typed in correctly.
>>>>>>>>
>>>>>>>> So, an RM can run the first 25 steps
>> locally,
>>> then go
>>>> the CI server
>>>>>>>> and run what is now Jenkins Job
>>> "Royale_Release_Step_013"
>>>> (no need to
>>>>>> run
>>>>>>>> the first 12) and it will run tasks 26
>> through 32,
>>> and if
>>>> it is
>>>>>> successful,
>>>>>>>> then the RM has proven code coverage of the
>>> build.xml
>>>> files. (If the
>>>>>>>> resulting tar.gz and zips are not posted,
>> then the
>>> RM
>>>> should verify that
>>>>>>>> they match the ones from Maven
>> distribution). I
>>> would
>>>> encourage RMs to
>>>>>>>> also use the CI jobs that generate the emails
>> to
>>> make
>>>> sure the subject
>>>>>> and
>>>>>>>> content is correct and contains the usual
>>> instructions so
>>>> we have
>>>>>>>> consistency. Maybe someday there will be CI
>> jobs
>>> to do
>>>> the last 60+
>>>>>> steps
>>>>>>>> if that helps. We could add a Jenkins job
>> that
>>> runs an
>>>> Ant build on RC
>>>>>>>> artifacts on dist.a.o as well.
>>>>>>>>
>>>>>>>> I would like you all to help maintain the
>> list of
>>> 100
>>>> steps and other
>>>>>>>> documents related to the release process, and
>>> improve the
>>>> CI jobs and
>>>>>> Ant
>>>>>>>> steps if it helps you be a more efficient
>> RM. I am
>>>> hopeful that now
>>>>>> that I
>>>>>>>> have hopefully explained our release process
>>> better, that
>>>> we can see
>>>>>> that
>>>>>>>> these 100+ steps just have to be done in some
>> way.
>>> The
>>>> RM can figure
>>>>>> out
>>>>>>>> what way works best for them, but they must
>> get
>>> through
>>>> all of them.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
So to summarize thanks to latest emails data,
with such complicated process of 100 commands we are not ensuring nothing
that cannot be done by the RM just checking the RC (with all build systems)
before posting to ease the work of people verifying and voting. Ergo the
recipe of 15 commands is more than enough.
El vie., 3 abr. 2020 a las 10:40, Christofer Dutz (<
christofer.dutz@c-ware.de>) escribió:
> Hi Carlos,
>
> let me correct you on one thing:
> Right now the SWCs are created by the royale compiler in both Ant and Maven
> So the output should be identical (or be pretty simple to make them
> identical).
>
> The jars created in the royale compiler contain some meta information if
> being
> Built by maven, but this can be turned off:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <configuration>
> <archive>
> <addMavenDescriptor>false</addMavenDescriptor>
> </archive>
> </configuration>
> </plugin>
>
> With this these meta information will not be packaged and it should be
> possible
> To get reproducible builds that are bit-identical, even between build
> systems.
>
> I am just questioning if the benefit of reproducibility justifies not
> releasing for
> So long. I would put it on the list of ToDos for a 1.0.0 and start
> releasing faster
> Immediately.
>
> As Carlos mentioned: I am too in strong doubt if we were to validate
> The last releases, this will probably not pass, but currently the tooling
> checks
> Against the Jenkins latest successful release, so it's not really
> checkable.
>
> If there was tooling where you can simply specify the url of a
> distribution archive and
> The tooling would build (with whatever build tool) and then compare the
> results of
> The locally built version with the distribution in the archive ... now
> that would be
> helpful. Because then others could validate the build even years after the
> release
> is done.
>
> Also then we could prepare a release with any tool we like (as long as it
> takes care
> of preparing a RC that is valid in all build systems we support).
>
> Validation PMCs are doing as well as the RM would then simply be based on
> that
> tag in GIT and simply validate the RC sources, maven artifacts and binary
> distribution
> Against what's locally built by building that tagged version.
>
> Chris
>
>
>
>
>
>
> Am 03.04.20, 10:23 schrieb "Carlos Rovira" <ca...@apache.org>:
>
> Hi Alex,
>
> trying to summarize again with this plan seems to me unnecessary, in a
> way
> that maybe until now nobody exposed and could be the key to understand
> the
> problem:
>
> if we ask ourselves: "Are we generating the same artifacts between
> build
> systems at bit level?", the response is "No". They should be mostly the
> same for an user to work with it, but after working on a release it was
> clear to me that each build system has its own "idiosyncrasy" (to say
> it
> some way), since we us to have files like metainfs, xmls, or other
> things
> that are not generated the same way.
>
> "are we creating reproducible builds?". "No". Since the compiler is not
> prepared for it. Due to differences in OS (and possibly JDK Vendor) the
> order generated in some files is different (as already exposed many
> days
> ago). So reproducible builds in 0.9.6 are not real. "what needs to be
> made
> to have reproducible builds?". "Fix the compiler is needed to implement
> it".
>
> Far beyond, "If we fix the compiler to have real reproducible builds
> will
> we have reproducible builds between build systems?". "No, will be only
> reproducible from a concrete build system perspective". So builds for
> Ant
> are reproducible for Ant, and builds done with Maven are reproducible
> with
> Maven, but are not comparable between them due to latest point, each
> build
> system generate slightly different artifacts. Checking jars for binary
> equality will fail (just opening with a tool like intellij will show
> you
> the problem easily).
>
> (subsection: since reproducibility seems more work we can left for post
> 1.0.0)
>
> So "if you make a release using one build system have sense to mix with
> other build system during the release?", "No, since as we are creating
> different artifacts, just running a full build, when release is done,
> to
> test the rest of build systems are working is enough to check it". Or
> "it
> no has sense to do release steps for all build systems since we just
> need
> to push one set of artifacts and we are really not checking any
> relation
> between them since are different things at byte level although can
> work the
> same for an user"
>
> If the problem is to save time to the rest of people verifying the
> release,
> the RM can do a full build with *all* build systems to check the
> integrity
> and that build systems are working as we all expect, so RCs are in the
> same
> state as running the 100 steps. That will far easy and quick than
> doing 100
> commands that really are not performing what we expect from what I
> explained here.
>
> In resume, both ways are the same, since reproducible builds are only
> affecting to the build system from what you're building and the
> so-called
> "reproducible artifacts" and not "comparable" with same artifacts
> generated
> by other build systems, so artifacts done with different systems are
> essentially (bit level) not equal).
>
> If after all the evidences exposed here, you still insists in impose a
> 100
> command recipe, I honestly will not understand.
>
> In exchange, if you (or other) feels better doing 100 commands when
> acting
> as RM, is completely up to you, while don't try to impose to the rest
> of
> the project.
>
> HTH
>
> Thanks
>
> Carlos
>
>
>
>
>
> El vie., 3 abr. 2020 a las 6:35, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > I honestly can't think of any steps we can do without. If you can
> explain
> > technically why some step isn't needed, then we can discuss it. I'm
> sorry
> > you don't agree. I hope the rest of the PMC will agree that we have
> to do
> > all of these steps and support the RM in doing so.
> >
> > One way to not have to actually type 90+ command is to use the Ant
> steps
> > or CI jobs. Ideas on how to do less typing to execute these 90+
> commands
> > are welcome.
> >
> > -Alex
> >
> > On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Alex,
> >
> > sincerely, I don't understand that, and was not what I
> understand for
> > your
> > first email. I must say that I completely disagree that we need
> to do
> > 90 or
> > 100 commands to get a release that should be around 15. I think
> we
> > have a
> > problem with what we really need here.
> >
> > Maybe the solution is to get some external mediator that have a
> good
> > experience with multiple build systems and releases and could
> give us
> > his
> > opinion from outside, so we can have the most logic option. I
> think if
> > we
> > can get someone that could give a hand could be very good for us.
> >
> > Can we ask in Apache for someone that review it? Maybe this will
> be the
> > only solution to avoid going in circles again, since I'm afraid
> that my
> > response will not be what you expect, but sorry, don't see this
> as you.
> >
> > I think this shouldn't be a requirement to all RMs, so people
> that
> > wants to
> > do all that commands can do it, but I sincerely prefer to stick
> with
> > the
> > recipe that is the current standard in all projects (even the
> ones that
> > have more than one build systems). Take for sure that if I see a
> need
> > to do
> > all of that I'll be glad to do it. But sincerily is something I
> don't
> > share.
> >
> > Anyway for people that wants to do that kind of checking I think
> you
> > get a
> > good advance from the previous solution.
> >
> > Thanks
> >
> >
> >
> >
> >
> >
> >
> > El jue., 2 abr. 2020 a las 21:50, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > escribió:
> >
> > > Hi Carlos,
> > >
> > > The command lines in [1] have been added to [2]. [1] is only a
> > partial
> > > list of the things to do, but includes some helpful setup
> information
> > > Hopefully in June we won't need to release build-tools so you
> will
> > only
> > > have about 90 steps to do, but we may have added more commands
> as we
> > > improve our automated test infrastructure.
> > >
> > > HTH,
> > > -Alex
> > >
> > > [2]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> > >
> > > On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org>
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > to understand your long email. Lets say that when I'll go
> to
> > release in
> > > June (0.9.9), I'll use instructions described in [1].
> > > So that will create the sources needed to post. Then, to
> avouid
> > later
> > > problems for people verifying I'll verify it with Maven
> and Ant
> > (build
> > > with
> > > both, and test SDK generated in example apps. Then push to
> > dist.a.o,
> > > create
> > > discuss and vote threads, and start the vote.
> > >
> > > Is that ok?
> > >
> > > Thanks
> > >
> > > [1]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=IBIgHvzutG7YtH27kxyD5tyaQyjBe6QetVWWsrSxF9w%3D&reserved=0
> > >
> > > El jue., 2 abr. 2020 a las 19:16, Alex Harui
> > (<aharui@adobe.com.invalid
> > > >)
> > > escribió:
> > >
> > > > I'm not sure I understand the distinction. I think we
> want to
> > do
> > > both.
> > > > The goal of code coverage is to try to exercise paths.
> We
> > want to
> > > run "ant
> > > > release" because our Ant users might want to do that.
> And Ant
> > does
> > > have
> > > > assertions AFAICT. It will report errors. Meanwhile,
> the
> > standard
> > > for
> > > > the .tar.gz package is the one produced by "ant release"
> > because
> > > that's the
> > > > recipe we've been using for years now. The Maven
> > distribution's
> > > .tar.gz
> > > > has been shown to work in most cases, but AFAICT, is
> nearly as
> > well
> > > tested
> > > > and has not been binary-compared. Ways to compare the
> two
> > .tar.gz
> > > files
> > > > are needed and welcome.
> > > >
> > > > More and better tests are welcome.
> > > >
> > > > Do we have agreement? It sounds like it. So I will now
> be
> > spending
> > > my
> > > > evenings on the release instead of writing lists of 100
> things.
> > > >
> > > > -Alex
> > > >
> > > > On 4/2/20, 8:40 AM, "Yishay Weiss" <
> yishayjobs@hotmail.com>
> > wrote:
> > > >
> > > > Chris, I think you’re missing Alex’s point. We’re not
> > running
> > > Ant to
> > > > make sure it doesn’t blow up. We’re running it to make
> sure the
> > > resultant
> > > > tar.gz/zip files are identical to the ones created by
> Maven.
> > Alex,
> > > please
> > > > correct me if I’m wrong.
> > > >
> > > > ________________________________
> > > > From: Christofer Dutz <ch...@c-ware.de>
> > > > Sent: Thursday, April 2, 2020 4:42:00 PM
> > > > To: dev@royale.apache.org <de...@royale.apache.org>
> > > > Subject: Re: Royale Releases
> > > >
> > > > And to add a little to that [1]
> > > >
> > > > "In computer science, test coverage is a measure
> used to
> > > describe the
> > > > degree to which the source code of a program is executed
> when a
> > > particular
> > > > test suite runs."
> > > >
> > > > So no test, no coverage. Just using something and
> it's not
> > > blowing up
> > > > isn't a test for me. It's better than nothing however.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=ohLzW9qtDjCrsy8mHX47Z2qkWR4me5giS%2BSEGSUSWKQ%3D&reserved=0
> > > >
> > > > Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> > > > christofer.dutz@c-ware.de>:
> > > >
> > > > Hi folks,
> > > >
> > > > I would say we have coverage for both maven ant
> > equally as
> > > we're
> > > > building the same code.
> > > >
> > > > However we are missing the important assertions.
> It's
> > not
> > > that the
> > > > Ant build is running some tests Maven isn't.
> > > > It's just that the settings for Ant seem to be
> > different
> > > than for
> > > > Maven and the Ant ones happen to work.
> > > >
> > > > Ideally there would be real tests that test the
> output
> > of
> > > both to
> > > > see if it works in both cases.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > Am 02.04.20, 15:15 schrieb "Harbs" <
> > harbs.lists@gmail.com>:
> > > >
> > > > Adding more coverage for Maven is good.
> > > >
> > > > Removing coverage for Ant is not.
> > > >
> > > > Do you agree?
> > > >
> > > > > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> > > > carlosrovira@apache.org> wrote:
> > > > >
> > > > > Hi Harbs,
> > > > >
> > > > > I think what we're trying to say is that
> until
> > now we
> > > > released with Maven
> > > > > and Ant, and that was hiding a flaw in
> Maven (SVG
> > > example).
> > > > So that means
> > > > > what we were trying to cover was not
> covered
> > clearly,
> > > so the
> > > > premise is not
> > > > > right.
> > > > >
> > > > >
> > > > >
> > > > > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> > > > harbs.lists@gmail.com>) escribió:
> > > > >
> > > > >> No one is arguing that we shouldn’t add
> more
> > tests.
> > > > >>
> > > > >> Please let’s not make it seem like
> there’s a
> > > disagreement
> > > > about that.
> > > > >>
> > > > >>> On Apr 2, 2020, at 10:46 AM, Carlos
> Rovira <
> > > > carlosrovira@apache.org>
> > > > >> wrote:
> > > > >>>
> > > > >>> Hi Alex,
> > > > >>>
> > > > >>> first, many thanks for the detailed
> email. I'll
> > > comment on
> > > > this later as
> > > > >> I
> > > > >>> have more time.
> > > > >>>
> > > > >>> For now, to add up a recent example on
> what
> > Chris
> > > > commented: If you all
> > > > >>> remember a week ago I was trying to use
> SVG
> > Images
> > > in a
> > > > blog example that
> > > > >>> was published 2 days ago. Nobody tried
> SVG
> > Images
> > > before
> > > > building with
> > > > >>> maven, I know that since maven was not
> properly
> > > configured
> > > > and using that
> > > > >>> component from Maven was failing with an
> RTE.
> > > Probably we
> > > > have more
> > > > >> things
> > > > >>> not working the same way when build from
> Maven
> > and
> > > Ant,
> > > > and that's
> > > > >>> something that will need people using
> that code
> > > paths in
> > > > test
> > > > >> applications
> > > > >>> (or in their own apps) to see if things
> works
> > > properly.
> > > > >>>
> > > > >>> I was recently introduced to
> > > "examples-integrationtest" by
> > > > Chris, that I
> > > > >>> plan to use soon as I can. I think is a
> great
> > idea,
> > > since
> > > > you get a
> > > > >> Firefox
> > > > >>> running test interface of the real use
> of some
> > > concrete
> > > > royale code. I
> > > > >>> think passed until now unnoticed by all
> of us,
> > and
> > > seems a
> > > > powerful tool.
> > > > >>> There's already an example about
> FlexStore
> > with some
> > > basic
> > > > assertions.
> > > > >>>
> > > > >>> Again, thanks, and will comment on the
> rest
> > later
> > > > >>>
> > > > >>> Carlos
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> El jue., 2 abr. 2020 a las 9:20,
> Christofer
> > Dutz (<
> > > > >> christofer.dutz@c-ware.de>)
> > > > >>> escribió:
> > > > >>>
> > > > >>>> Hi Alex,
> > > > >>>>
> > > > >>>> just a point you are bringing up: "Code
> > coverage".
> > > > >>>>
> > > > >>>> I strongly dislike the idea of "asjs"
> > effectively
> > > being
> > > > the test for the
> > > > >>>> compiler. The reasoning behind this is:
> yes
> > you do
> > > get
> > > > more code
> > > > >> covered,
> > > > >>>> but only the happy-path (ideally) and
> even if
> > > things go
> > > > wrong, the end
> > > > >>>> results aren't tested. Did add a module
> to
> > asjs
> > > years ago
> > > > >>>> ("examples-integrationtest") that
> deployed the
> > > examples
> > > > in a tomcat
> > > > >> server
> > > > >>>> then opens a Firefox browser and clicks
> > through 2
> > > of the
> > > > examples (I
> > > > >> added
> > > > >>>> two dummy tests as an example, but
> seems no
> > one
> > > touched
> > > > this after me).
> > > > >> I
> > > > >>>> did this because I remember us working
> on
> > asjs for
> > > weeks
> > > > without anyone
> > > > >>>> noticing the compiler wasn't producing
> > runnable
> > > code ...
> > > > same with the
> > > > >>>> little unit-tests that are still run
> for every
> > > example,
> > > > that simply
> > > > >> check
> > > > >>>> if an output is generated, because we
> had a
> > > prolonged
> > > > period of time
> > > > >> where
> > > > >>>> we were all working on different parts,
> but
> > for
> > > quite
> > > > some time the
> > > > >>>> application compilation just didn't
> output
> > anything
> > > and
> > > > no one noticed.
> > > > >>>>
> > > > >>>> So coverage is nothing without
> assertions (my
> > > opinion)
> > > > ... ok ... it's
> > > > >>>> slightly better than no coverage, but
> not
> > much, in
> > > my
> > > > opinion.
> > > > >>>>
> > > > >>>> I think in parallel to this release
> > discussions I
> > > have
> > > > seen numerous
> > > > >>>> threads about someone doing something
> that
> > broke
> > > > something for someone
> > > > >>>> else. This could be addressed by
> increasing
> > > coverage by
> > > > providing
> > > > >> explicit
> > > > >>>> tests.
> > > > >>>>
> > > > >>>> Coming back to the releases:
> > > > >>>> I have no objections, if you do a
> "release"
> > locally
> > > and
> > > > automate the
> > > > >>>> validation on the CI server (Which
> effectively
> > > would be
> > > > your proposal
> > > > >> to do
> > > > >>>> the first 12 steps on local hardware
> and the
> > 13th
> > > on the
> > > > CI server). I
> > > > >> even
> > > > >>>> think that's a good idea ... There
> could be
> > one
> > > step for
> > > > building a
> > > > >> release
> > > > >>>> from a given "git tag" for every build
> system
> > and
> > > generic
> > > > means to
> > > > >> compare
> > > > >>>> tar.gz and zips produced by any build
> system
> > with
> > > that of
> > > > another
> > > > >> (ideally
> > > > >>>> with better output than just a plain
> > "true/false").
> > > This
> > > > would even
> > > > >> help to
> > > > >>>> iron out the last potentially existing
> bumps
> > out of
> > > the
> > > > Maven
> > > > >> distribution.
> > > > >>>>
> > > > >>>> Chris
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> > > > <ah...@adobe.com.INVALID>:
> > > > >>>>
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> This is my attempt to explain what
> goes
> > into a
> > > release
> > > > in hopes that
> > > > >>>> we can understand and agree on what our
> > release
> > > process
> > > > is. It became
> > > > >>>> apparent in my reading of the wiki page
> with
> > the new
> > > > Maven steps and in
> > > > >>>> talking with Harbs today that there are
> still
> > many
> > > > misunderstandings
> > > > >> about
> > > > >>>> what we do to create a release. I don't
> > generally
> > > like
> > > > writing
> > > > >>>> instructions in English because it is
> easy to
> > be
> > > > ambiguous. All of the
> > > > >>>> steps that we use to create releases
> had been
> > > captured in
> > > > Ant scripts
> > > > >> in a
> > > > >>>> much more explicit way, IMO, but I took
> the
> > time to
> > > write
> > > > them down in
> > > > >>>> English here:
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> > > > >>>>
> > > > >>>> I did this quickly by scanning the CI
> > steps, the
> > > new
> > > > Maven steps and
> > > > >>>> the Ant scripts used in prior releases
> so
> > there
> > > could
> > > > certainly be
> > > > >> mistakes
> > > > >>>> and missed steps. If I did my math
> right,
> > the RM
> > > for
> > > > 0.9.7 will have to
> > > > >>>> complete over 100 tasks (essentially,
> typing a
> > > > command-line 100 times).
> > > > >>>> Future RMs, when we don't have to
> release
> > > build-tools,
> > > > will have about
> > > > >> 92
> > > > >>>> steps. And I did not include voter
> > verification
> > > checks
> > > > the RM should
> > > > >> run
> > > > >>>> before opening a vote (verifying that
> the
> > artifacts
> > > > download and match
> > > > >>>> their checksums, etc). As an RM, I run
> a
> > bunch of
> > > tests
> > > > on the RC
> > > > >> before
> > > > >>>> sending out the vote. Maybe we should
> add
> > those to
> > > the
> > > > task list.
> > > > >>>>
> > > > >>>> I think there has been confusion
> about the
> > use of
> > > Ant
> > > > in the release
> > > > >>>> process. Because I was the RM for the
> first
> > set of
> > > > FlexJS/Royale
> > > > >> releases,
> > > > >>>> and I'm a lazy person who hates typing
> at the
> > > command
> > > > line, I created
> > > > >> Ant
> > > > >>>> scripts to execute these 100 steps.
> But I
> > agree
> > > that it
> > > > is not a
> > > > >>>> requirement that other RMs must use the
> Ant
> > scripts
> > > for
> > > > these
> > > > >> commands. If
> > > > >>>> you are the RM and like typing, go
> ahead.
> > > > >>>>
> > > > >>>> Then we found out that other people
> > couldn't get
> > > > through this task
> > > > >>>> list. I think the 3 people who tried
> were
> > having
> > > trouble
> > > > with Maven
> > > > >>>> uploads and downloads. So what I did
> was put
> > the
> > > first
> > > > 40 steps or so
> > > > >> into
> > > > >>>> Jenkins jobs. And by doing that, Piotr
> was
> > able to
> > > > produce our last
> > > > >>>> release. And that also saves on
> manually
> > typing
> > > > commands. But again,
> > > > >>>> going forward, the RM gets to choose
> how they
> > want
> > > to
> > > > execute these
> > > > >> steps.
> > > > >>>>
> > > > >>>> If you scan the set of steps, you'll
> see
> > that
> > > "ant" is
> > > > only in there
> > > > >>>> once. I believe the recent threads
> have been
> > about
> > > this
> > > > single command
> > > > >> out
> > > > >>>> of the 100+ commands. This is why this
> has
> > been so
> > > > frustrating to me.
> > > > >> I
> > > > >>>> believe there is a solid technical
> reason for
> > that
> > > one
> > > > command: it
> > > > >> proves
> > > > >>>> that the build.xml files in the source
> > packages can
> > > build
> > > > the .tar.gz
> > > > >> that
> > > > >>>> are useful to NPM and IDE users who use
> Ant
> > and
> > > want to
> > > > test a change.
> > > > >>>>
> > > > >>>> I think of it as code-coverage. If
> we had
> > > > code-coverage tools, we
> > > > >>>> would ask that the RM complete as much
> of the
> > > automated
> > > > code-coverage
> > > > >>>> testing as possible before posting the
> > release for a
> > > > vote. That one
> > > > >>>> command increases our code coverage by
> > running the
> > > > build.xml files. We
> > > > >>>> should be always working to increase
> > automated code
> > > > coverage in the RC.
> > > > >>>> Certainly for me as RM, I will gladly
> watch
> > TV as
> > > the
> > > > automated tests
> > > > >> run
> > > > >>>> because a failed RC means going back
> through
> > many
> > > of the
> > > > first 25
> > > > >> commands
> > > > >>>> again and wastes other people's time.
> Each
> > RC is
> > > more
> > > > emails to read
> > > > >> and
> > > > >>>> more time from the voters and testers.
> > > > >>>>
> > > > >>>> If there are other ways for the RM to
> get
> > the
> > > same or
> > > > better code
> > > > >>>> coverage on the build.xml files before
> > posting the
> > > RC, we
> > > > can discuss
> > > > >> those
> > > > >>>> options.
> > > > >>>>
> > > > >>>> I am hopeful we can all agree on these
> > simple
> > > > principles: Strive for
> > > > >>>> better code coverage and fewer failed
> RCs.
> > > Royale's main
> > > > purpose is to
> > > > >>>> save other people time. Let's do that
> in
> > creating
> > > > releases too.
> > > > >>>>
> > > > >>>> One issue that was brought up
> recently was
> > > whether it
> > > > is a good
> > > > >>>> decision to have the RM test all of the
> build
> > > platforms
> > > > we support.
> > > > >>>> Suppose we add some other build system
> > support or
> > > more in
> > > > the future?
> > > > >>>> Again, the code coverage principle
> applies
> > here, but
> > > > also, I would like
> > > > >> us
> > > > >>>> to retain feature parity, and I also
> hope for
> > as
> > > few RCs
> > > > and votes as
> > > > >>>> possible. So instead of having separate
> > > > votes/features/release-dates
> > > > >> for
> > > > >>>> the Maven artifacts vs the Ant
> artifacts vs
> > the
> > > > SomeFutureBuildTech
> > > > >>>> artifacts, I think we should have one
> vote
> > and keep
> > > them
> > > > all in sync.
> > > > >> If
> > > > >>>> we do ever get around to monthly or
> bi-monthly
> > > releases,
> > > > I think
> > > > >> separate
> > > > >>>> build platform releases would be too
> much
> > work.
> > > > >>>>
> > > > >>>> But consider this thought I just had
> > today: the
> > > RM
> > > > doesn't really
> > > > >>>> have to choose to do all 100 commands
> on a
> > local
> > > machine
> > > > or with Ant
> > > > >>>> scripts or do the first 40 via CI. The
> RM can
> > > actually
> > > > pick and choose
> > > > >>>> commands to run on the CI server. The
> CI
> > Jenkins
> > > jobs
> > > > are not a
> > > > >>>> separate/alternative release process,
> they
> > are just
> > > > another way of
> > > > >>>> executing the first 40 steps. Using CI
> jobs
> > > actually
> > > > requires
> > > > >> additional
> > > > >>>> command-line cut-and-paste to push
> commits on
> > the CI
> > > > server and to sign
> > > > >> and
> > > > >>>> validate binaries locally, but that's
> the
> > trade-off
> > > of
> > > > not having to
> > > > >>>> configure your machine to successfully
> run
> > all of
> > > the
> > > > automated tests
> > > > >> and
> > > > >>>> build systems, and being able to run a
> > command by
> > > filling
> > > > in the version
> > > > >>>> number and rc number and hitting the
> "ok"
> > button
> > > instead
> > > > of making sure
> > > > >> you
> > > > >>>> got the whole command typed in
> correctly.
> > > > >>>>
> > > > >>>> So, an RM can run the first 25 steps
> > locally,
> > > then go
> > > > the CI server
> > > > >>>> and run what is now Jenkins Job
> > > "Royale_Release_Step_013"
> > > > (no need to
> > > > >> run
> > > > >>>> the first 12) and it will run tasks 26
> > through 32,
> > > and if
> > > > it is
> > > > >> successful,
> > > > >>>> then the RM has proven code coverage of
> the
> > > build.xml
> > > > files. (If the
> > > > >>>> resulting tar.gz and zips are not
> posted,
> > then the
> > > RM
> > > > should verify that
> > > > >>>> they match the ones from Maven
> > distribution). I
> > > would
> > > > encourage RMs to
> > > > >>>> also use the CI jobs that generate the
> emails
> > to
> > > make
> > > > sure the subject
> > > > >> and
> > > > >>>> content is correct and contains the
> usual
> > > instructions so
> > > > we have
> > > > >>>> consistency. Maybe someday there will
> be CI
> > jobs
> > > to do
> > > > the last 60+
> > > > >> steps
> > > > >>>> if that helps. We could add a Jenkins
> job
> > that
> > > runs an
> > > > Ant build on RC
> > > > >>>> artifacts on dist.a.o as well.
> > > > >>>>
> > > > >>>> I would like you all to help maintain
> the
> > list of
> > > 100
> > > > steps and other
> > > > >>>> documents related to the release
> process, and
> > > improve the
> > > > CI jobs and
> > > > >> Ant
> > > > >>>> steps if it helps you be a more
> efficient
> > RM. I am
> > > > hopeful that now
> > > > >> that I
> > > > >>>> have hopefully explained our release
> process
> > > better, that
> > > > we can see
> > > > >> that
> > > > >>>> these 100+ steps just have to be done
> in some
> > way.
> > > The
> > > > RM can figure
> > > > >> out
> > > > >>>> what way works best for them, but they
> must
> > get
> > > through
> > > > all of them.
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>> -Alex
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>> --
> > > > >>> Carlos Rovira
> > > > >>>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Carlos,
let me correct you on one thing:
Right now the SWCs are created by the royale compiler in both Ant and Maven
So the output should be identical (or be pretty simple to make them identical).
The jars created in the royale compiler contain some meta information if being
Built by maven, but this can be turned off:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
</configuration>
</plugin>
With this these meta information will not be packaged and it should be possible
To get reproducible builds that are bit-identical, even between build systems.
I am just questioning if the benefit of reproducibility justifies not releasing for
So long. I would put it on the list of ToDos for a 1.0.0 and start releasing faster
Immediately.
As Carlos mentioned: I am too in strong doubt if we were to validate
The last releases, this will probably not pass, but currently the tooling checks
Against the Jenkins latest successful release, so it's not really checkable.
If there was tooling where you can simply specify the url of a distribution archive and
The tooling would build (with whatever build tool) and then compare the results of
The locally built version with the distribution in the archive ... now that would be
helpful. Because then others could validate the build even years after the release
is done.
Also then we could prepare a release with any tool we like (as long as it takes care
of preparing a RC that is valid in all build systems we support).
Validation PMCs are doing as well as the RM would then simply be based on that
tag in GIT and simply validate the RC sources, maven artifacts and binary distribution
Against what's locally built by building that tagged version.
Chris
Am 03.04.20, 10:23 schrieb "Carlos Rovira" <ca...@apache.org>:
Hi Alex,
trying to summarize again with this plan seems to me unnecessary, in a way
that maybe until now nobody exposed and could be the key to understand the
problem:
if we ask ourselves: "Are we generating the same artifacts between build
systems at bit level?", the response is "No". They should be mostly the
same for an user to work with it, but after working on a release it was
clear to me that each build system has its own "idiosyncrasy" (to say it
some way), since we us to have files like metainfs, xmls, or other things
that are not generated the same way.
"are we creating reproducible builds?". "No". Since the compiler is not
prepared for it. Due to differences in OS (and possibly JDK Vendor) the
order generated in some files is different (as already exposed many days
ago). So reproducible builds in 0.9.6 are not real. "what needs to be made
to have reproducible builds?". "Fix the compiler is needed to implement
it".
Far beyond, "If we fix the compiler to have real reproducible builds will
we have reproducible builds between build systems?". "No, will be only
reproducible from a concrete build system perspective". So builds for Ant
are reproducible for Ant, and builds done with Maven are reproducible with
Maven, but are not comparable between them due to latest point, each build
system generate slightly different artifacts. Checking jars for binary
equality will fail (just opening with a tool like intellij will show you
the problem easily).
(subsection: since reproducibility seems more work we can left for post
1.0.0)
So "if you make a release using one build system have sense to mix with
other build system during the release?", "No, since as we are creating
different artifacts, just running a full build, when release is done, to
test the rest of build systems are working is enough to check it". Or "it
no has sense to do release steps for all build systems since we just need
to push one set of artifacts and we are really not checking any relation
between them since are different things at byte level although can work the
same for an user"
If the problem is to save time to the rest of people verifying the release,
the RM can do a full build with *all* build systems to check the integrity
and that build systems are working as we all expect, so RCs are in the same
state as running the 100 steps. That will far easy and quick than doing 100
commands that really are not performing what we expect from what I
explained here.
In resume, both ways are the same, since reproducible builds are only
affecting to the build system from what you're building and the so-called
"reproducible artifacts" and not "comparable" with same artifacts generated
by other build systems, so artifacts done with different systems are
essentially (bit level) not equal).
If after all the evidences exposed here, you still insists in impose a 100
command recipe, I honestly will not understand.
In exchange, if you (or other) feels better doing 100 commands when acting
as RM, is completely up to you, while don't try to impose to the rest of
the project.
HTH
Thanks
Carlos
El vie., 3 abr. 2020 a las 6:35, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I honestly can't think of any steps we can do without. If you can explain
> technically why some step isn't needed, then we can discuss it. I'm sorry
> you don't agree. I hope the rest of the PMC will agree that we have to do
> all of these steps and support the RM in doing so.
>
> One way to not have to actually type 90+ command is to use the Ant steps
> or CI jobs. Ideas on how to do less typing to execute these 90+ commands
> are welcome.
>
> -Alex
>
> On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> sincerely, I don't understand that, and was not what I understand for
> your
> first email. I must say that I completely disagree that we need to do
> 90 or
> 100 commands to get a release that should be around 15. I think we
> have a
> problem with what we really need here.
>
> Maybe the solution is to get some external mediator that have a good
> experience with multiple build systems and releases and could give us
> his
> opinion from outside, so we can have the most logic option. I think if
> we
> can get someone that could give a hand could be very good for us.
>
> Can we ask in Apache for someone that review it? Maybe this will be the
> only solution to avoid going in circles again, since I'm afraid that my
> response will not be what you expect, but sorry, don't see this as you.
>
> I think this shouldn't be a requirement to all RMs, so people that
> wants to
> do all that commands can do it, but I sincerely prefer to stick with
> the
> recipe that is the current standard in all projects (even the ones that
> have more than one build systems). Take for sure that if I see a need
> to do
> all of that I'll be glad to do it. But sincerily is something I don't
> share.
>
> Anyway for people that wants to do that kind of checking I think you
> get a
> good advance from the previous solution.
>
> Thanks
>
>
>
>
>
>
>
> El jue., 2 abr. 2020 a las 21:50, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > Hi Carlos,
> >
> > The command lines in [1] have been added to [2]. [1] is only a
> partial
> > list of the things to do, but includes some helpful setup information
> > Hopefully in June we won't need to release build-tools so you will
> only
> > have about 90 steps to do, but we may have added more commands as we
> > improve our automated test infrastructure.
> >
> > HTH,
> > -Alex
> >
> > [2]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> >
> > On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > to understand your long email. Lets say that when I'll go to
> release in
> > June (0.9.9), I'll use instructions described in [1].
> > So that will create the sources needed to post. Then, to avouid
> later
> > problems for people verifying I'll verify it with Maven and Ant
> (build
> > with
> > both, and test SDK generated in example apps. Then push to
> dist.a.o,
> > create
> > discuss and vote threads, and start the vote.
> >
> > Is that ok?
> >
> > Thanks
> >
> > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=IBIgHvzutG7YtH27kxyD5tyaQyjBe6QetVWWsrSxF9w%3D&reserved=0
> >
> > El jue., 2 abr. 2020 a las 19:16, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > escribió:
> >
> > > I'm not sure I understand the distinction. I think we want to
> do
> > both.
> > > The goal of code coverage is to try to exercise paths. We
> want to
> > run "ant
> > > release" because our Ant users might want to do that. And Ant
> does
> > have
> > > assertions AFAICT. It will report errors. Meanwhile, the
> standard
> > for
> > > the .tar.gz package is the one produced by "ant release"
> because
> > that's the
> > > recipe we've been using for years now. The Maven
> distribution's
> > .tar.gz
> > > has been shown to work in most cases, but AFAICT, is nearly as
> well
> > tested
> > > and has not been binary-compared. Ways to compare the two
> .tar.gz
> > files
> > > are needed and welcome.
> > >
> > > More and better tests are welcome.
> > >
> > > Do we have agreement? It sounds like it. So I will now be
> spending
> > my
> > > evenings on the release instead of writing lists of 100 things.
> > >
> > > -Alex
> > >
> > > On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com>
> wrote:
> > >
> > > Chris, I think you’re missing Alex’s point. We’re not
> running
> > Ant to
> > > make sure it doesn’t blow up. We’re running it to make sure the
> > resultant
> > > tar.gz/zip files are identical to the ones created by Maven.
> Alex,
> > please
> > > correct me if I’m wrong.
> > >
> > > ________________________________
> > > From: Christofer Dutz <ch...@c-ware.de>
> > > Sent: Thursday, April 2, 2020 4:42:00 PM
> > > To: dev@royale.apache.org <de...@royale.apache.org>
> > > Subject: Re: Royale Releases
> > >
> > > And to add a little to that [1]
> > >
> > > "In computer science, test coverage is a measure used to
> > describe the
> > > degree to which the source code of a program is executed when a
> > particular
> > > test suite runs."
> > >
> > > So no test, no coverage. Just using something and it's not
> > blowing up
> > > isn't a test for me. It's better than nothing however.
> > >
> > > Chris
> > >
> > >
> > >
> > > [1]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=ohLzW9qtDjCrsy8mHX47Z2qkWR4me5giS%2BSEGSUSWKQ%3D&reserved=0
> > >
> > > Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> > > christofer.dutz@c-ware.de>:
> > >
> > > Hi folks,
> > >
> > > I would say we have coverage for both maven ant
> equally as
> > we're
> > > building the same code.
> > >
> > > However we are missing the important assertions. It's
> not
> > that the
> > > Ant build is running some tests Maven isn't.
> > > It's just that the settings for Ant seem to be
> different
> > than for
> > > Maven and the Ant ones happen to work.
> > >
> > > Ideally there would be real tests that test the output
> of
> > both to
> > > see if it works in both cases.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 02.04.20, 15:15 schrieb "Harbs" <
> harbs.lists@gmail.com>:
> > >
> > > Adding more coverage for Maven is good.
> > >
> > > Removing coverage for Ant is not.
> > >
> > > Do you agree?
> > >
> > > > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> > > carlosrovira@apache.org> wrote:
> > > >
> > > > Hi Harbs,
> > > >
> > > > I think what we're trying to say is that until
> now we
> > > released with Maven
> > > > and Ant, and that was hiding a flaw in Maven (SVG
> > example).
> > > So that means
> > > > what we were trying to cover was not covered
> clearly,
> > so the
> > > premise is not
> > > > right.
> > > >
> > > >
> > > >
> > > > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> > > harbs.lists@gmail.com>) escribió:
> > > >
> > > >> No one is arguing that we shouldn’t add more
> tests.
> > > >>
> > > >> Please let’s not make it seem like there’s a
> > disagreement
> > > about that.
> > > >>
> > > >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> > > carlosrovira@apache.org>
> > > >> wrote:
> > > >>>
> > > >>> Hi Alex,
> > > >>>
> > > >>> first, many thanks for the detailed email. I'll
> > comment on
> > > this later as
> > > >> I
> > > >>> have more time.
> > > >>>
> > > >>> For now, to add up a recent example on what
> Chris
> > > commented: If you all
> > > >>> remember a week ago I was trying to use SVG
> Images
> > in a
> > > blog example that
> > > >>> was published 2 days ago. Nobody tried SVG
> Images
> > before
> > > building with
> > > >>> maven, I know that since maven was not properly
> > configured
> > > and using that
> > > >>> component from Maven was failing with an RTE.
> > Probably we
> > > have more
> > > >> things
> > > >>> not working the same way when build from Maven
> and
> > Ant,
> > > and that's
> > > >>> something that will need people using that code
> > paths in
> > > test
> > > >> applications
> > > >>> (or in their own apps) to see if things works
> > properly.
> > > >>>
> > > >>> I was recently introduced to
> > "examples-integrationtest" by
> > > Chris, that I
> > > >>> plan to use soon as I can. I think is a great
> idea,
> > since
> > > you get a
> > > >> Firefox
> > > >>> running test interface of the real use of some
> > concrete
> > > royale code. I
> > > >>> think passed until now unnoticed by all of us,
> and
> > seems a
> > > powerful tool.
> > > >>> There's already an example about FlexStore
> with some
> > basic
> > > assertions.
> > > >>>
> > > >>> Again, thanks, and will comment on the rest
> later
> > > >>>
> > > >>> Carlos
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> El jue., 2 abr. 2020 a las 9:20, Christofer
> Dutz (<
> > > >> christofer.dutz@c-ware.de>)
> > > >>> escribió:
> > > >>>
> > > >>>> Hi Alex,
> > > >>>>
> > > >>>> just a point you are bringing up: "Code
> coverage".
> > > >>>>
> > > >>>> I strongly dislike the idea of "asjs"
> effectively
> > being
> > > the test for the
> > > >>>> compiler. The reasoning behind this is: yes
> you do
> > get
> > > more code
> > > >> covered,
> > > >>>> but only the happy-path (ideally) and even if
> > things go
> > > wrong, the end
> > > >>>> results aren't tested. Did add a module to
> asjs
> > years ago
> > > >>>> ("examples-integrationtest") that deployed the
> > examples
> > > in a tomcat
> > > >> server
> > > >>>> then opens a Firefox browser and clicks
> through 2
> > of the
> > > examples (I
> > > >> added
> > > >>>> two dummy tests as an example, but seems no
> one
> > touched
> > > this after me).
> > > >> I
> > > >>>> did this because I remember us working on
> asjs for
> > weeks
> > > without anyone
> > > >>>> noticing the compiler wasn't producing
> runnable
> > code ...
> > > same with the
> > > >>>> little unit-tests that are still run for every
> > example,
> > > that simply
> > > >> check
> > > >>>> if an output is generated, because we had a
> > prolonged
> > > period of time
> > > >> where
> > > >>>> we were all working on different parts, but
> for
> > quite
> > > some time the
> > > >>>> application compilation just didn't output
> anything
> > and
> > > no one noticed.
> > > >>>>
> > > >>>> So coverage is nothing without assertions (my
> > opinion)
> > > ... ok ... it's
> > > >>>> slightly better than no coverage, but not
> much, in
> > my
> > > opinion.
> > > >>>>
> > > >>>> I think in parallel to this release
> discussions I
> > have
> > > seen numerous
> > > >>>> threads about someone doing something that
> broke
> > > something for someone
> > > >>>> else. This could be addressed by increasing
> > coverage by
> > > providing
> > > >> explicit
> > > >>>> tests.
> > > >>>>
> > > >>>> Coming back to the releases:
> > > >>>> I have no objections, if you do a "release"
> locally
> > and
> > > automate the
> > > >>>> validation on the CI server (Which effectively
> > would be
> > > your proposal
> > > >> to do
> > > >>>> the first 12 steps on local hardware and the
> 13th
> > on the
> > > CI server). I
> > > >> even
> > > >>>> think that's a good idea ... There could be
> one
> > step for
> > > building a
> > > >> release
> > > >>>> from a given "git tag" for every build system
> and
> > generic
> > > means to
> > > >> compare
> > > >>>> tar.gz and zips produced by any build system
> with
> > that of
> > > another
> > > >> (ideally
> > > >>>> with better output than just a plain
> "true/false").
> > This
> > > would even
> > > >> help to
> > > >>>> iron out the last potentially existing bumps
> out of
> > the
> > > Maven
> > > >> distribution.
> > > >>>>
> > > >>>> Chris
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> > > <ah...@adobe.com.INVALID>:
> > > >>>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> This is my attempt to explain what goes
> into a
> > release
> > > in hopes that
> > > >>>> we can understand and agree on what our
> release
> > process
> > > is. It became
> > > >>>> apparent in my reading of the wiki page with
> the new
> > > Maven steps and in
> > > >>>> talking with Harbs today that there are still
> many
> > > misunderstandings
> > > >> about
> > > >>>> what we do to create a release. I don't
> generally
> > like
> > > writing
> > > >>>> instructions in English because it is easy to
> be
> > > ambiguous. All of the
> > > >>>> steps that we use to create releases had been
> > captured in
> > > Ant scripts
> > > >> in a
> > > >>>> much more explicit way, IMO, but I took the
> time to
> > write
> > > them down in
> > > >>>> English here:
> > > >>>>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> > > >>>>
> > > >>>> I did this quickly by scanning the CI
> steps, the
> > new
> > > Maven steps and
> > > >>>> the Ant scripts used in prior releases so
> there
> > could
> > > certainly be
> > > >> mistakes
> > > >>>> and missed steps. If I did my math right,
> the RM
> > for
> > > 0.9.7 will have to
> > > >>>> complete over 100 tasks (essentially, typing a
> > > command-line 100 times).
> > > >>>> Future RMs, when we don't have to release
> > build-tools,
> > > will have about
> > > >> 92
> > > >>>> steps. And I did not include voter
> verification
> > checks
> > > the RM should
> > > >> run
> > > >>>> before opening a vote (verifying that the
> artifacts
> > > download and match
> > > >>>> their checksums, etc). As an RM, I run a
> bunch of
> > tests
> > > on the RC
> > > >> before
> > > >>>> sending out the vote. Maybe we should add
> those to
> > the
> > > task list.
> > > >>>>
> > > >>>> I think there has been confusion about the
> use of
> > Ant
> > > in the release
> > > >>>> process. Because I was the RM for the first
> set of
> > > FlexJS/Royale
> > > >> releases,
> > > >>>> and I'm a lazy person who hates typing at the
> > command
> > > line, I created
> > > >> Ant
> > > >>>> scripts to execute these 100 steps. But I
> agree
> > that it
> > > is not a
> > > >>>> requirement that other RMs must use the Ant
> scripts
> > for
> > > these
> > > >> commands. If
> > > >>>> you are the RM and like typing, go ahead.
> > > >>>>
> > > >>>> Then we found out that other people
> couldn't get
> > > through this task
> > > >>>> list. I think the 3 people who tried were
> having
> > trouble
> > > with Maven
> > > >>>> uploads and downloads. So what I did was put
> the
> > first
> > > 40 steps or so
> > > >> into
> > > >>>> Jenkins jobs. And by doing that, Piotr was
> able to
> > > produce our last
> > > >>>> release. And that also saves on manually
> typing
> > > commands. But again,
> > > >>>> going forward, the RM gets to choose how they
> want
> > to
> > > execute these
> > > >> steps.
> > > >>>>
> > > >>>> If you scan the set of steps, you'll see
> that
> > "ant" is
> > > only in there
> > > >>>> once. I believe the recent threads have been
> about
> > this
> > > single command
> > > >> out
> > > >>>> of the 100+ commands. This is why this has
> been so
> > > frustrating to me.
> > > >> I
> > > >>>> believe there is a solid technical reason for
> that
> > one
> > > command: it
> > > >> proves
> > > >>>> that the build.xml files in the source
> packages can
> > build
> > > the .tar.gz
> > > >> that
> > > >>>> are useful to NPM and IDE users who use Ant
> and
> > want to
> > > test a change.
> > > >>>>
> > > >>>> I think of it as code-coverage. If we had
> > > code-coverage tools, we
> > > >>>> would ask that the RM complete as much of the
> > automated
> > > code-coverage
> > > >>>> testing as possible before posting the
> release for a
> > > vote. That one
> > > >>>> command increases our code coverage by
> running the
> > > build.xml files. We
> > > >>>> should be always working to increase
> automated code
> > > coverage in the RC.
> > > >>>> Certainly for me as RM, I will gladly watch
> TV as
> > the
> > > automated tests
> > > >> run
> > > >>>> because a failed RC means going back through
> many
> > of the
> > > first 25
> > > >> commands
> > > >>>> again and wastes other people's time. Each
> RC is
> > more
> > > emails to read
> > > >> and
> > > >>>> more time from the voters and testers.
> > > >>>>
> > > >>>> If there are other ways for the RM to get
> the
> > same or
> > > better code
> > > >>>> coverage on the build.xml files before
> posting the
> > RC, we
> > > can discuss
> > > >> those
> > > >>>> options.
> > > >>>>
> > > >>>> I am hopeful we can all agree on these
> simple
> > > principles: Strive for
> > > >>>> better code coverage and fewer failed RCs.
> > Royale's main
> > > purpose is to
> > > >>>> save other people time. Let's do that in
> creating
> > > releases too.
> > > >>>>
> > > >>>> One issue that was brought up recently was
> > whether it
> > > is a good
> > > >>>> decision to have the RM test all of the build
> > platforms
> > > we support.
> > > >>>> Suppose we add some other build system
> support or
> > more in
> > > the future?
> > > >>>> Again, the code coverage principle applies
> here, but
> > > also, I would like
> > > >> us
> > > >>>> to retain feature parity, and I also hope for
> as
> > few RCs
> > > and votes as
> > > >>>> possible. So instead of having separate
> > > votes/features/release-dates
> > > >> for
> > > >>>> the Maven artifacts vs the Ant artifacts vs
> the
> > > SomeFutureBuildTech
> > > >>>> artifacts, I think we should have one vote
> and keep
> > them
> > > all in sync.
> > > >> If
> > > >>>> we do ever get around to monthly or bi-monthly
> > releases,
> > > I think
> > > >> separate
> > > >>>> build platform releases would be too much
> work.
> > > >>>>
> > > >>>> But consider this thought I just had
> today: the
> > RM
> > > doesn't really
> > > >>>> have to choose to do all 100 commands on a
> local
> > machine
> > > or with Ant
> > > >>>> scripts or do the first 40 via CI. The RM can
> > actually
> > > pick and choose
> > > >>>> commands to run on the CI server. The CI
> Jenkins
> > jobs
> > > are not a
> > > >>>> separate/alternative release process, they
> are just
> > > another way of
> > > >>>> executing the first 40 steps. Using CI jobs
> > actually
> > > requires
> > > >> additional
> > > >>>> command-line cut-and-paste to push commits on
> the CI
> > > server and to sign
> > > >> and
> > > >>>> validate binaries locally, but that's the
> trade-off
> > of
> > > not having to
> > > >>>> configure your machine to successfully run
> all of
> > the
> > > automated tests
> > > >> and
> > > >>>> build systems, and being able to run a
> command by
> > filling
> > > in the version
> > > >>>> number and rc number and hitting the "ok"
> button
> > instead
> > > of making sure
> > > >> you
> > > >>>> got the whole command typed in correctly.
> > > >>>>
> > > >>>> So, an RM can run the first 25 steps
> locally,
> > then go
> > > the CI server
> > > >>>> and run what is now Jenkins Job
> > "Royale_Release_Step_013"
> > > (no need to
> > > >> run
> > > >>>> the first 12) and it will run tasks 26
> through 32,
> > and if
> > > it is
> > > >> successful,
> > > >>>> then the RM has proven code coverage of the
> > build.xml
> > > files. (If the
> > > >>>> resulting tar.gz and zips are not posted,
> then the
> > RM
> > > should verify that
> > > >>>> they match the ones from Maven
> distribution). I
> > would
> > > encourage RMs to
> > > >>>> also use the CI jobs that generate the emails
> to
> > make
> > > sure the subject
> > > >> and
> > > >>>> content is correct and contains the usual
> > instructions so
> > > we have
> > > >>>> consistency. Maybe someday there will be CI
> jobs
> > to do
> > > the last 60+
> > > >> steps
> > > >>>> if that helps. We could add a Jenkins job
> that
> > runs an
> > > Ant build on RC
> > > >>>> artifacts on dist.a.o as well.
> > > >>>>
> > > >>>> I would like you all to help maintain the
> list of
> > 100
> > > steps and other
> > > >>>> documents related to the release process, and
> > improve the
> > > CI jobs and
> > > >> Ant
> > > >>>> steps if it helps you be a more efficient
> RM. I am
> > > hopeful that now
> > > >> that I
> > > >>>> have hopefully explained our release process
> > better, that
> > > we can see
> > > >> that
> > > >>>> these 100+ steps just have to be done in some
> way.
> > The
> > > RM can figure
> > > >> out
> > > >>>> what way works best for them, but they must
> get
> > through
> > > all of them.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> -Alex
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> --
> > > >>> Carlos Rovira
> > > >>>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > > >>
> > > >>
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
trying to summarize again with this plan seems to me unnecessary, in a way
that maybe until now nobody exposed and could be the key to understand the
problem:
if we ask ourselves: "Are we generating the same artifacts between build
systems at bit level?", the response is "No". They should be mostly the
same for an user to work with it, but after working on a release it was
clear to me that each build system has its own "idiosyncrasy" (to say it
some way), since we us to have files like metainfs, xmls, or other things
that are not generated the same way.
"are we creating reproducible builds?". "No". Since the compiler is not
prepared for it. Due to differences in OS (and possibly JDK Vendor) the
order generated in some files is different (as already exposed many days
ago). So reproducible builds in 0.9.6 are not real. "what needs to be made
to have reproducible builds?". "Fix the compiler is needed to implement
it".
Far beyond, "If we fix the compiler to have real reproducible builds will
we have reproducible builds between build systems?". "No, will be only
reproducible from a concrete build system perspective". So builds for Ant
are reproducible for Ant, and builds done with Maven are reproducible with
Maven, but are not comparable between them due to latest point, each build
system generate slightly different artifacts. Checking jars for binary
equality will fail (just opening with a tool like intellij will show you
the problem easily).
(subsection: since reproducibility seems more work we can left for post
1.0.0)
So "if you make a release using one build system have sense to mix with
other build system during the release?", "No, since as we are creating
different artifacts, just running a full build, when release is done, to
test the rest of build systems are working is enough to check it". Or "it
no has sense to do release steps for all build systems since we just need
to push one set of artifacts and we are really not checking any relation
between them since are different things at byte level although can work the
same for an user"
If the problem is to save time to the rest of people verifying the release,
the RM can do a full build with *all* build systems to check the integrity
and that build systems are working as we all expect, so RCs are in the same
state as running the 100 steps. That will far easy and quick than doing 100
commands that really are not performing what we expect from what I
explained here.
In resume, both ways are the same, since reproducible builds are only
affecting to the build system from what you're building and the so-called
"reproducible artifacts" and not "comparable" with same artifacts generated
by other build systems, so artifacts done with different systems are
essentially (bit level) not equal).
If after all the evidences exposed here, you still insists in impose a 100
command recipe, I honestly will not understand.
In exchange, if you (or other) feels better doing 100 commands when acting
as RM, is completely up to you, while don't try to impose to the rest of
the project.
HTH
Thanks
Carlos
El vie., 3 abr. 2020 a las 6:35, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I honestly can't think of any steps we can do without. If you can explain
> technically why some step isn't needed, then we can discuss it. I'm sorry
> you don't agree. I hope the rest of the PMC will agree that we have to do
> all of these steps and support the RM in doing so.
>
> One way to not have to actually type 90+ command is to use the Ant steps
> or CI jobs. Ideas on how to do less typing to execute these 90+ commands
> are welcome.
>
> -Alex
>
> On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> sincerely, I don't understand that, and was not what I understand for
> your
> first email. I must say that I completely disagree that we need to do
> 90 or
> 100 commands to get a release that should be around 15. I think we
> have a
> problem with what we really need here.
>
> Maybe the solution is to get some external mediator that have a good
> experience with multiple build systems and releases and could give us
> his
> opinion from outside, so we can have the most logic option. I think if
> we
> can get someone that could give a hand could be very good for us.
>
> Can we ask in Apache for someone that review it? Maybe this will be the
> only solution to avoid going in circles again, since I'm afraid that my
> response will not be what you expect, but sorry, don't see this as you.
>
> I think this shouldn't be a requirement to all RMs, so people that
> wants to
> do all that commands can do it, but I sincerely prefer to stick with
> the
> recipe that is the current standard in all projects (even the ones that
> have more than one build systems). Take for sure that if I see a need
> to do
> all of that I'll be glad to do it. But sincerily is something I don't
> share.
>
> Anyway for people that wants to do that kind of checking I think you
> get a
> good advance from the previous solution.
>
> Thanks
>
>
>
>
>
>
>
> El jue., 2 abr. 2020 a las 21:50, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > Hi Carlos,
> >
> > The command lines in [1] have been added to [2]. [1] is only a
> partial
> > list of the things to do, but includes some helpful setup information
> > Hopefully in June we won't need to release build-tools so you will
> only
> > have about 90 steps to do, but we may have added more commands as we
> > improve our automated test infrastructure.
> >
> > HTH,
> > -Alex
> >
> > [2]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> >
> > On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > to understand your long email. Lets say that when I'll go to
> release in
> > June (0.9.9), I'll use instructions described in [1].
> > So that will create the sources needed to post. Then, to avouid
> later
> > problems for people verifying I'll verify it with Maven and Ant
> (build
> > with
> > both, and test SDK generated in example apps. Then push to
> dist.a.o,
> > create
> > discuss and vote threads, and start the vote.
> >
> > Is that ok?
> >
> > Thanks
> >
> > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=IBIgHvzutG7YtH27kxyD5tyaQyjBe6QetVWWsrSxF9w%3D&reserved=0
> >
> > El jue., 2 abr. 2020 a las 19:16, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > escribió:
> >
> > > I'm not sure I understand the distinction. I think we want to
> do
> > both.
> > > The goal of code coverage is to try to exercise paths. We
> want to
> > run "ant
> > > release" because our Ant users might want to do that. And Ant
> does
> > have
> > > assertions AFAICT. It will report errors. Meanwhile, the
> standard
> > for
> > > the .tar.gz package is the one produced by "ant release"
> because
> > that's the
> > > recipe we've been using for years now. The Maven
> distribution's
> > .tar.gz
> > > has been shown to work in most cases, but AFAICT, is nearly as
> well
> > tested
> > > and has not been binary-compared. Ways to compare the two
> .tar.gz
> > files
> > > are needed and welcome.
> > >
> > > More and better tests are welcome.
> > >
> > > Do we have agreement? It sounds like it. So I will now be
> spending
> > my
> > > evenings on the release instead of writing lists of 100 things.
> > >
> > > -Alex
> > >
> > > On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com>
> wrote:
> > >
> > > Chris, I think you’re missing Alex’s point. We’re not
> running
> > Ant to
> > > make sure it doesn’t blow up. We’re running it to make sure the
> > resultant
> > > tar.gz/zip files are identical to the ones created by Maven.
> Alex,
> > please
> > > correct me if I’m wrong.
> > >
> > > ________________________________
> > > From: Christofer Dutz <ch...@c-ware.de>
> > > Sent: Thursday, April 2, 2020 4:42:00 PM
> > > To: dev@royale.apache.org <de...@royale.apache.org>
> > > Subject: Re: Royale Releases
> > >
> > > And to add a little to that [1]
> > >
> > > "In computer science, test coverage is a measure used to
> > describe the
> > > degree to which the source code of a program is executed when a
> > particular
> > > test suite runs."
> > >
> > > So no test, no coverage. Just using something and it's not
> > blowing up
> > > isn't a test for me. It's better than nothing however.
> > >
> > > Chris
> > >
> > >
> > >
> > > [1]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=ohLzW9qtDjCrsy8mHX47Z2qkWR4me5giS%2BSEGSUSWKQ%3D&reserved=0
> > >
> > > Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> > > christofer.dutz@c-ware.de>:
> > >
> > > Hi folks,
> > >
> > > I would say we have coverage for both maven ant
> equally as
> > we're
> > > building the same code.
> > >
> > > However we are missing the important assertions. It's
> not
> > that the
> > > Ant build is running some tests Maven isn't.
> > > It's just that the settings for Ant seem to be
> different
> > than for
> > > Maven and the Ant ones happen to work.
> > >
> > > Ideally there would be real tests that test the output
> of
> > both to
> > > see if it works in both cases.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 02.04.20, 15:15 schrieb "Harbs" <
> harbs.lists@gmail.com>:
> > >
> > > Adding more coverage for Maven is good.
> > >
> > > Removing coverage for Ant is not.
> > >
> > > Do you agree?
> > >
> > > > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> > > carlosrovira@apache.org> wrote:
> > > >
> > > > Hi Harbs,
> > > >
> > > > I think what we're trying to say is that until
> now we
> > > released with Maven
> > > > and Ant, and that was hiding a flaw in Maven (SVG
> > example).
> > > So that means
> > > > what we were trying to cover was not covered
> clearly,
> > so the
> > > premise is not
> > > > right.
> > > >
> > > >
> > > >
> > > > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> > > harbs.lists@gmail.com>) escribió:
> > > >
> > > >> No one is arguing that we shouldn’t add more
> tests.
> > > >>
> > > >> Please let’s not make it seem like there’s a
> > disagreement
> > > about that.
> > > >>
> > > >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> > > carlosrovira@apache.org>
> > > >> wrote:
> > > >>>
> > > >>> Hi Alex,
> > > >>>
> > > >>> first, many thanks for the detailed email. I'll
> > comment on
> > > this later as
> > > >> I
> > > >>> have more time.
> > > >>>
> > > >>> For now, to add up a recent example on what
> Chris
> > > commented: If you all
> > > >>> remember a week ago I was trying to use SVG
> Images
> > in a
> > > blog example that
> > > >>> was published 2 days ago. Nobody tried SVG
> Images
> > before
> > > building with
> > > >>> maven, I know that since maven was not properly
> > configured
> > > and using that
> > > >>> component from Maven was failing with an RTE.
> > Probably we
> > > have more
> > > >> things
> > > >>> not working the same way when build from Maven
> and
> > Ant,
> > > and that's
> > > >>> something that will need people using that code
> > paths in
> > > test
> > > >> applications
> > > >>> (or in their own apps) to see if things works
> > properly.
> > > >>>
> > > >>> I was recently introduced to
> > "examples-integrationtest" by
> > > Chris, that I
> > > >>> plan to use soon as I can. I think is a great
> idea,
> > since
> > > you get a
> > > >> Firefox
> > > >>> running test interface of the real use of some
> > concrete
> > > royale code. I
> > > >>> think passed until now unnoticed by all of us,
> and
> > seems a
> > > powerful tool.
> > > >>> There's already an example about FlexStore
> with some
> > basic
> > > assertions.
> > > >>>
> > > >>> Again, thanks, and will comment on the rest
> later
> > > >>>
> > > >>> Carlos
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> El jue., 2 abr. 2020 a las 9:20, Christofer
> Dutz (<
> > > >> christofer.dutz@c-ware.de>)
> > > >>> escribió:
> > > >>>
> > > >>>> Hi Alex,
> > > >>>>
> > > >>>> just a point you are bringing up: "Code
> coverage".
> > > >>>>
> > > >>>> I strongly dislike the idea of "asjs"
> effectively
> > being
> > > the test for the
> > > >>>> compiler. The reasoning behind this is: yes
> you do
> > get
> > > more code
> > > >> covered,
> > > >>>> but only the happy-path (ideally) and even if
> > things go
> > > wrong, the end
> > > >>>> results aren't tested. Did add a module to
> asjs
> > years ago
> > > >>>> ("examples-integrationtest") that deployed the
> > examples
> > > in a tomcat
> > > >> server
> > > >>>> then opens a Firefox browser and clicks
> through 2
> > of the
> > > examples (I
> > > >> added
> > > >>>> two dummy tests as an example, but seems no
> one
> > touched
> > > this after me).
> > > >> I
> > > >>>> did this because I remember us working on
> asjs for
> > weeks
> > > without anyone
> > > >>>> noticing the compiler wasn't producing
> runnable
> > code ...
> > > same with the
> > > >>>> little unit-tests that are still run for every
> > example,
> > > that simply
> > > >> check
> > > >>>> if an output is generated, because we had a
> > prolonged
> > > period of time
> > > >> where
> > > >>>> we were all working on different parts, but
> for
> > quite
> > > some time the
> > > >>>> application compilation just didn't output
> anything
> > and
> > > no one noticed.
> > > >>>>
> > > >>>> So coverage is nothing without assertions (my
> > opinion)
> > > ... ok ... it's
> > > >>>> slightly better than no coverage, but not
> much, in
> > my
> > > opinion.
> > > >>>>
> > > >>>> I think in parallel to this release
> discussions I
> > have
> > > seen numerous
> > > >>>> threads about someone doing something that
> broke
> > > something for someone
> > > >>>> else. This could be addressed by increasing
> > coverage by
> > > providing
> > > >> explicit
> > > >>>> tests.
> > > >>>>
> > > >>>> Coming back to the releases:
> > > >>>> I have no objections, if you do a "release"
> locally
> > and
> > > automate the
> > > >>>> validation on the CI server (Which effectively
> > would be
> > > your proposal
> > > >> to do
> > > >>>> the first 12 steps on local hardware and the
> 13th
> > on the
> > > CI server). I
> > > >> even
> > > >>>> think that's a good idea ... There could be
> one
> > step for
> > > building a
> > > >> release
> > > >>>> from a given "git tag" for every build system
> and
> > generic
> > > means to
> > > >> compare
> > > >>>> tar.gz and zips produced by any build system
> with
> > that of
> > > another
> > > >> (ideally
> > > >>>> with better output than just a plain
> "true/false").
> > This
> > > would even
> > > >> help to
> > > >>>> iron out the last potentially existing bumps
> out of
> > the
> > > Maven
> > > >> distribution.
> > > >>>>
> > > >>>> Chris
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> > > <ah...@adobe.com.INVALID>:
> > > >>>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> This is my attempt to explain what goes
> into a
> > release
> > > in hopes that
> > > >>>> we can understand and agree on what our
> release
> > process
> > > is. It became
> > > >>>> apparent in my reading of the wiki page with
> the new
> > > Maven steps and in
> > > >>>> talking with Harbs today that there are still
> many
> > > misunderstandings
> > > >> about
> > > >>>> what we do to create a release. I don't
> generally
> > like
> > > writing
> > > >>>> instructions in English because it is easy to
> be
> > > ambiguous. All of the
> > > >>>> steps that we use to create releases had been
> > captured in
> > > Ant scripts
> > > >> in a
> > > >>>> much more explicit way, IMO, but I took the
> time to
> > write
> > > them down in
> > > >>>> English here:
> > > >>>>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> > > >>>>
> > > >>>> I did this quickly by scanning the CI
> steps, the
> > new
> > > Maven steps and
> > > >>>> the Ant scripts used in prior releases so
> there
> > could
> > > certainly be
> > > >> mistakes
> > > >>>> and missed steps. If I did my math right,
> the RM
> > for
> > > 0.9.7 will have to
> > > >>>> complete over 100 tasks (essentially, typing a
> > > command-line 100 times).
> > > >>>> Future RMs, when we don't have to release
> > build-tools,
> > > will have about
> > > >> 92
> > > >>>> steps. And I did not include voter
> verification
> > checks
> > > the RM should
> > > >> run
> > > >>>> before opening a vote (verifying that the
> artifacts
> > > download and match
> > > >>>> their checksums, etc). As an RM, I run a
> bunch of
> > tests
> > > on the RC
> > > >> before
> > > >>>> sending out the vote. Maybe we should add
> those to
> > the
> > > task list.
> > > >>>>
> > > >>>> I think there has been confusion about the
> use of
> > Ant
> > > in the release
> > > >>>> process. Because I was the RM for the first
> set of
> > > FlexJS/Royale
> > > >> releases,
> > > >>>> and I'm a lazy person who hates typing at the
> > command
> > > line, I created
> > > >> Ant
> > > >>>> scripts to execute these 100 steps. But I
> agree
> > that it
> > > is not a
> > > >>>> requirement that other RMs must use the Ant
> scripts
> > for
> > > these
> > > >> commands. If
> > > >>>> you are the RM and like typing, go ahead.
> > > >>>>
> > > >>>> Then we found out that other people
> couldn't get
> > > through this task
> > > >>>> list. I think the 3 people who tried were
> having
> > trouble
> > > with Maven
> > > >>>> uploads and downloads. So what I did was put
> the
> > first
> > > 40 steps or so
> > > >> into
> > > >>>> Jenkins jobs. And by doing that, Piotr was
> able to
> > > produce our last
> > > >>>> release. And that also saves on manually
> typing
> > > commands. But again,
> > > >>>> going forward, the RM gets to choose how they
> want
> > to
> > > execute these
> > > >> steps.
> > > >>>>
> > > >>>> If you scan the set of steps, you'll see
> that
> > "ant" is
> > > only in there
> > > >>>> once. I believe the recent threads have been
> about
> > this
> > > single command
> > > >> out
> > > >>>> of the 100+ commands. This is why this has
> been so
> > > frustrating to me.
> > > >> I
> > > >>>> believe there is a solid technical reason for
> that
> > one
> > > command: it
> > > >> proves
> > > >>>> that the build.xml files in the source
> packages can
> > build
> > > the .tar.gz
> > > >> that
> > > >>>> are useful to NPM and IDE users who use Ant
> and
> > want to
> > > test a change.
> > > >>>>
> > > >>>> I think of it as code-coverage. If we had
> > > code-coverage tools, we
> > > >>>> would ask that the RM complete as much of the
> > automated
> > > code-coverage
> > > >>>> testing as possible before posting the
> release for a
> > > vote. That one
> > > >>>> command increases our code coverage by
> running the
> > > build.xml files. We
> > > >>>> should be always working to increase
> automated code
> > > coverage in the RC.
> > > >>>> Certainly for me as RM, I will gladly watch
> TV as
> > the
> > > automated tests
> > > >> run
> > > >>>> because a failed RC means going back through
> many
> > of the
> > > first 25
> > > >> commands
> > > >>>> again and wastes other people's time. Each
> RC is
> > more
> > > emails to read
> > > >> and
> > > >>>> more time from the voters and testers.
> > > >>>>
> > > >>>> If there are other ways for the RM to get
> the
> > same or
> > > better code
> > > >>>> coverage on the build.xml files before
> posting the
> > RC, we
> > > can discuss
> > > >> those
> > > >>>> options.
> > > >>>>
> > > >>>> I am hopeful we can all agree on these
> simple
> > > principles: Strive for
> > > >>>> better code coverage and fewer failed RCs.
> > Royale's main
> > > purpose is to
> > > >>>> save other people time. Let's do that in
> creating
> > > releases too.
> > > >>>>
> > > >>>> One issue that was brought up recently was
> > whether it
> > > is a good
> > > >>>> decision to have the RM test all of the build
> > platforms
> > > we support.
> > > >>>> Suppose we add some other build system
> support or
> > more in
> > > the future?
> > > >>>> Again, the code coverage principle applies
> here, but
> > > also, I would like
> > > >> us
> > > >>>> to retain feature parity, and I also hope for
> as
> > few RCs
> > > and votes as
> > > >>>> possible. So instead of having separate
> > > votes/features/release-dates
> > > >> for
> > > >>>> the Maven artifacts vs the Ant artifacts vs
> the
> > > SomeFutureBuildTech
> > > >>>> artifacts, I think we should have one vote
> and keep
> > them
> > > all in sync.
> > > >> If
> > > >>>> we do ever get around to monthly or bi-monthly
> > releases,
> > > I think
> > > >> separate
> > > >>>> build platform releases would be too much
> work.
> > > >>>>
> > > >>>> But consider this thought I just had
> today: the
> > RM
> > > doesn't really
> > > >>>> have to choose to do all 100 commands on a
> local
> > machine
> > > or with Ant
> > > >>>> scripts or do the first 40 via CI. The RM can
> > actually
> > > pick and choose
> > > >>>> commands to run on the CI server. The CI
> Jenkins
> > jobs
> > > are not a
> > > >>>> separate/alternative release process, they
> are just
> > > another way of
> > > >>>> executing the first 40 steps. Using CI jobs
> > actually
> > > requires
> > > >> additional
> > > >>>> command-line cut-and-paste to push commits on
> the CI
> > > server and to sign
> > > >> and
> > > >>>> validate binaries locally, but that's the
> trade-off
> > of
> > > not having to
> > > >>>> configure your machine to successfully run
> all of
> > the
> > > automated tests
> > > >> and
> > > >>>> build systems, and being able to run a
> command by
> > filling
> > > in the version
> > > >>>> number and rc number and hitting the "ok"
> button
> > instead
> > > of making sure
> > > >> you
> > > >>>> got the whole command typed in correctly.
> > > >>>>
> > > >>>> So, an RM can run the first 25 steps
> locally,
> > then go
> > > the CI server
> > > >>>> and run what is now Jenkins Job
> > "Royale_Release_Step_013"
> > > (no need to
> > > >> run
> > > >>>> the first 12) and it will run tasks 26
> through 32,
> > and if
> > > it is
> > > >> successful,
> > > >>>> then the RM has proven code coverage of the
> > build.xml
> > > files. (If the
> > > >>>> resulting tar.gz and zips are not posted,
> then the
> > RM
> > > should verify that
> > > >>>> they match the ones from Maven
> distribution). I
> > would
> > > encourage RMs to
> > > >>>> also use the CI jobs that generate the emails
> to
> > make
> > > sure the subject
> > > >> and
> > > >>>> content is correct and contains the usual
> > instructions so
> > > we have
> > > >>>> consistency. Maybe someday there will be CI
> jobs
> > to do
> > > the last 60+
> > > >> steps
> > > >>>> if that helps. We could add a Jenkins job
> that
> > runs an
> > > Ant build on RC
> > > >>>> artifacts on dist.a.o as well.
> > > >>>>
> > > >>>> I would like you all to help maintain the
> list of
> > 100
> > > steps and other
> > > >>>> documents related to the release process, and
> > improve the
> > > CI jobs and
> > > >> Ant
> > > >>>> steps if it helps you be a more efficient
> RM. I am
> > > hopeful that now
> > > >> that I
> > > >>>> have hopefully explained our release process
> > better, that
> > > we can see
> > > >> that
> > > >>>> these 100+ steps just have to be done in some
> way.
> > The
> > > RM can figure
> > > >> out
> > > >>>> what way works best for them, but they must
> get
> > through
> > > all of them.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> -Alex
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> --
> > > >>> Carlos Rovira
> > > >>>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > > >>
> > > >>
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I honestly can't think of any steps we can do without. If you can explain technically why some step isn't needed, then we can discuss it. I'm sorry you don't agree. I hope the rest of the PMC will agree that we have to do all of these steps and support the RM in doing so.
One way to not have to actually type 90+ command is to use the Ant steps or CI jobs. Ideas on how to do less typing to execute these 90+ commands are welcome.
-Alex
On 4/2/20, 4:22 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
sincerely, I don't understand that, and was not what I understand for your
first email. I must say that I completely disagree that we need to do 90 or
100 commands to get a release that should be around 15. I think we have a
problem with what we really need here.
Maybe the solution is to get some external mediator that have a good
experience with multiple build systems and releases and could give us his
opinion from outside, so we can have the most logic option. I think if we
can get someone that could give a hand could be very good for us.
Can we ask in Apache for someone that review it? Maybe this will be the
only solution to avoid going in circles again, since I'm afraid that my
response will not be what you expect, but sorry, don't see this as you.
I think this shouldn't be a requirement to all RMs, so people that wants to
do all that commands can do it, but I sincerely prefer to stick with the
recipe that is the current standard in all projects (even the ones that
have more than one build systems). Take for sure that if I see a need to do
all of that I'll be glad to do it. But sincerily is something I don't share.
Anyway for people that wants to do that kind of checking I think you get a
good advance from the previous solution.
Thanks
El jue., 2 abr. 2020 a las 21:50, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> The command lines in [1] have been added to [2]. [1] is only a partial
> list of the things to do, but includes some helpful setup information
> Hopefully in June we won't need to release build-tools so you will only
> have about 90 steps to do, but we may have added more commands as we
> improve our automated test infrastructure.
>
> HTH,
> -Alex
>
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
>
> On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> to understand your long email. Lets say that when I'll go to release in
> June (0.9.9), I'll use instructions described in [1].
> So that will create the sources needed to post. Then, to avouid later
> problems for people verifying I'll verify it with Maven and Ant (build
> with
> both, and test SDK generated in example apps. Then push to dist.a.o,
> create
> discuss and vote threads, and start the vote.
>
> Is that ok?
>
> Thanks
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=IBIgHvzutG7YtH27kxyD5tyaQyjBe6QetVWWsrSxF9w%3D&reserved=0
>
> El jue., 2 abr. 2020 a las 19:16, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > I'm not sure I understand the distinction. I think we want to do
> both.
> > The goal of code coverage is to try to exercise paths. We want to
> run "ant
> > release" because our Ant users might want to do that. And Ant does
> have
> > assertions AFAICT. It will report errors. Meanwhile, the standard
> for
> > the .tar.gz package is the one produced by "ant release" because
> that's the
> > recipe we've been using for years now. The Maven distribution's
> .tar.gz
> > has been shown to work in most cases, but AFAICT, is nearly as well
> tested
> > and has not been binary-compared. Ways to compare the two .tar.gz
> files
> > are needed and welcome.
> >
> > More and better tests are welcome.
> >
> > Do we have agreement? It sounds like it. So I will now be spending
> my
> > evenings on the release instead of writing lists of 100 things.
> >
> > -Alex
> >
> > On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
> >
> > Chris, I think you’re missing Alex’s point. We’re not running
> Ant to
> > make sure it doesn’t blow up. We’re running it to make sure the
> resultant
> > tar.gz/zip files are identical to the ones created by Maven. Alex,
> please
> > correct me if I’m wrong.
> >
> > ________________________________
> > From: Christofer Dutz <ch...@c-ware.de>
> > Sent: Thursday, April 2, 2020 4:42:00 PM
> > To: dev@royale.apache.org <de...@royale.apache.org>
> > Subject: Re: Royale Releases
> >
> > And to add a little to that [1]
> >
> > "In computer science, test coverage is a measure used to
> describe the
> > degree to which the source code of a program is executed when a
> particular
> > test suite runs."
> >
> > So no test, no coverage. Just using something and it's not
> blowing up
> > isn't a test for me. It's better than nothing however.
> >
> > Chris
> >
> >
> >
> > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=ohLzW9qtDjCrsy8mHX47Z2qkWR4me5giS%2BSEGSUSWKQ%3D&reserved=0
> >
> > Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> > christofer.dutz@c-ware.de>:
> >
> > Hi folks,
> >
> > I would say we have coverage for both maven ant equally as
> we're
> > building the same code.
> >
> > However we are missing the important assertions. It's not
> that the
> > Ant build is running some tests Maven isn't.
> > It's just that the settings for Ant seem to be different
> than for
> > Maven and the Ant ones happen to work.
> >
> > Ideally there would be real tests that test the output of
> both to
> > see if it works in both cases.
> >
> > Chris
> >
> >
> >
> > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> >
> > Adding more coverage for Maven is good.
> >
> > Removing coverage for Ant is not.
> >
> > Do you agree?
> >
> > > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> > carlosrovira@apache.org> wrote:
> > >
> > > Hi Harbs,
> > >
> > > I think what we're trying to say is that until now we
> > released with Maven
> > > and Ant, and that was hiding a flaw in Maven (SVG
> example).
> > So that means
> > > what we were trying to cover was not covered clearly,
> so the
> > premise is not
> > > right.
> > >
> > >
> > >
> > > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> > harbs.lists@gmail.com>) escribió:
> > >
> > >> No one is arguing that we shouldn’t add more tests.
> > >>
> > >> Please let’s not make it seem like there’s a
> disagreement
> > about that.
> > >>
> > >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> > carlosrovira@apache.org>
> > >> wrote:
> > >>>
> > >>> Hi Alex,
> > >>>
> > >>> first, many thanks for the detailed email. I'll
> comment on
> > this later as
> > >> I
> > >>> have more time.
> > >>>
> > >>> For now, to add up a recent example on what Chris
> > commented: If you all
> > >>> remember a week ago I was trying to use SVG Images
> in a
> > blog example that
> > >>> was published 2 days ago. Nobody tried SVG Images
> before
> > building with
> > >>> maven, I know that since maven was not properly
> configured
> > and using that
> > >>> component from Maven was failing with an RTE.
> Probably we
> > have more
> > >> things
> > >>> not working the same way when build from Maven and
> Ant,
> > and that's
> > >>> something that will need people using that code
> paths in
> > test
> > >> applications
> > >>> (or in their own apps) to see if things works
> properly.
> > >>>
> > >>> I was recently introduced to
> "examples-integrationtest" by
> > Chris, that I
> > >>> plan to use soon as I can. I think is a great idea,
> since
> > you get a
> > >> Firefox
> > >>> running test interface of the real use of some
> concrete
> > royale code. I
> > >>> think passed until now unnoticed by all of us, and
> seems a
> > powerful tool.
> > >>> There's already an example about FlexStore with some
> basic
> > assertions.
> > >>>
> > >>> Again, thanks, and will comment on the rest later
> > >>>
> > >>> Carlos
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > >> christofer.dutz@c-ware.de>)
> > >>> escribió:
> > >>>
> > >>>> Hi Alex,
> > >>>>
> > >>>> just a point you are bringing up: "Code coverage".
> > >>>>
> > >>>> I strongly dislike the idea of "asjs" effectively
> being
> > the test for the
> > >>>> compiler. The reasoning behind this is: yes you do
> get
> > more code
> > >> covered,
> > >>>> but only the happy-path (ideally) and even if
> things go
> > wrong, the end
> > >>>> results aren't tested. Did add a module to asjs
> years ago
> > >>>> ("examples-integrationtest") that deployed the
> examples
> > in a tomcat
> > >> server
> > >>>> then opens a Firefox browser and clicks through 2
> of the
> > examples (I
> > >> added
> > >>>> two dummy tests as an example, but seems no one
> touched
> > this after me).
> > >> I
> > >>>> did this because I remember us working on asjs for
> weeks
> > without anyone
> > >>>> noticing the compiler wasn't producing runnable
> code ...
> > same with the
> > >>>> little unit-tests that are still run for every
> example,
> > that simply
> > >> check
> > >>>> if an output is generated, because we had a
> prolonged
> > period of time
> > >> where
> > >>>> we were all working on different parts, but for
> quite
> > some time the
> > >>>> application compilation just didn't output anything
> and
> > no one noticed.
> > >>>>
> > >>>> So coverage is nothing without assertions (my
> opinion)
> > ... ok ... it's
> > >>>> slightly better than no coverage, but not much, in
> my
> > opinion.
> > >>>>
> > >>>> I think in parallel to this release discussions I
> have
> > seen numerous
> > >>>> threads about someone doing something that broke
> > something for someone
> > >>>> else. This could be addressed by increasing
> coverage by
> > providing
> > >> explicit
> > >>>> tests.
> > >>>>
> > >>>> Coming back to the releases:
> > >>>> I have no objections, if you do a "release" locally
> and
> > automate the
> > >>>> validation on the CI server (Which effectively
> would be
> > your proposal
> > >> to do
> > >>>> the first 12 steps on local hardware and the 13th
> on the
> > CI server). I
> > >> even
> > >>>> think that's a good idea ... There could be one
> step for
> > building a
> > >> release
> > >>>> from a given "git tag" for every build system and
> generic
> > means to
> > >> compare
> > >>>> tar.gz and zips produced by any build system with
> that of
> > another
> > >> (ideally
> > >>>> with better output than just a plain "true/false").
> This
> > would even
> > >> help to
> > >>>> iron out the last potentially existing bumps out of
> the
> > Maven
> > >> distribution.
> > >>>>
> > >>>> Chris
> > >>>>
> > >>>>
> > >>>>
> > >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> > <ah...@adobe.com.INVALID>:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> This is my attempt to explain what goes into a
> release
> > in hopes that
> > >>>> we can understand and agree on what our release
> process
> > is. It became
> > >>>> apparent in my reading of the wiki page with the new
> > Maven steps and in
> > >>>> talking with Harbs today that there are still many
> > misunderstandings
> > >> about
> > >>>> what we do to create a release. I don't generally
> like
> > writing
> > >>>> instructions in English because it is easy to be
> > ambiguous. All of the
> > >>>> steps that we use to create releases had been
> captured in
> > Ant scripts
> > >> in a
> > >>>> much more explicit way, IMO, but I took the time to
> write
> > them down in
> > >>>> English here:
> > >>>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=V%2BSDjqbnq0yRYrAGvGvVrLRPtdUWy4T0wXidpMx%2FgMU%3D&reserved=0
> > >>>>
> > >>>> I did this quickly by scanning the CI steps, the
> new
> > Maven steps and
> > >>>> the Ant scripts used in prior releases so there
> could
> > certainly be
> > >> mistakes
> > >>>> and missed steps. If I did my math right, the RM
> for
> > 0.9.7 will have to
> > >>>> complete over 100 tasks (essentially, typing a
> > command-line 100 times).
> > >>>> Future RMs, when we don't have to release
> build-tools,
> > will have about
> > >> 92
> > >>>> steps. And I did not include voter verification
> checks
> > the RM should
> > >> run
> > >>>> before opening a vote (verifying that the artifacts
> > download and match
> > >>>> their checksums, etc). As an RM, I run a bunch of
> tests
> > on the RC
> > >> before
> > >>>> sending out the vote. Maybe we should add those to
> the
> > task list.
> > >>>>
> > >>>> I think there has been confusion about the use of
> Ant
> > in the release
> > >>>> process. Because I was the RM for the first set of
> > FlexJS/Royale
> > >> releases,
> > >>>> and I'm a lazy person who hates typing at the
> command
> > line, I created
> > >> Ant
> > >>>> scripts to execute these 100 steps. But I agree
> that it
> > is not a
> > >>>> requirement that other RMs must use the Ant scripts
> for
> > these
> > >> commands. If
> > >>>> you are the RM and like typing, go ahead.
> > >>>>
> > >>>> Then we found out that other people couldn't get
> > through this task
> > >>>> list. I think the 3 people who tried were having
> trouble
> > with Maven
> > >>>> uploads and downloads. So what I did was put the
> first
> > 40 steps or so
> > >> into
> > >>>> Jenkins jobs. And by doing that, Piotr was able to
> > produce our last
> > >>>> release. And that also saves on manually typing
> > commands. But again,
> > >>>> going forward, the RM gets to choose how they want
> to
> > execute these
> > >> steps.
> > >>>>
> > >>>> If you scan the set of steps, you'll see that
> "ant" is
> > only in there
> > >>>> once. I believe the recent threads have been about
> this
> > single command
> > >> out
> > >>>> of the 100+ commands. This is why this has been so
> > frustrating to me.
> > >> I
> > >>>> believe there is a solid technical reason for that
> one
> > command: it
> > >> proves
> > >>>> that the build.xml files in the source packages can
> build
> > the .tar.gz
> > >> that
> > >>>> are useful to NPM and IDE users who use Ant and
> want to
> > test a change.
> > >>>>
> > >>>> I think of it as code-coverage. If we had
> > code-coverage tools, we
> > >>>> would ask that the RM complete as much of the
> automated
> > code-coverage
> > >>>> testing as possible before posting the release for a
> > vote. That one
> > >>>> command increases our code coverage by running the
> > build.xml files. We
> > >>>> should be always working to increase automated code
> > coverage in the RC.
> > >>>> Certainly for me as RM, I will gladly watch TV as
> the
> > automated tests
> > >> run
> > >>>> because a failed RC means going back through many
> of the
> > first 25
> > >> commands
> > >>>> again and wastes other people's time. Each RC is
> more
> > emails to read
> > >> and
> > >>>> more time from the voters and testers.
> > >>>>
> > >>>> If there are other ways for the RM to get the
> same or
> > better code
> > >>>> coverage on the build.xml files before posting the
> RC, we
> > can discuss
> > >> those
> > >>>> options.
> > >>>>
> > >>>> I am hopeful we can all agree on these simple
> > principles: Strive for
> > >>>> better code coverage and fewer failed RCs.
> Royale's main
> > purpose is to
> > >>>> save other people time. Let's do that in creating
> > releases too.
> > >>>>
> > >>>> One issue that was brought up recently was
> whether it
> > is a good
> > >>>> decision to have the RM test all of the build
> platforms
> > we support.
> > >>>> Suppose we add some other build system support or
> more in
> > the future?
> > >>>> Again, the code coverage principle applies here, but
> > also, I would like
> > >> us
> > >>>> to retain feature parity, and I also hope for as
> few RCs
> > and votes as
> > >>>> possible. So instead of having separate
> > votes/features/release-dates
> > >> for
> > >>>> the Maven artifacts vs the Ant artifacts vs the
> > SomeFutureBuildTech
> > >>>> artifacts, I think we should have one vote and keep
> them
> > all in sync.
> > >> If
> > >>>> we do ever get around to monthly or bi-monthly
> releases,
> > I think
> > >> separate
> > >>>> build platform releases would be too much work.
> > >>>>
> > >>>> But consider this thought I just had today: the
> RM
> > doesn't really
> > >>>> have to choose to do all 100 commands on a local
> machine
> > or with Ant
> > >>>> scripts or do the first 40 via CI. The RM can
> actually
> > pick and choose
> > >>>> commands to run on the CI server. The CI Jenkins
> jobs
> > are not a
> > >>>> separate/alternative release process, they are just
> > another way of
> > >>>> executing the first 40 steps. Using CI jobs
> actually
> > requires
> > >> additional
> > >>>> command-line cut-and-paste to push commits on the CI
> > server and to sign
> > >> and
> > >>>> validate binaries locally, but that's the trade-off
> of
> > not having to
> > >>>> configure your machine to successfully run all of
> the
> > automated tests
> > >> and
> > >>>> build systems, and being able to run a command by
> filling
> > in the version
> > >>>> number and rc number and hitting the "ok" button
> instead
> > of making sure
> > >> you
> > >>>> got the whole command typed in correctly.
> > >>>>
> > >>>> So, an RM can run the first 25 steps locally,
> then go
> > the CI server
> > >>>> and run what is now Jenkins Job
> "Royale_Release_Step_013"
> > (no need to
> > >> run
> > >>>> the first 12) and it will run tasks 26 through 32,
> and if
> > it is
> > >> successful,
> > >>>> then the RM has proven code coverage of the
> build.xml
> > files. (If the
> > >>>> resulting tar.gz and zips are not posted, then the
> RM
> > should verify that
> > >>>> they match the ones from Maven distribution). I
> would
> > encourage RMs to
> > >>>> also use the CI jobs that generate the emails to
> make
> > sure the subject
> > >> and
> > >>>> content is correct and contains the usual
> instructions so
> > we have
> > >>>> consistency. Maybe someday there will be CI jobs
> to do
> > the last 60+
> > >> steps
> > >>>> if that helps. We could add a Jenkins job that
> runs an
> > Ant build on RC
> > >>>> artifacts on dist.a.o as well.
> > >>>>
> > >>>> I would like you all to help maintain the list of
> 100
> > steps and other
> > >>>> documents related to the release process, and
> improve the
> > CI jobs and
> > >> Ant
> > >>>> steps if it helps you be a more efficient RM. I am
> > hopeful that now
> > >> that I
> > >>>> have hopefully explained our release process
> better, that
> > we can see
> > >> that
> > >>>> these 100+ steps just have to be done in some way.
> The
> > RM can figure
> > >> out
> > >>>> what way works best for them, but they must get
> through
> > all of them.
> > >>>>
> > >>>> Thanks,
> > >>>> -Alex
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Carlos Rovira
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ccdfb6a3f66b34452025f08d7d75cc39d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214665746612222&sdata=TH74uNC5GsYB4%2BS3d2SCU4Ckwi8WbszDDTVXurLfAqc%3D&reserved=0
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
sincerely, I don't understand that, and was not what I understand for your
first email. I must say that I completely disagree that we need to do 90 or
100 commands to get a release that should be around 15. I think we have a
problem with what we really need here.
Maybe the solution is to get some external mediator that have a good
experience with multiple build systems and releases and could give us his
opinion from outside, so we can have the most logic option. I think if we
can get someone that could give a hand could be very good for us.
Can we ask in Apache for someone that review it? Maybe this will be the
only solution to avoid going in circles again, since I'm afraid that my
response will not be what you expect, but sorry, don't see this as you.
I think this shouldn't be a requirement to all RMs, so people that wants to
do all that commands can do it, but I sincerely prefer to stick with the
recipe that is the current standard in all projects (even the ones that
have more than one build systems). Take for sure that if I see a need to do
all of that I'll be glad to do it. But sincerily is something I don't share.
Anyway for people that wants to do that kind of checking I think you get a
good advance from the previous solution.
Thanks
El jue., 2 abr. 2020 a las 21:50, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> The command lines in [1] have been added to [2]. [1] is only a partial
> list of the things to do, but includes some helpful setup information
> Hopefully in June we won't need to release build-tools so you will only
> have about 90 steps to do, but we may have added more commands as we
> improve our automated test infrastructure.
>
> HTH,
> -Alex
>
> [2]
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>
> On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> to understand your long email. Lets say that when I'll go to release in
> June (0.9.9), I'll use instructions described in [1].
> So that will create the sources needed to post. Then, to avouid later
> problems for people verifying I'll verify it with Maven and Ant (build
> with
> both, and test SDK generated in example apps. Then push to dist.a.o,
> create
> discuss and vote threads, and start the vote.
>
> Is that ok?
>
> Thanks
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165851458&sdata=mqhHe7LrUmASFs1EH7Bd18g7TOyU9CGm8Sqz1XiZzrA%3D&reserved=0
>
> El jue., 2 abr. 2020 a las 19:16, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > I'm not sure I understand the distinction. I think we want to do
> both.
> > The goal of code coverage is to try to exercise paths. We want to
> run "ant
> > release" because our Ant users might want to do that. And Ant does
> have
> > assertions AFAICT. It will report errors. Meanwhile, the standard
> for
> > the .tar.gz package is the one produced by "ant release" because
> that's the
> > recipe we've been using for years now. The Maven distribution's
> .tar.gz
> > has been shown to work in most cases, but AFAICT, is nearly as well
> tested
> > and has not been binary-compared. Ways to compare the two .tar.gz
> files
> > are needed and welcome.
> >
> > More and better tests are welcome.
> >
> > Do we have agreement? It sounds like it. So I will now be spending
> my
> > evenings on the release instead of writing lists of 100 things.
> >
> > -Alex
> >
> > On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
> >
> > Chris, I think you’re missing Alex’s point. We’re not running
> Ant to
> > make sure it doesn’t blow up. We’re running it to make sure the
> resultant
> > tar.gz/zip files are identical to the ones created by Maven. Alex,
> please
> > correct me if I’m wrong.
> >
> > ________________________________
> > From: Christofer Dutz <ch...@c-ware.de>
> > Sent: Thursday, April 2, 2020 4:42:00 PM
> > To: dev@royale.apache.org <de...@royale.apache.org>
> > Subject: Re: Royale Releases
> >
> > And to add a little to that [1]
> >
> > "In computer science, test coverage is a measure used to
> describe the
> > degree to which the source code of a program is executed when a
> particular
> > test suite runs."
> >
> > So no test, no coverage. Just using something and it's not
> blowing up
> > isn't a test for me. It's better than nothing however.
> >
> > Chris
> >
> >
> >
> > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165851458&sdata=%2FlsJ%2FKEJn%2FEVGIsq%2Bja%2FcCrS7yIF6PRw7o0c%2FYE0tcY%3D&reserved=0
> >
> > Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> > christofer.dutz@c-ware.de>:
> >
> > Hi folks,
> >
> > I would say we have coverage for both maven ant equally as
> we're
> > building the same code.
> >
> > However we are missing the important assertions. It's not
> that the
> > Ant build is running some tests Maven isn't.
> > It's just that the settings for Ant seem to be different
> than for
> > Maven and the Ant ones happen to work.
> >
> > Ideally there would be real tests that test the output of
> both to
> > see if it works in both cases.
> >
> > Chris
> >
> >
> >
> > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> >
> > Adding more coverage for Maven is good.
> >
> > Removing coverage for Ant is not.
> >
> > Do you agree?
> >
> > > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> > carlosrovira@apache.org> wrote:
> > >
> > > Hi Harbs,
> > >
> > > I think what we're trying to say is that until now we
> > released with Maven
> > > and Ant, and that was hiding a flaw in Maven (SVG
> example).
> > So that means
> > > what we were trying to cover was not covered clearly,
> so the
> > premise is not
> > > right.
> > >
> > >
> > >
> > > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> > harbs.lists@gmail.com>) escribió:
> > >
> > >> No one is arguing that we shouldn’t add more tests.
> > >>
> > >> Please let’s not make it seem like there’s a
> disagreement
> > about that.
> > >>
> > >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> > carlosrovira@apache.org>
> > >> wrote:
> > >>>
> > >>> Hi Alex,
> > >>>
> > >>> first, many thanks for the detailed email. I'll
> comment on
> > this later as
> > >> I
> > >>> have more time.
> > >>>
> > >>> For now, to add up a recent example on what Chris
> > commented: If you all
> > >>> remember a week ago I was trying to use SVG Images
> in a
> > blog example that
> > >>> was published 2 days ago. Nobody tried SVG Images
> before
> > building with
> > >>> maven, I know that since maven was not properly
> configured
> > and using that
> > >>> component from Maven was failing with an RTE.
> Probably we
> > have more
> > >> things
> > >>> not working the same way when build from Maven and
> Ant,
> > and that's
> > >>> something that will need people using that code
> paths in
> > test
> > >> applications
> > >>> (or in their own apps) to see if things works
> properly.
> > >>>
> > >>> I was recently introduced to
> "examples-integrationtest" by
> > Chris, that I
> > >>> plan to use soon as I can. I think is a great idea,
> since
> > you get a
> > >> Firefox
> > >>> running test interface of the real use of some
> concrete
> > royale code. I
> > >>> think passed until now unnoticed by all of us, and
> seems a
> > powerful tool.
> > >>> There's already an example about FlexStore with some
> basic
> > assertions.
> > >>>
> > >>> Again, thanks, and will comment on the rest later
> > >>>
> > >>> Carlos
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > >> christofer.dutz@c-ware.de>)
> > >>> escribió:
> > >>>
> > >>>> Hi Alex,
> > >>>>
> > >>>> just a point you are bringing up: "Code coverage".
> > >>>>
> > >>>> I strongly dislike the idea of "asjs" effectively
> being
> > the test for the
> > >>>> compiler. The reasoning behind this is: yes you do
> get
> > more code
> > >> covered,
> > >>>> but only the happy-path (ideally) and even if
> things go
> > wrong, the end
> > >>>> results aren't tested. Did add a module to asjs
> years ago
> > >>>> ("examples-integrationtest") that deployed the
> examples
> > in a tomcat
> > >> server
> > >>>> then opens a Firefox browser and clicks through 2
> of the
> > examples (I
> > >> added
> > >>>> two dummy tests as an example, but seems no one
> touched
> > this after me).
> > >> I
> > >>>> did this because I remember us working on asjs for
> weeks
> > without anyone
> > >>>> noticing the compiler wasn't producing runnable
> code ...
> > same with the
> > >>>> little unit-tests that are still run for every
> example,
> > that simply
> > >> check
> > >>>> if an output is generated, because we had a
> prolonged
> > period of time
> > >> where
> > >>>> we were all working on different parts, but for
> quite
> > some time the
> > >>>> application compilation just didn't output anything
> and
> > no one noticed.
> > >>>>
> > >>>> So coverage is nothing without assertions (my
> opinion)
> > ... ok ... it's
> > >>>> slightly better than no coverage, but not much, in
> my
> > opinion.
> > >>>>
> > >>>> I think in parallel to this release discussions I
> have
> > seen numerous
> > >>>> threads about someone doing something that broke
> > something for someone
> > >>>> else. This could be addressed by increasing
> coverage by
> > providing
> > >> explicit
> > >>>> tests.
> > >>>>
> > >>>> Coming back to the releases:
> > >>>> I have no objections, if you do a "release" locally
> and
> > automate the
> > >>>> validation on the CI server (Which effectively
> would be
> > your proposal
> > >> to do
> > >>>> the first 12 steps on local hardware and the 13th
> on the
> > CI server). I
> > >> even
> > >>>> think that's a good idea ... There could be one
> step for
> > building a
> > >> release
> > >>>> from a given "git tag" for every build system and
> generic
> > means to
> > >> compare
> > >>>> tar.gz and zips produced by any build system with
> that of
> > another
> > >> (ideally
> > >>>> with better output than just a plain "true/false").
> This
> > would even
> > >> help to
> > >>>> iron out the last potentially existing bumps out of
> the
> > Maven
> > >> distribution.
> > >>>>
> > >>>> Chris
> > >>>>
> > >>>>
> > >>>>
> > >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> > <ah...@adobe.com.INVALID>:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> This is my attempt to explain what goes into a
> release
> > in hopes that
> > >>>> we can understand and agree on what our release
> process
> > is. It became
> > >>>> apparent in my reading of the wiki page with the new
> > Maven steps and in
> > >>>> talking with Harbs today that there are still many
> > misunderstandings
> > >> about
> > >>>> what we do to create a release. I don't generally
> like
> > writing
> > >>>> instructions in English because it is easy to be
> > ambiguous. All of the
> > >>>> steps that we use to create releases had been
> captured in
> > Ant scripts
> > >> in a
> > >>>> much more explicit way, IMO, but I took the time to
> write
> > them down in
> > >>>> English here:
> > >>>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=cjnIpo4zXOc1abhUTDRE2O8IqQ5%2Baxn%2B9JSiX%2Bfmv1c%3D&reserved=0
> > >>>>
> > >>>> I did this quickly by scanning the CI steps, the
> new
> > Maven steps and
> > >>>> the Ant scripts used in prior releases so there
> could
> > certainly be
> > >> mistakes
> > >>>> and missed steps. If I did my math right, the RM
> for
> > 0.9.7 will have to
> > >>>> complete over 100 tasks (essentially, typing a
> > command-line 100 times).
> > >>>> Future RMs, when we don't have to release
> build-tools,
> > will have about
> > >> 92
> > >>>> steps. And I did not include voter verification
> checks
> > the RM should
> > >> run
> > >>>> before opening a vote (verifying that the artifacts
> > download and match
> > >>>> their checksums, etc). As an RM, I run a bunch of
> tests
> > on the RC
> > >> before
> > >>>> sending out the vote. Maybe we should add those to
> the
> > task list.
> > >>>>
> > >>>> I think there has been confusion about the use of
> Ant
> > in the release
> > >>>> process. Because I was the RM for the first set of
> > FlexJS/Royale
> > >> releases,
> > >>>> and I'm a lazy person who hates typing at the
> command
> > line, I created
> > >> Ant
> > >>>> scripts to execute these 100 steps. But I agree
> that it
> > is not a
> > >>>> requirement that other RMs must use the Ant scripts
> for
> > these
> > >> commands. If
> > >>>> you are the RM and like typing, go ahead.
> > >>>>
> > >>>> Then we found out that other people couldn't get
> > through this task
> > >>>> list. I think the 3 people who tried were having
> trouble
> > with Maven
> > >>>> uploads and downloads. So what I did was put the
> first
> > 40 steps or so
> > >> into
> > >>>> Jenkins jobs. And by doing that, Piotr was able to
> > produce our last
> > >>>> release. And that also saves on manually typing
> > commands. But again,
> > >>>> going forward, the RM gets to choose how they want
> to
> > execute these
> > >> steps.
> > >>>>
> > >>>> If you scan the set of steps, you'll see that
> "ant" is
> > only in there
> > >>>> once. I believe the recent threads have been about
> this
> > single command
> > >> out
> > >>>> of the 100+ commands. This is why this has been so
> > frustrating to me.
> > >> I
> > >>>> believe there is a solid technical reason for that
> one
> > command: it
> > >> proves
> > >>>> that the build.xml files in the source packages can
> build
> > the .tar.gz
> > >> that
> > >>>> are useful to NPM and IDE users who use Ant and
> want to
> > test a change.
> > >>>>
> > >>>> I think of it as code-coverage. If we had
> > code-coverage tools, we
> > >>>> would ask that the RM complete as much of the
> automated
> > code-coverage
> > >>>> testing as possible before posting the release for a
> > vote. That one
> > >>>> command increases our code coverage by running the
> > build.xml files. We
> > >>>> should be always working to increase automated code
> > coverage in the RC.
> > >>>> Certainly for me as RM, I will gladly watch TV as
> the
> > automated tests
> > >> run
> > >>>> because a failed RC means going back through many
> of the
> > first 25
> > >> commands
> > >>>> again and wastes other people's time. Each RC is
> more
> > emails to read
> > >> and
> > >>>> more time from the voters and testers.
> > >>>>
> > >>>> If there are other ways for the RM to get the
> same or
> > better code
> > >>>> coverage on the build.xml files before posting the
> RC, we
> > can discuss
> > >> those
> > >>>> options.
> > >>>>
> > >>>> I am hopeful we can all agree on these simple
> > principles: Strive for
> > >>>> better code coverage and fewer failed RCs.
> Royale's main
> > purpose is to
> > >>>> save other people time. Let's do that in creating
> > releases too.
> > >>>>
> > >>>> One issue that was brought up recently was
> whether it
> > is a good
> > >>>> decision to have the RM test all of the build
> platforms
> > we support.
> > >>>> Suppose we add some other build system support or
> more in
> > the future?
> > >>>> Again, the code coverage principle applies here, but
> > also, I would like
> > >> us
> > >>>> to retain feature parity, and I also hope for as
> few RCs
> > and votes as
> > >>>> possible. So instead of having separate
> > votes/features/release-dates
> > >> for
> > >>>> the Maven artifacts vs the Ant artifacts vs the
> > SomeFutureBuildTech
> > >>>> artifacts, I think we should have one vote and keep
> them
> > all in sync.
> > >> If
> > >>>> we do ever get around to monthly or bi-monthly
> releases,
> > I think
> > >> separate
> > >>>> build platform releases would be too much work.
> > >>>>
> > >>>> But consider this thought I just had today: the
> RM
> > doesn't really
> > >>>> have to choose to do all 100 commands on a local
> machine
> > or with Ant
> > >>>> scripts or do the first 40 via CI. The RM can
> actually
> > pick and choose
> > >>>> commands to run on the CI server. The CI Jenkins
> jobs
> > are not a
> > >>>> separate/alternative release process, they are just
> > another way of
> > >>>> executing the first 40 steps. Using CI jobs
> actually
> > requires
> > >> additional
> > >>>> command-line cut-and-paste to push commits on the CI
> > server and to sign
> > >> and
> > >>>> validate binaries locally, but that's the trade-off
> of
> > not having to
> > >>>> configure your machine to successfully run all of
> the
> > automated tests
> > >> and
> > >>>> build systems, and being able to run a command by
> filling
> > in the version
> > >>>> number and rc number and hitting the "ok" button
> instead
> > of making sure
> > >> you
> > >>>> got the whole command typed in correctly.
> > >>>>
> > >>>> So, an RM can run the first 25 steps locally,
> then go
> > the CI server
> > >>>> and run what is now Jenkins Job
> "Royale_Release_Step_013"
> > (no need to
> > >> run
> > >>>> the first 12) and it will run tasks 26 through 32,
> and if
> > it is
> > >> successful,
> > >>>> then the RM has proven code coverage of the
> build.xml
> > files. (If the
> > >>>> resulting tar.gz and zips are not posted, then the
> RM
> > should verify that
> > >>>> they match the ones from Maven distribution). I
> would
> > encourage RMs to
> > >>>> also use the CI jobs that generate the emails to
> make
> > sure the subject
> > >> and
> > >>>> content is correct and contains the usual
> instructions so
> > we have
> > >>>> consistency. Maybe someday there will be CI jobs
> to do
> > the last 60+
> > >> steps
> > >>>> if that helps. We could add a Jenkins job that
> runs an
> > Ant build on RC
> > >>>> artifacts on dist.a.o as well.
> > >>>>
> > >>>> I would like you all to help maintain the list of
> 100
> > steps and other
> > >>>> documents related to the release process, and
> improve the
> > CI jobs and
> > >> Ant
> > >>>> steps if it helps you be a more efficient RM. I am
> > hopeful that now
> > >> that I
> > >>>> have hopefully explained our release process
> better, that
> > we can see
> > >> that
> > >>>> these 100+ steps just have to be done in some way.
> The
> > RM can figure
> > >> out
> > >>>> what way works best for them, but they must get
> through
> > all of them.
> > >>>>
> > >>>> Thanks,
> > >>>> -Alex
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Carlos Rovira
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=xlPb2j%2BvQaiP19ABxenzcttceBkXQo%2FkTU6SZ%2FaADQ0%3D&reserved=0
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=xlPb2j%2BvQaiP19ABxenzcttceBkXQo%2FkTU6SZ%2FaADQ0%3D&reserved=0
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=xlPb2j%2BvQaiP19ABxenzcttceBkXQo%2FkTU6SZ%2FaADQ0%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
The command lines in [1] have been added to [2]. [1] is only a partial list of the things to do, but includes some helpful setup information Hopefully in June we won't need to release build-tools so you will only have about 90 steps to do, but we may have added more commands as we improve our automated test infrastructure.
HTH,
-Alex
[2] https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
On 4/2/20, 11:56 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
to understand your long email. Lets say that when I'll go to release in
June (0.9.9), I'll use instructions described in [1].
So that will create the sources needed to post. Then, to avouid later
problems for people verifying I'll verify it with Maven and Ant (build with
both, and test SDK generated in example apps. Then push to dist.a.o, create
discuss and vote threads, and start the vote.
Is that ok?
Thanks
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FNew-Release-Manager&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165851458&sdata=mqhHe7LrUmASFs1EH7Bd18g7TOyU9CGm8Sqz1XiZzrA%3D&reserved=0
El jue., 2 abr. 2020 a las 19:16, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I'm not sure I understand the distinction. I think we want to do both.
> The goal of code coverage is to try to exercise paths. We want to run "ant
> release" because our Ant users might want to do that. And Ant does have
> assertions AFAICT. It will report errors. Meanwhile, the standard for
> the .tar.gz package is the one produced by "ant release" because that's the
> recipe we've been using for years now. The Maven distribution's .tar.gz
> has been shown to work in most cases, but AFAICT, is nearly as well tested
> and has not been binary-compared. Ways to compare the two .tar.gz files
> are needed and welcome.
>
> More and better tests are welcome.
>
> Do we have agreement? It sounds like it. So I will now be spending my
> evenings on the release instead of writing lists of 100 things.
>
> -Alex
>
> On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
> Chris, I think you’re missing Alex’s point. We’re not running Ant to
> make sure it doesn’t blow up. We’re running it to make sure the resultant
> tar.gz/zip files are identical to the ones created by Maven. Alex, please
> correct me if I’m wrong.
>
> ________________________________
> From: Christofer Dutz <ch...@c-ware.de>
> Sent: Thursday, April 2, 2020 4:42:00 PM
> To: dev@royale.apache.org <de...@royale.apache.org>
> Subject: Re: Royale Releases
>
> And to add a little to that [1]
>
> "In computer science, test coverage is a measure used to describe the
> degree to which the source code of a program is executed when a particular
> test suite runs."
>
> So no test, no coverage. Just using something and it's not blowing up
> isn't a test for me. It's better than nothing however.
>
> Chris
>
>
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165851458&sdata=%2FlsJ%2FKEJn%2FEVGIsq%2Bja%2FcCrS7yIF6PRw7o0c%2FYE0tcY%3D&reserved=0
>
> Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> christofer.dutz@c-ware.de>:
>
> Hi folks,
>
> I would say we have coverage for both maven ant equally as we're
> building the same code.
>
> However we are missing the important assertions. It's not that the
> Ant build is running some tests Maven isn't.
> It's just that the settings for Ant seem to be different than for
> Maven and the Ant ones happen to work.
>
> Ideally there would be real tests that test the output of both to
> see if it works in both cases.
>
> Chris
>
>
>
> Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
>
> Adding more coverage for Maven is good.
>
> Removing coverage for Ant is not.
>
> Do you agree?
>
> > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> carlosrovira@apache.org> wrote:
> >
> > Hi Harbs,
> >
> > I think what we're trying to say is that until now we
> released with Maven
> > and Ant, and that was hiding a flaw in Maven (SVG example).
> So that means
> > what we were trying to cover was not covered clearly, so the
> premise is not
> > right.
> >
> >
> >
> > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> harbs.lists@gmail.com>) escribió:
> >
> >> No one is arguing that we shouldn’t add more tests.
> >>
> >> Please let’s not make it seem like there’s a disagreement
> about that.
> >>
> >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> carlosrovira@apache.org>
> >> wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> first, many thanks for the detailed email. I'll comment on
> this later as
> >> I
> >>> have more time.
> >>>
> >>> For now, to add up a recent example on what Chris
> commented: If you all
> >>> remember a week ago I was trying to use SVG Images in a
> blog example that
> >>> was published 2 days ago. Nobody tried SVG Images before
> building with
> >>> maven, I know that since maven was not properly configured
> and using that
> >>> component from Maven was failing with an RTE. Probably we
> have more
> >> things
> >>> not working the same way when build from Maven and Ant,
> and that's
> >>> something that will need people using that code paths in
> test
> >> applications
> >>> (or in their own apps) to see if things works properly.
> >>>
> >>> I was recently introduced to "examples-integrationtest" by
> Chris, that I
> >>> plan to use soon as I can. I think is a great idea, since
> you get a
> >> Firefox
> >>> running test interface of the real use of some concrete
> royale code. I
> >>> think passed until now unnoticed by all of us, and seems a
> powerful tool.
> >>> There's already an example about FlexStore with some basic
> assertions.
> >>>
> >>> Again, thanks, and will comment on the rest later
> >>>
> >>> Carlos
> >>>
> >>>
> >>>
> >>>
> >>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >> christofer.dutz@c-ware.de>)
> >>> escribió:
> >>>
> >>>> Hi Alex,
> >>>>
> >>>> just a point you are bringing up: "Code coverage".
> >>>>
> >>>> I strongly dislike the idea of "asjs" effectively being
> the test for the
> >>>> compiler. The reasoning behind this is: yes you do get
> more code
> >> covered,
> >>>> but only the happy-path (ideally) and even if things go
> wrong, the end
> >>>> results aren't tested. Did add a module to asjs years ago
> >>>> ("examples-integrationtest") that deployed the examples
> in a tomcat
> >> server
> >>>> then opens a Firefox browser and clicks through 2 of the
> examples (I
> >> added
> >>>> two dummy tests as an example, but seems no one touched
> this after me).
> >> I
> >>>> did this because I remember us working on asjs for weeks
> without anyone
> >>>> noticing the compiler wasn't producing runnable code ...
> same with the
> >>>> little unit-tests that are still run for every example,
> that simply
> >> check
> >>>> if an output is generated, because we had a prolonged
> period of time
> >> where
> >>>> we were all working on different parts, but for quite
> some time the
> >>>> application compilation just didn't output anything and
> no one noticed.
> >>>>
> >>>> So coverage is nothing without assertions (my opinion)
> ... ok ... it's
> >>>> slightly better than no coverage, but not much, in my
> opinion.
> >>>>
> >>>> I think in parallel to this release discussions I have
> seen numerous
> >>>> threads about someone doing something that broke
> something for someone
> >>>> else. This could be addressed by increasing coverage by
> providing
> >> explicit
> >>>> tests.
> >>>>
> >>>> Coming back to the releases:
> >>>> I have no objections, if you do a "release" locally and
> automate the
> >>>> validation on the CI server (Which effectively would be
> your proposal
> >> to do
> >>>> the first 12 steps on local hardware and the 13th on the
> CI server). I
> >> even
> >>>> think that's a good idea ... There could be one step for
> building a
> >> release
> >>>> from a given "git tag" for every build system and generic
> means to
> >> compare
> >>>> tar.gz and zips produced by any build system with that of
> another
> >> (ideally
> >>>> with better output than just a plain "true/false"). This
> would even
> >> help to
> >>>> iron out the last potentially existing bumps out of the
> Maven
> >> distribution.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> <ah...@adobe.com.INVALID>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This is my attempt to explain what goes into a release
> in hopes that
> >>>> we can understand and agree on what our release process
> is. It became
> >>>> apparent in my reading of the wiki page with the new
> Maven steps and in
> >>>> talking with Harbs today that there are still many
> misunderstandings
> >> about
> >>>> what we do to create a release. I don't generally like
> writing
> >>>> instructions in English because it is easy to be
> ambiguous. All of the
> >>>> steps that we use to create releases had been captured in
> Ant scripts
> >> in a
> >>>> much more explicit way, IMO, but I took the time to write
> them down in
> >>>> English here:
> >>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=cjnIpo4zXOc1abhUTDRE2O8IqQ5%2Baxn%2B9JSiX%2Bfmv1c%3D&reserved=0
> >>>>
> >>>> I did this quickly by scanning the CI steps, the new
> Maven steps and
> >>>> the Ant scripts used in prior releases so there could
> certainly be
> >> mistakes
> >>>> and missed steps. If I did my math right, the RM for
> 0.9.7 will have to
> >>>> complete over 100 tasks (essentially, typing a
> command-line 100 times).
> >>>> Future RMs, when we don't have to release build-tools,
> will have about
> >> 92
> >>>> steps. And I did not include voter verification checks
> the RM should
> >> run
> >>>> before opening a vote (verifying that the artifacts
> download and match
> >>>> their checksums, etc). As an RM, I run a bunch of tests
> on the RC
> >> before
> >>>> sending out the vote. Maybe we should add those to the
> task list.
> >>>>
> >>>> I think there has been confusion about the use of Ant
> in the release
> >>>> process. Because I was the RM for the first set of
> FlexJS/Royale
> >> releases,
> >>>> and I'm a lazy person who hates typing at the command
> line, I created
> >> Ant
> >>>> scripts to execute these 100 steps. But I agree that it
> is not a
> >>>> requirement that other RMs must use the Ant scripts for
> these
> >> commands. If
> >>>> you are the RM and like typing, go ahead.
> >>>>
> >>>> Then we found out that other people couldn't get
> through this task
> >>>> list. I think the 3 people who tried were having trouble
> with Maven
> >>>> uploads and downloads. So what I did was put the first
> 40 steps or so
> >> into
> >>>> Jenkins jobs. And by doing that, Piotr was able to
> produce our last
> >>>> release. And that also saves on manually typing
> commands. But again,
> >>>> going forward, the RM gets to choose how they want to
> execute these
> >> steps.
> >>>>
> >>>> If you scan the set of steps, you'll see that "ant" is
> only in there
> >>>> once. I believe the recent threads have been about this
> single command
> >> out
> >>>> of the 100+ commands. This is why this has been so
> frustrating to me.
> >> I
> >>>> believe there is a solid technical reason for that one
> command: it
> >> proves
> >>>> that the build.xml files in the source packages can build
> the .tar.gz
> >> that
> >>>> are useful to NPM and IDE users who use Ant and want to
> test a change.
> >>>>
> >>>> I think of it as code-coverage. If we had
> code-coverage tools, we
> >>>> would ask that the RM complete as much of the automated
> code-coverage
> >>>> testing as possible before posting the release for a
> vote. That one
> >>>> command increases our code coverage by running the
> build.xml files. We
> >>>> should be always working to increase automated code
> coverage in the RC.
> >>>> Certainly for me as RM, I will gladly watch TV as the
> automated tests
> >> run
> >>>> because a failed RC means going back through many of the
> first 25
> >> commands
> >>>> again and wastes other people's time. Each RC is more
> emails to read
> >> and
> >>>> more time from the voters and testers.
> >>>>
> >>>> If there are other ways for the RM to get the same or
> better code
> >>>> coverage on the build.xml files before posting the RC, we
> can discuss
> >> those
> >>>> options.
> >>>>
> >>>> I am hopeful we can all agree on these simple
> principles: Strive for
> >>>> better code coverage and fewer failed RCs. Royale's main
> purpose is to
> >>>> save other people time. Let's do that in creating
> releases too.
> >>>>
> >>>> One issue that was brought up recently was whether it
> is a good
> >>>> decision to have the RM test all of the build platforms
> we support.
> >>>> Suppose we add some other build system support or more in
> the future?
> >>>> Again, the code coverage principle applies here, but
> also, I would like
> >> us
> >>>> to retain feature parity, and I also hope for as few RCs
> and votes as
> >>>> possible. So instead of having separate
> votes/features/release-dates
> >> for
> >>>> the Maven artifacts vs the Ant artifacts vs the
> SomeFutureBuildTech
> >>>> artifacts, I think we should have one vote and keep them
> all in sync.
> >> If
> >>>> we do ever get around to monthly or bi-monthly releases,
> I think
> >> separate
> >>>> build platform releases would be too much work.
> >>>>
> >>>> But consider this thought I just had today: the RM
> doesn't really
> >>>> have to choose to do all 100 commands on a local machine
> or with Ant
> >>>> scripts or do the first 40 via CI. The RM can actually
> pick and choose
> >>>> commands to run on the CI server. The CI Jenkins jobs
> are not a
> >>>> separate/alternative release process, they are just
> another way of
> >>>> executing the first 40 steps. Using CI jobs actually
> requires
> >> additional
> >>>> command-line cut-and-paste to push commits on the CI
> server and to sign
> >> and
> >>>> validate binaries locally, but that's the trade-off of
> not having to
> >>>> configure your machine to successfully run all of the
> automated tests
> >> and
> >>>> build systems, and being able to run a command by filling
> in the version
> >>>> number and rc number and hitting the "ok" button instead
> of making sure
> >> you
> >>>> got the whole command typed in correctly.
> >>>>
> >>>> So, an RM can run the first 25 steps locally, then go
> the CI server
> >>>> and run what is now Jenkins Job "Royale_Release_Step_013"
> (no need to
> >> run
> >>>> the first 12) and it will run tasks 26 through 32, and if
> it is
> >> successful,
> >>>> then the RM has proven code coverage of the build.xml
> files. (If the
> >>>> resulting tar.gz and zips are not posted, then the RM
> should verify that
> >>>> they match the ones from Maven distribution). I would
> encourage RMs to
> >>>> also use the CI jobs that generate the emails to make
> sure the subject
> >> and
> >>>> content is correct and contains the usual instructions so
> we have
> >>>> consistency. Maybe someday there will be CI jobs to do
> the last 60+
> >> steps
> >>>> if that helps. We could add a Jenkins job that runs an
> Ant build on RC
> >>>> artifacts on dist.a.o as well.
> >>>>
> >>>> I would like you all to help maintain the list of 100
> steps and other
> >>>> documents related to the release process, and improve the
> CI jobs and
> >> Ant
> >>>> steps if it helps you be a more efficient RM. I am
> hopeful that now
> >> that I
> >>>> have hopefully explained our release process better, that
> we can see
> >> that
> >>>> these 100+ steps just have to be done in some way. The
> RM can figure
> >> out
> >>>> what way works best for them, but they must get through
> all of them.
> >>>>
> >>>> Thanks,
> >>>> -Alex
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=xlPb2j%2BvQaiP19ABxenzcttceBkXQo%2FkTU6SZ%2FaADQ0%3D&reserved=0
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=xlPb2j%2BvQaiP19ABxenzcttceBkXQo%2FkTU6SZ%2FaADQ0%3D&reserved=0
>
>
>
>
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cae841258728b4f64ee2808d7d7379c5e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214506165861453&sdata=xlPb2j%2BvQaiP19ABxenzcttceBkXQo%2FkTU6SZ%2FaADQ0%3D&reserved=0
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
to understand your long email. Lets say that when I'll go to release in
June (0.9.9), I'll use instructions described in [1].
So that will create the sources needed to post. Then, to avouid later
problems for people verifying I'll verify it with Maven and Ant (build with
both, and test SDK generated in example apps. Then push to dist.a.o, create
discuss and vote threads, and start the vote.
Is that ok?
Thanks
[1] https://github.com/apache/royale-asjs/wiki/New-Release-Manager
El jue., 2 abr. 2020 a las 19:16, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I'm not sure I understand the distinction. I think we want to do both.
> The goal of code coverage is to try to exercise paths. We want to run "ant
> release" because our Ant users might want to do that. And Ant does have
> assertions AFAICT. It will report errors. Meanwhile, the standard for
> the .tar.gz package is the one produced by "ant release" because that's the
> recipe we've been using for years now. The Maven distribution's .tar.gz
> has been shown to work in most cases, but AFAICT, is nearly as well tested
> and has not been binary-compared. Ways to compare the two .tar.gz files
> are needed and welcome.
>
> More and better tests are welcome.
>
> Do we have agreement? It sounds like it. So I will now be spending my
> evenings on the release instead of writing lists of 100 things.
>
> -Alex
>
> On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
> Chris, I think you’re missing Alex’s point. We’re not running Ant to
> make sure it doesn’t blow up. We’re running it to make sure the resultant
> tar.gz/zip files are identical to the ones created by Maven. Alex, please
> correct me if I’m wrong.
>
> ________________________________
> From: Christofer Dutz <ch...@c-ware.de>
> Sent: Thursday, April 2, 2020 4:42:00 PM
> To: dev@royale.apache.org <de...@royale.apache.org>
> Subject: Re: Royale Releases
>
> And to add a little to that [1]
>
> "In computer science, test coverage is a measure used to describe the
> degree to which the source code of a program is executed when a particular
> test suite runs."
>
> So no test, no coverage. Just using something and it's not blowing up
> isn't a test for me. It's better than nothing however.
>
> Chris
>
>
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=emW5sFytkSu0CWSVicIrmHRA3SxiJqi26n%2BFrF%2FYX5E%3D&reserved=0
>
> Am 02.04.20, 15:39 schrieb "Christofer Dutz" <
> christofer.dutz@c-ware.de>:
>
> Hi folks,
>
> I would say we have coverage for both maven ant equally as we're
> building the same code.
>
> However we are missing the important assertions. It's not that the
> Ant build is running some tests Maven isn't.
> It's just that the settings for Ant seem to be different than for
> Maven and the Ant ones happen to work.
>
> Ideally there would be real tests that test the output of both to
> see if it works in both cases.
>
> Chris
>
>
>
> Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
>
> Adding more coverage for Maven is good.
>
> Removing coverage for Ant is not.
>
> Do you agree?
>
> > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> carlosrovira@apache.org> wrote:
> >
> > Hi Harbs,
> >
> > I think what we're trying to say is that until now we
> released with Maven
> > and Ant, and that was hiding a flaw in Maven (SVG example).
> So that means
> > what we were trying to cover was not covered clearly, so the
> premise is not
> > right.
> >
> >
> >
> > El jue., 2 abr. 2020 a las 14:56, Harbs (<
> harbs.lists@gmail.com>) escribió:
> >
> >> No one is arguing that we shouldn’t add more tests.
> >>
> >> Please let’s not make it seem like there’s a disagreement
> about that.
> >>
> >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> carlosrovira@apache.org>
> >> wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> first, many thanks for the detailed email. I'll comment on
> this later as
> >> I
> >>> have more time.
> >>>
> >>> For now, to add up a recent example on what Chris
> commented: If you all
> >>> remember a week ago I was trying to use SVG Images in a
> blog example that
> >>> was published 2 days ago. Nobody tried SVG Images before
> building with
> >>> maven, I know that since maven was not properly configured
> and using that
> >>> component from Maven was failing with an RTE. Probably we
> have more
> >> things
> >>> not working the same way when build from Maven and Ant,
> and that's
> >>> something that will need people using that code paths in
> test
> >> applications
> >>> (or in their own apps) to see if things works properly.
> >>>
> >>> I was recently introduced to "examples-integrationtest" by
> Chris, that I
> >>> plan to use soon as I can. I think is a great idea, since
> you get a
> >> Firefox
> >>> running test interface of the real use of some concrete
> royale code. I
> >>> think passed until now unnoticed by all of us, and seems a
> powerful tool.
> >>> There's already an example about FlexStore with some basic
> assertions.
> >>>
> >>> Again, thanks, and will comment on the rest later
> >>>
> >>> Carlos
> >>>
> >>>
> >>>
> >>>
> >>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >> christofer.dutz@c-ware.de>)
> >>> escribió:
> >>>
> >>>> Hi Alex,
> >>>>
> >>>> just a point you are bringing up: "Code coverage".
> >>>>
> >>>> I strongly dislike the idea of "asjs" effectively being
> the test for the
> >>>> compiler. The reasoning behind this is: yes you do get
> more code
> >> covered,
> >>>> but only the happy-path (ideally) and even if things go
> wrong, the end
> >>>> results aren't tested. Did add a module to asjs years ago
> >>>> ("examples-integrationtest") that deployed the examples
> in a tomcat
> >> server
> >>>> then opens a Firefox browser and clicks through 2 of the
> examples (I
> >> added
> >>>> two dummy tests as an example, but seems no one touched
> this after me).
> >> I
> >>>> did this because I remember us working on asjs for weeks
> without anyone
> >>>> noticing the compiler wasn't producing runnable code ...
> same with the
> >>>> little unit-tests that are still run for every example,
> that simply
> >> check
> >>>> if an output is generated, because we had a prolonged
> period of time
> >> where
> >>>> we were all working on different parts, but for quite
> some time the
> >>>> application compilation just didn't output anything and
> no one noticed.
> >>>>
> >>>> So coverage is nothing without assertions (my opinion)
> ... ok ... it's
> >>>> slightly better than no coverage, but not much, in my
> opinion.
> >>>>
> >>>> I think in parallel to this release discussions I have
> seen numerous
> >>>> threads about someone doing something that broke
> something for someone
> >>>> else. This could be addressed by increasing coverage by
> providing
> >> explicit
> >>>> tests.
> >>>>
> >>>> Coming back to the releases:
> >>>> I have no objections, if you do a "release" locally and
> automate the
> >>>> validation on the CI server (Which effectively would be
> your proposal
> >> to do
> >>>> the first 12 steps on local hardware and the 13th on the
> CI server). I
> >> even
> >>>> think that's a good idea ... There could be one step for
> building a
> >> release
> >>>> from a given "git tag" for every build system and generic
> means to
> >> compare
> >>>> tar.gz and zips produced by any build system with that of
> another
> >> (ideally
> >>>> with better output than just a plain "true/false"). This
> would even
> >> help to
> >>>> iron out the last potentially existing bumps out of the
> Maven
> >> distribution.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> <ah...@adobe.com.INVALID>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This is my attempt to explain what goes into a release
> in hopes that
> >>>> we can understand and agree on what our release process
> is. It became
> >>>> apparent in my reading of the wiki page with the new
> Maven steps and in
> >>>> talking with Harbs today that there are still many
> misunderstandings
> >> about
> >>>> what we do to create a release. I don't generally like
> writing
> >>>> instructions in English because it is easy to be
> ambiguous. All of the
> >>>> steps that we use to create releases had been captured in
> Ant scripts
> >> in a
> >>>> much more explicit way, IMO, but I took the time to write
> them down in
> >>>> English here:
> >>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=HgyvdeHLRqIp4iBCvEDyxpcqW9eOrwH%2BqKcmfphmIk4%3D&reserved=0
> >>>>
> >>>> I did this quickly by scanning the CI steps, the new
> Maven steps and
> >>>> the Ant scripts used in prior releases so there could
> certainly be
> >> mistakes
> >>>> and missed steps. If I did my math right, the RM for
> 0.9.7 will have to
> >>>> complete over 100 tasks (essentially, typing a
> command-line 100 times).
> >>>> Future RMs, when we don't have to release build-tools,
> will have about
> >> 92
> >>>> steps. And I did not include voter verification checks
> the RM should
> >> run
> >>>> before opening a vote (verifying that the artifacts
> download and match
> >>>> their checksums, etc). As an RM, I run a bunch of tests
> on the RC
> >> before
> >>>> sending out the vote. Maybe we should add those to the
> task list.
> >>>>
> >>>> I think there has been confusion about the use of Ant
> in the release
> >>>> process. Because I was the RM for the first set of
> FlexJS/Royale
> >> releases,
> >>>> and I'm a lazy person who hates typing at the command
> line, I created
> >> Ant
> >>>> scripts to execute these 100 steps. But I agree that it
> is not a
> >>>> requirement that other RMs must use the Ant scripts for
> these
> >> commands. If
> >>>> you are the RM and like typing, go ahead.
> >>>>
> >>>> Then we found out that other people couldn't get
> through this task
> >>>> list. I think the 3 people who tried were having trouble
> with Maven
> >>>> uploads and downloads. So what I did was put the first
> 40 steps or so
> >> into
> >>>> Jenkins jobs. And by doing that, Piotr was able to
> produce our last
> >>>> release. And that also saves on manually typing
> commands. But again,
> >>>> going forward, the RM gets to choose how they want to
> execute these
> >> steps.
> >>>>
> >>>> If you scan the set of steps, you'll see that "ant" is
> only in there
> >>>> once. I believe the recent threads have been about this
> single command
> >> out
> >>>> of the 100+ commands. This is why this has been so
> frustrating to me.
> >> I
> >>>> believe there is a solid technical reason for that one
> command: it
> >> proves
> >>>> that the build.xml files in the source packages can build
> the .tar.gz
> >> that
> >>>> are useful to NPM and IDE users who use Ant and want to
> test a change.
> >>>>
> >>>> I think of it as code-coverage. If we had
> code-coverage tools, we
> >>>> would ask that the RM complete as much of the automated
> code-coverage
> >>>> testing as possible before posting the release for a
> vote. That one
> >>>> command increases our code coverage by running the
> build.xml files. We
> >>>> should be always working to increase automated code
> coverage in the RC.
> >>>> Certainly for me as RM, I will gladly watch TV as the
> automated tests
> >> run
> >>>> because a failed RC means going back through many of the
> first 25
> >> commands
> >>>> again and wastes other people's time. Each RC is more
> emails to read
> >> and
> >>>> more time from the voters and testers.
> >>>>
> >>>> If there are other ways for the RM to get the same or
> better code
> >>>> coverage on the build.xml files before posting the RC, we
> can discuss
> >> those
> >>>> options.
> >>>>
> >>>> I am hopeful we can all agree on these simple
> principles: Strive for
> >>>> better code coverage and fewer failed RCs. Royale's main
> purpose is to
> >>>> save other people time. Let's do that in creating
> releases too.
> >>>>
> >>>> One issue that was brought up recently was whether it
> is a good
> >>>> decision to have the RM test all of the build platforms
> we support.
> >>>> Suppose we add some other build system support or more in
> the future?
> >>>> Again, the code coverage principle applies here, but
> also, I would like
> >> us
> >>>> to retain feature parity, and I also hope for as few RCs
> and votes as
> >>>> possible. So instead of having separate
> votes/features/release-dates
> >> for
> >>>> the Maven artifacts vs the Ant artifacts vs the
> SomeFutureBuildTech
> >>>> artifacts, I think we should have one vote and keep them
> all in sync.
> >> If
> >>>> we do ever get around to monthly or bi-monthly releases,
> I think
> >> separate
> >>>> build platform releases would be too much work.
> >>>>
> >>>> But consider this thought I just had today: the RM
> doesn't really
> >>>> have to choose to do all 100 commands on a local machine
> or with Ant
> >>>> scripts or do the first 40 via CI. The RM can actually
> pick and choose
> >>>> commands to run on the CI server. The CI Jenkins jobs
> are not a
> >>>> separate/alternative release process, they are just
> another way of
> >>>> executing the first 40 steps. Using CI jobs actually
> requires
> >> additional
> >>>> command-line cut-and-paste to push commits on the CI
> server and to sign
> >> and
> >>>> validate binaries locally, but that's the trade-off of
> not having to
> >>>> configure your machine to successfully run all of the
> automated tests
> >> and
> >>>> build systems, and being able to run a command by filling
> in the version
> >>>> number and rc number and hitting the "ok" button instead
> of making sure
> >> you
> >>>> got the whole command typed in correctly.
> >>>>
> >>>> So, an RM can run the first 25 steps locally, then go
> the CI server
> >>>> and run what is now Jenkins Job "Royale_Release_Step_013"
> (no need to
> >> run
> >>>> the first 12) and it will run tasks 26 through 32, and if
> it is
> >> successful,
> >>>> then the RM has proven code coverage of the build.xml
> files. (If the
> >>>> resulting tar.gz and zips are not posted, then the RM
> should verify that
> >>>> they match the ones from Maven distribution). I would
> encourage RMs to
> >>>> also use the CI jobs that generate the emails to make
> sure the subject
> >> and
> >>>> content is correct and contains the usual instructions so
> we have
> >>>> consistency. Maybe someday there will be CI jobs to do
> the last 60+
> >> steps
> >>>> if that helps. We could add a Jenkins job that runs an
> Ant build on RC
> >>>> artifacts on dist.a.o as well.
> >>>>
> >>>> I would like you all to help maintain the list of 100
> steps and other
> >>>> documents related to the release process, and improve the
> CI jobs and
> >> Ant
> >>>> steps if it helps you be a more efficient RM. I am
> hopeful that now
> >> that I
> >>>> have hopefully explained our release process better, that
> we can see
> >> that
> >>>> these 100+ steps just have to be done in some way. The
> RM can figure
> >> out
> >>>> what way works best for them, but they must get through
> all of them.
> >>>>
> >>>> Thanks,
> >>>> -Alex
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=GmfwWqH%2FI7uyN%2FKAhOytA3akoAelmvQbFb78f4oQjRg%3D&reserved=0
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=GmfwWqH%2FI7uyN%2FKAhOytA3akoAelmvQbFb78f4oQjRg%3D&reserved=0
>
>
>
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm not sure I understand the distinction. I think we want to do both. The goal of code coverage is to try to exercise paths. We want to run "ant release" because our Ant users might want to do that. And Ant does have assertions AFAICT. It will report errors. Meanwhile, the standard for the .tar.gz package is the one produced by "ant release" because that's the recipe we've been using for years now. The Maven distribution's .tar.gz has been shown to work in most cases, but AFAICT, is nearly as well tested and has not been binary-compared. Ways to compare the two .tar.gz files are needed and welcome.
More and better tests are welcome.
Do we have agreement? It sounds like it. So I will now be spending my evenings on the release instead of writing lists of 100 things.
-Alex
On 4/2/20, 8:40 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
Chris, I think you’re missing Alex’s point. We’re not running Ant to make sure it doesn’t blow up. We’re running it to make sure the resultant tar.gz/zip files are identical to the ones created by Maven. Alex, please correct me if I’m wrong.
________________________________
From: Christofer Dutz <ch...@c-ware.de>
Sent: Thursday, April 2, 2020 4:42:00 PM
To: dev@royale.apache.org <de...@royale.apache.org>
Subject: Re: Royale Releases
And to add a little to that [1]
"In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs."
So no test, no coverage. Just using something and it's not blowing up isn't a test for me. It's better than nothing however.
Chris
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCode_coverage&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=emW5sFytkSu0CWSVicIrmHRA3SxiJqi26n%2BFrF%2FYX5E%3D&reserved=0
Am 02.04.20, 15:39 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi folks,
I would say we have coverage for both maven ant equally as we're building the same code.
However we are missing the important assertions. It's not that the Ant build is running some tests Maven isn't.
It's just that the settings for Ant seem to be different than for Maven and the Ant ones happen to work.
Ideally there would be real tests that test the output of both to see if it works in both cases.
Chris
Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
Adding more coverage for Maven is good.
Removing coverage for Ant is not.
Do you agree?
> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I think what we're trying to say is that until now we released with Maven
> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
> what we were trying to cover was not covered clearly, so the premise is not
> right.
>
>
>
> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>
>> No one is arguing that we shouldn’t add more tests.
>>
>> Please let’s not make it seem like there’s a disagreement about that.
>>
>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> first, many thanks for the detailed email. I'll comment on this later as
>> I
>>> have more time.
>>>
>>> For now, to add up a recent example on what Chris commented: If you all
>>> remember a week ago I was trying to use SVG Images in a blog example that
>>> was published 2 days ago. Nobody tried SVG Images before building with
>>> maven, I know that since maven was not properly configured and using that
>>> component from Maven was failing with an RTE. Probably we have more
>> things
>>> not working the same way when build from Maven and Ant, and that's
>>> something that will need people using that code paths in test
>> applications
>>> (or in their own apps) to see if things works properly.
>>>
>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>> plan to use soon as I can. I think is a great idea, since you get a
>> Firefox
>>> running test interface of the real use of some concrete royale code. I
>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>> There's already an example about FlexStore with some basic assertions.
>>>
>>> Again, thanks, and will comment on the rest later
>>>
>>> Carlos
>>>
>>>
>>>
>>>
>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> christofer.dutz@c-ware.de>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> just a point you are bringing up: "Code coverage".
>>>>
>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>> compiler. The reasoning behind this is: yes you do get more code
>> covered,
>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>> results aren't tested. Did add a module to asjs years ago
>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>> server
>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>> added
>>>> two dummy tests as an example, but seems no one touched this after me).
>> I
>>>> did this because I remember us working on asjs for weeks without anyone
>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>> little unit-tests that are still run for every example, that simply
>> check
>>>> if an output is generated, because we had a prolonged period of time
>> where
>>>> we were all working on different parts, but for quite some time the
>>>> application compilation just didn't output anything and no one noticed.
>>>>
>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>> slightly better than no coverage, but not much, in my opinion.
>>>>
>>>> I think in parallel to this release discussions I have seen numerous
>>>> threads about someone doing something that broke something for someone
>>>> else. This could be addressed by increasing coverage by providing
>> explicit
>>>> tests.
>>>>
>>>> Coming back to the releases:
>>>> I have no objections, if you do a "release" locally and automate the
>>>> validation on the CI server (Which effectively would be your proposal
>> to do
>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>> even
>>>> think that's a good idea ... There could be one step for building a
>> release
>>>> from a given "git tag" for every build system and generic means to
>> compare
>>>> tar.gz and zips produced by any build system with that of another
>> (ideally
>>>> with better output than just a plain "true/false"). This would even
>> help to
>>>> iron out the last potentially existing bumps out of the Maven
>> distribution.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>
>>>> Hi,
>>>>
>>>> This is my attempt to explain what goes into a release in hopes that
>>>> we can understand and agree on what our release process is. It became
>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>> talking with Harbs today that there are still many misunderstandings
>> about
>>>> what we do to create a release. I don't generally like writing
>>>> instructions in English because it is easy to be ambiguous. All of the
>>>> steps that we use to create releases had been captured in Ant scripts
>> in a
>>>> much more explicit way, IMO, but I took the time to write them down in
>>>> English here:
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=HgyvdeHLRqIp4iBCvEDyxpcqW9eOrwH%2BqKcmfphmIk4%3D&reserved=0
>>>>
>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>> the Ant scripts used in prior releases so there could certainly be
>> mistakes
>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>> Future RMs, when we don't have to release build-tools, will have about
>> 92
>>>> steps. And I did not include voter verification checks the RM should
>> run
>>>> before opening a vote (verifying that the artifacts download and match
>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>> before
>>>> sending out the vote. Maybe we should add those to the task list.
>>>>
>>>> I think there has been confusion about the use of Ant in the release
>>>> process. Because I was the RM for the first set of FlexJS/Royale
>> releases,
>>>> and I'm a lazy person who hates typing at the command line, I created
>> Ant
>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>> requirement that other RMs must use the Ant scripts for these
>> commands. If
>>>> you are the RM and like typing, go ahead.
>>>>
>>>> Then we found out that other people couldn't get through this task
>>>> list. I think the 3 people who tried were having trouble with Maven
>>>> uploads and downloads. So what I did was put the first 40 steps or so
>> into
>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>> release. And that also saves on manually typing commands. But again,
>>>> going forward, the RM gets to choose how they want to execute these
>> steps.
>>>>
>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>> once. I believe the recent threads have been about this single command
>> out
>>>> of the 100+ commands. This is why this has been so frustrating to me.
>> I
>>>> believe there is a solid technical reason for that one command: it
>> proves
>>>> that the build.xml files in the source packages can build the .tar.gz
>> that
>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>
>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>> would ask that the RM complete as much of the automated code-coverage
>>>> testing as possible before posting the release for a vote. That one
>>>> command increases our code coverage by running the build.xml files. We
>>>> should be always working to increase automated code coverage in the RC.
>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>> run
>>>> because a failed RC means going back through many of the first 25
>> commands
>>>> again and wastes other people's time. Each RC is more emails to read
>> and
>>>> more time from the voters and testers.
>>>>
>>>> If there are other ways for the RM to get the same or better code
>>>> coverage on the build.xml files before posting the RC, we can discuss
>> those
>>>> options.
>>>>
>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>> save other people time. Let's do that in creating releases too.
>>>>
>>>> One issue that was brought up recently was whether it is a good
>>>> decision to have the RM test all of the build platforms we support.
>>>> Suppose we add some other build system support or more in the future?
>>>> Again, the code coverage principle applies here, but also, I would like
>> us
>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>> possible. So instead of having separate votes/features/release-dates
>> for
>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>> artifacts, I think we should have one vote and keep them all in sync.
>> If
>>>> we do ever get around to monthly or bi-monthly releases, I think
>> separate
>>>> build platform releases would be too much work.
>>>>
>>>> But consider this thought I just had today: the RM doesn't really
>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>> separate/alternative release process, they are just another way of
>>>> executing the first 40 steps. Using CI jobs actually requires
>> additional
>>>> command-line cut-and-paste to push commits on the CI server and to sign
>> and
>>>> validate binaries locally, but that's the trade-off of not having to
>>>> configure your machine to successfully run all of the automated tests
>> and
>>>> build systems, and being able to run a command by filling in the version
>>>> number and rc number and hitting the "ok" button instead of making sure
>> you
>>>> got the whole command typed in correctly.
>>>>
>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>> run
>>>> the first 12) and it will run tasks 26 through 32, and if it is
>> successful,
>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>> also use the CI jobs that generate the emails to make sure the subject
>> and
>>>> content is correct and contains the usual instructions so we have
>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>> steps
>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>> artifacts on dist.a.o as well.
>>>>
>>>> I would like you all to help maintain the list of 100 steps and other
>>>> documents related to the release process, and improve the CI jobs and
>> Ant
>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>> that I
>>>> have hopefully explained our release process better, that we can see
>> that
>>>> these 100+ steps just have to be done in some way. The RM can figure
>> out
>>>> what way works best for them, but they must get through all of them.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=GmfwWqH%2FI7uyN%2FKAhOytA3akoAelmvQbFb78f4oQjRg%3D&reserved=0
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd317247f5606472fc5b208d7d71c300d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637214388378762332&sdata=GmfwWqH%2FI7uyN%2FKAhOytA3akoAelmvQbFb78f4oQjRg%3D&reserved=0
RE: Royale Releases
Posted by Yishay Weiss <yi...@hotmail.com>.
Chris, I think you’re missing Alex’s point. We’re not running Ant to make sure it doesn’t blow up. We’re running it to make sure the resultant tar.gz/zip files are identical to the ones created by Maven. Alex, please correct me if I’m wrong.
________________________________
From: Christofer Dutz <ch...@c-ware.de>
Sent: Thursday, April 2, 2020 4:42:00 PM
To: dev@royale.apache.org <de...@royale.apache.org>
Subject: Re: Royale Releases
And to add a little to that [1]
"In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs."
So no test, no coverage. Just using something and it's not blowing up isn't a test for me. It's better than nothing however.
Chris
[1] https://en.wikipedia.org/wiki/Code_coverage
Am 02.04.20, 15:39 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi folks,
I would say we have coverage for both maven ant equally as we're building the same code.
However we are missing the important assertions. It's not that the Ant build is running some tests Maven isn't.
It's just that the settings for Ant seem to be different than for Maven and the Ant ones happen to work.
Ideally there would be real tests that test the output of both to see if it works in both cases.
Chris
Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
Adding more coverage for Maven is good.
Removing coverage for Ant is not.
Do you agree?
> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I think what we're trying to say is that until now we released with Maven
> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
> what we were trying to cover was not covered clearly, so the premise is not
> right.
>
>
>
> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>
>> No one is arguing that we shouldn’t add more tests.
>>
>> Please let’s not make it seem like there’s a disagreement about that.
>>
>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> first, many thanks for the detailed email. I'll comment on this later as
>> I
>>> have more time.
>>>
>>> For now, to add up a recent example on what Chris commented: If you all
>>> remember a week ago I was trying to use SVG Images in a blog example that
>>> was published 2 days ago. Nobody tried SVG Images before building with
>>> maven, I know that since maven was not properly configured and using that
>>> component from Maven was failing with an RTE. Probably we have more
>> things
>>> not working the same way when build from Maven and Ant, and that's
>>> something that will need people using that code paths in test
>> applications
>>> (or in their own apps) to see if things works properly.
>>>
>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>> plan to use soon as I can. I think is a great idea, since you get a
>> Firefox
>>> running test interface of the real use of some concrete royale code. I
>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>> There's already an example about FlexStore with some basic assertions.
>>>
>>> Again, thanks, and will comment on the rest later
>>>
>>> Carlos
>>>
>>>
>>>
>>>
>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> christofer.dutz@c-ware.de>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> just a point you are bringing up: "Code coverage".
>>>>
>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>> compiler. The reasoning behind this is: yes you do get more code
>> covered,
>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>> results aren't tested. Did add a module to asjs years ago
>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>> server
>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>> added
>>>> two dummy tests as an example, but seems no one touched this after me).
>> I
>>>> did this because I remember us working on asjs for weeks without anyone
>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>> little unit-tests that are still run for every example, that simply
>> check
>>>> if an output is generated, because we had a prolonged period of time
>> where
>>>> we were all working on different parts, but for quite some time the
>>>> application compilation just didn't output anything and no one noticed.
>>>>
>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>> slightly better than no coverage, but not much, in my opinion.
>>>>
>>>> I think in parallel to this release discussions I have seen numerous
>>>> threads about someone doing something that broke something for someone
>>>> else. This could be addressed by increasing coverage by providing
>> explicit
>>>> tests.
>>>>
>>>> Coming back to the releases:
>>>> I have no objections, if you do a "release" locally and automate the
>>>> validation on the CI server (Which effectively would be your proposal
>> to do
>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>> even
>>>> think that's a good idea ... There could be one step for building a
>> release
>>>> from a given "git tag" for every build system and generic means to
>> compare
>>>> tar.gz and zips produced by any build system with that of another
>> (ideally
>>>> with better output than just a plain "true/false"). This would even
>> help to
>>>> iron out the last potentially existing bumps out of the Maven
>> distribution.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>
>>>> Hi,
>>>>
>>>> This is my attempt to explain what goes into a release in hopes that
>>>> we can understand and agree on what our release process is. It became
>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>> talking with Harbs today that there are still many misunderstandings
>> about
>>>> what we do to create a release. I don't generally like writing
>>>> instructions in English because it is easy to be ambiguous. All of the
>>>> steps that we use to create releases had been captured in Ant scripts
>> in a
>>>> much more explicit way, IMO, but I took the time to write them down in
>>>> English here:
>>>>
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>
>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>> the Ant scripts used in prior releases so there could certainly be
>> mistakes
>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>> Future RMs, when we don't have to release build-tools, will have about
>> 92
>>>> steps. And I did not include voter verification checks the RM should
>> run
>>>> before opening a vote (verifying that the artifacts download and match
>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>> before
>>>> sending out the vote. Maybe we should add those to the task list.
>>>>
>>>> I think there has been confusion about the use of Ant in the release
>>>> process. Because I was the RM for the first set of FlexJS/Royale
>> releases,
>>>> and I'm a lazy person who hates typing at the command line, I created
>> Ant
>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>> requirement that other RMs must use the Ant scripts for these
>> commands. If
>>>> you are the RM and like typing, go ahead.
>>>>
>>>> Then we found out that other people couldn't get through this task
>>>> list. I think the 3 people who tried were having trouble with Maven
>>>> uploads and downloads. So what I did was put the first 40 steps or so
>> into
>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>> release. And that also saves on manually typing commands. But again,
>>>> going forward, the RM gets to choose how they want to execute these
>> steps.
>>>>
>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>> once. I believe the recent threads have been about this single command
>> out
>>>> of the 100+ commands. This is why this has been so frustrating to me.
>> I
>>>> believe there is a solid technical reason for that one command: it
>> proves
>>>> that the build.xml files in the source packages can build the .tar.gz
>> that
>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>
>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>> would ask that the RM complete as much of the automated code-coverage
>>>> testing as possible before posting the release for a vote. That one
>>>> command increases our code coverage by running the build.xml files. We
>>>> should be always working to increase automated code coverage in the RC.
>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>> run
>>>> because a failed RC means going back through many of the first 25
>> commands
>>>> again and wastes other people's time. Each RC is more emails to read
>> and
>>>> more time from the voters and testers.
>>>>
>>>> If there are other ways for the RM to get the same or better code
>>>> coverage on the build.xml files before posting the RC, we can discuss
>> those
>>>> options.
>>>>
>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>> save other people time. Let's do that in creating releases too.
>>>>
>>>> One issue that was brought up recently was whether it is a good
>>>> decision to have the RM test all of the build platforms we support.
>>>> Suppose we add some other build system support or more in the future?
>>>> Again, the code coverage principle applies here, but also, I would like
>> us
>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>> possible. So instead of having separate votes/features/release-dates
>> for
>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>> artifacts, I think we should have one vote and keep them all in sync.
>> If
>>>> we do ever get around to monthly or bi-monthly releases, I think
>> separate
>>>> build platform releases would be too much work.
>>>>
>>>> But consider this thought I just had today: the RM doesn't really
>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>> separate/alternative release process, they are just another way of
>>>> executing the first 40 steps. Using CI jobs actually requires
>> additional
>>>> command-line cut-and-paste to push commits on the CI server and to sign
>> and
>>>> validate binaries locally, but that's the trade-off of not having to
>>>> configure your machine to successfully run all of the automated tests
>> and
>>>> build systems, and being able to run a command by filling in the version
>>>> number and rc number and hitting the "ok" button instead of making sure
>> you
>>>> got the whole command typed in correctly.
>>>>
>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>> run
>>>> the first 12) and it will run tasks 26 through 32, and if it is
>> successful,
>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>> also use the CI jobs that generate the emails to make sure the subject
>> and
>>>> content is correct and contains the usual instructions so we have
>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>> steps
>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>> artifacts on dist.a.o as well.
>>>>
>>>> I would like you all to help maintain the list of 100 steps and other
>>>> documents related to the release process, and improve the CI jobs and
>> Ant
>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>> that I
>>>> have hopefully explained our release process better, that we can see
>> that
>>>> these 100+ steps just have to be done in some way. The RM can figure
>> out
>>>> what way works best for them, but they must get through all of them.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Royale Releases
Posted by Christofer Dutz <ch...@c-ware.de>.
And to add a little to that [1]
"In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs."
So no test, no coverage. Just using something and it's not blowing up isn't a test for me. It's better than nothing however.
Chris
[1] https://en.wikipedia.org/wiki/Code_coverage
Am 02.04.20, 15:39 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi folks,
I would say we have coverage for both maven ant equally as we're building the same code.
However we are missing the important assertions. It's not that the Ant build is running some tests Maven isn't.
It's just that the settings for Ant seem to be different than for Maven and the Ant ones happen to work.
Ideally there would be real tests that test the output of both to see if it works in both cases.
Chris
Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
Adding more coverage for Maven is good.
Removing coverage for Ant is not.
Do you agree?
> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I think what we're trying to say is that until now we released with Maven
> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
> what we were trying to cover was not covered clearly, so the premise is not
> right.
>
>
>
> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>
>> No one is arguing that we shouldn’t add more tests.
>>
>> Please let’s not make it seem like there’s a disagreement about that.
>>
>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> first, many thanks for the detailed email. I'll comment on this later as
>> I
>>> have more time.
>>>
>>> For now, to add up a recent example on what Chris commented: If you all
>>> remember a week ago I was trying to use SVG Images in a blog example that
>>> was published 2 days ago. Nobody tried SVG Images before building with
>>> maven, I know that since maven was not properly configured and using that
>>> component from Maven was failing with an RTE. Probably we have more
>> things
>>> not working the same way when build from Maven and Ant, and that's
>>> something that will need people using that code paths in test
>> applications
>>> (or in their own apps) to see if things works properly.
>>>
>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>> plan to use soon as I can. I think is a great idea, since you get a
>> Firefox
>>> running test interface of the real use of some concrete royale code. I
>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>> There's already an example about FlexStore with some basic assertions.
>>>
>>> Again, thanks, and will comment on the rest later
>>>
>>> Carlos
>>>
>>>
>>>
>>>
>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> christofer.dutz@c-ware.de>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> just a point you are bringing up: "Code coverage".
>>>>
>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>> compiler. The reasoning behind this is: yes you do get more code
>> covered,
>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>> results aren't tested. Did add a module to asjs years ago
>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>> server
>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>> added
>>>> two dummy tests as an example, but seems no one touched this after me).
>> I
>>>> did this because I remember us working on asjs for weeks without anyone
>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>> little unit-tests that are still run for every example, that simply
>> check
>>>> if an output is generated, because we had a prolonged period of time
>> where
>>>> we were all working on different parts, but for quite some time the
>>>> application compilation just didn't output anything and no one noticed.
>>>>
>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>> slightly better than no coverage, but not much, in my opinion.
>>>>
>>>> I think in parallel to this release discussions I have seen numerous
>>>> threads about someone doing something that broke something for someone
>>>> else. This could be addressed by increasing coverage by providing
>> explicit
>>>> tests.
>>>>
>>>> Coming back to the releases:
>>>> I have no objections, if you do a "release" locally and automate the
>>>> validation on the CI server (Which effectively would be your proposal
>> to do
>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>> even
>>>> think that's a good idea ... There could be one step for building a
>> release
>>>> from a given "git tag" for every build system and generic means to
>> compare
>>>> tar.gz and zips produced by any build system with that of another
>> (ideally
>>>> with better output than just a plain "true/false"). This would even
>> help to
>>>> iron out the last potentially existing bumps out of the Maven
>> distribution.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>
>>>> Hi,
>>>>
>>>> This is my attempt to explain what goes into a release in hopes that
>>>> we can understand and agree on what our release process is. It became
>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>> talking with Harbs today that there are still many misunderstandings
>> about
>>>> what we do to create a release. I don't generally like writing
>>>> instructions in English because it is easy to be ambiguous. All of the
>>>> steps that we use to create releases had been captured in Ant scripts
>> in a
>>>> much more explicit way, IMO, but I took the time to write them down in
>>>> English here:
>>>>
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>
>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>> the Ant scripts used in prior releases so there could certainly be
>> mistakes
>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>> Future RMs, when we don't have to release build-tools, will have about
>> 92
>>>> steps. And I did not include voter verification checks the RM should
>> run
>>>> before opening a vote (verifying that the artifacts download and match
>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>> before
>>>> sending out the vote. Maybe we should add those to the task list.
>>>>
>>>> I think there has been confusion about the use of Ant in the release
>>>> process. Because I was the RM for the first set of FlexJS/Royale
>> releases,
>>>> and I'm a lazy person who hates typing at the command line, I created
>> Ant
>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>> requirement that other RMs must use the Ant scripts for these
>> commands. If
>>>> you are the RM and like typing, go ahead.
>>>>
>>>> Then we found out that other people couldn't get through this task
>>>> list. I think the 3 people who tried were having trouble with Maven
>>>> uploads and downloads. So what I did was put the first 40 steps or so
>> into
>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>> release. And that also saves on manually typing commands. But again,
>>>> going forward, the RM gets to choose how they want to execute these
>> steps.
>>>>
>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>> once. I believe the recent threads have been about this single command
>> out
>>>> of the 100+ commands. This is why this has been so frustrating to me.
>> I
>>>> believe there is a solid technical reason for that one command: it
>> proves
>>>> that the build.xml files in the source packages can build the .tar.gz
>> that
>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>
>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>> would ask that the RM complete as much of the automated code-coverage
>>>> testing as possible before posting the release for a vote. That one
>>>> command increases our code coverage by running the build.xml files. We
>>>> should be always working to increase automated code coverage in the RC.
>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>> run
>>>> because a failed RC means going back through many of the first 25
>> commands
>>>> again and wastes other people's time. Each RC is more emails to read
>> and
>>>> more time from the voters and testers.
>>>>
>>>> If there are other ways for the RM to get the same or better code
>>>> coverage on the build.xml files before posting the RC, we can discuss
>> those
>>>> options.
>>>>
>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>> save other people time. Let's do that in creating releases too.
>>>>
>>>> One issue that was brought up recently was whether it is a good
>>>> decision to have the RM test all of the build platforms we support.
>>>> Suppose we add some other build system support or more in the future?
>>>> Again, the code coverage principle applies here, but also, I would like
>> us
>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>> possible. So instead of having separate votes/features/release-dates
>> for
>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>> artifacts, I think we should have one vote and keep them all in sync.
>> If
>>>> we do ever get around to monthly or bi-monthly releases, I think
>> separate
>>>> build platform releases would be too much work.
>>>>
>>>> But consider this thought I just had today: the RM doesn't really
>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>> separate/alternative release process, they are just another way of
>>>> executing the first 40 steps. Using CI jobs actually requires
>> additional
>>>> command-line cut-and-paste to push commits on the CI server and to sign
>> and
>>>> validate binaries locally, but that's the trade-off of not having to
>>>> configure your machine to successfully run all of the automated tests
>> and
>>>> build systems, and being able to run a command by filling in the version
>>>> number and rc number and hitting the "ok" button instead of making sure
>> you
>>>> got the whole command typed in correctly.
>>>>
>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>> run
>>>> the first 12) and it will run tasks 26 through 32, and if it is
>> successful,
>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>> also use the CI jobs that generate the emails to make sure the subject
>> and
>>>> content is correct and contains the usual instructions so we have
>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>> steps
>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>> artifacts on dist.a.o as well.
>>>>
>>>> I would like you all to help maintain the list of 100 steps and other
>>>> documents related to the release process, and improve the CI jobs and
>> Ant
>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>> that I
>>>> have hopefully explained our release process better, that we can see
>> that
>>>> these 100+ steps just have to be done in some way. The RM can figure
>> out
>>>> what way works best for them, but they must get through all of them.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
RE: Royale Releases
Posted by Yishay Weiss <yi...@hotmail.com>.
I’m fine with that. Thanks.
________________________________
From: Harbs <ha...@gmail.com>
Sent: Thursday, April 2, 2020 4:50:40 PM
To: dev@royale.apache.org <de...@royale.apache.org>
Subject: Re: Royale Releases
I spent over an hour with Alex on the Zoom last night trying to understand all the different technical points.
One point which became clear to me last night is that Ant and Maven are distributed differently so there are points of failure that one has which the other doesn’t.
I also want to stress that Alex is actually a fan of Maven.
We all want the Maven release to be easier, but somehow this is being conflated with bashing Ant.
As far as I’m concerned, the steps forward are:
1. Yishay should work on releasing 0.9.7.
2. He will hopefully be supported by Alex, Chris and Carlos to make it as smooth as possible.
3. When he’s done, I plan on sitting down with him to discuss his experience.
4. I plan on working on releasing 0.9.8 sometime in May.
5. While I’m working on 0.9.8 I expect to use Yishay’s experiences as well as my own to try and understand as much about the process as I can (Ant, Maven and NPM too).
6. I hope to work with anyone who wants to help to improve the process as much as I can.
Sounds OK?
Harbs
> On Apr 2, 2020, at 4:38 PM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi folks,
>
> I would say we have coverage for both maven ant equally as we're building the same code.
>
> However we are missing the important assertions. It's not that the Ant build is running some tests Maven isn't.
> It's just that the settings for Ant seem to be different than for Maven and the Ant ones happen to work.
>
> Ideally there would be real tests that test the output of both to see if it works in both cases.
>
> Chris
>
>
>
> Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
>
> Adding more coverage for Maven is good.
>
> Removing coverage for Ant is not.
>
> Do you agree?
>
>> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>>
>> Hi Harbs,
>>
>> I think what we're trying to say is that until now we released with Maven
>> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
>> what we were trying to cover was not covered clearly, so the premise is not
>> right.
>>
>>
>>
>> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>>
>>> No one is arguing that we shouldn’t add more tests.
>>>
>>> Please let’s not make it seem like there’s a disagreement about that.
>>>
>>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>>> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> first, many thanks for the detailed email. I'll comment on this later as
>>> I
>>>> have more time.
>>>>
>>>> For now, to add up a recent example on what Chris commented: If you all
>>>> remember a week ago I was trying to use SVG Images in a blog example that
>>>> was published 2 days ago. Nobody tried SVG Images before building with
>>>> maven, I know that since maven was not properly configured and using that
>>>> component from Maven was failing with an RTE. Probably we have more
>>> things
>>>> not working the same way when build from Maven and Ant, and that's
>>>> something that will need people using that code paths in test
>>> applications
>>>> (or in their own apps) to see if things works properly.
>>>>
>>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>>> plan to use soon as I can. I think is a great idea, since you get a
>>> Firefox
>>>> running test interface of the real use of some concrete royale code. I
>>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>>> There's already an example about FlexStore with some basic assertions.
>>>>
>>>> Again, thanks, and will comment on the rest later
>>>>
>>>> Carlos
>>>>
>>>>
>>>>
>>>>
>>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>>> christofer.dutz@c-ware.de>)
>>>> escribió:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> just a point you are bringing up: "Code coverage".
>>>>>
>>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>>> compiler. The reasoning behind this is: yes you do get more code
>>> covered,
>>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>>> results aren't tested. Did add a module to asjs years ago
>>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>>> server
>>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>>> added
>>>>> two dummy tests as an example, but seems no one touched this after me).
>>> I
>>>>> did this because I remember us working on asjs for weeks without anyone
>>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>>> little unit-tests that are still run for every example, that simply
>>> check
>>>>> if an output is generated, because we had a prolonged period of time
>>> where
>>>>> we were all working on different parts, but for quite some time the
>>>>> application compilation just didn't output anything and no one noticed.
>>>>>
>>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>>> slightly better than no coverage, but not much, in my opinion.
>>>>>
>>>>> I think in parallel to this release discussions I have seen numerous
>>>>> threads about someone doing something that broke something for someone
>>>>> else. This could be addressed by increasing coverage by providing
>>> explicit
>>>>> tests.
>>>>>
>>>>> Coming back to the releases:
>>>>> I have no objections, if you do a "release" locally and automate the
>>>>> validation on the CI server (Which effectively would be your proposal
>>> to do
>>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>>> even
>>>>> think that's a good idea ... There could be one step for building a
>>> release
>>>>> from a given "git tag" for every build system and generic means to
>>> compare
>>>>> tar.gz and zips produced by any build system with that of another
>>> (ideally
>>>>> with better output than just a plain "true/false"). This would even
>>> help to
>>>>> iron out the last potentially existing bumps out of the Maven
>>> distribution.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This is my attempt to explain what goes into a release in hopes that
>>>>> we can understand and agree on what our release process is. It became
>>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>>> talking with Harbs today that there are still many misunderstandings
>>> about
>>>>> what we do to create a release. I don't generally like writing
>>>>> instructions in English because it is easy to be ambiguous. All of the
>>>>> steps that we use to create releases had been captured in Ant scripts
>>> in a
>>>>> much more explicit way, IMO, but I took the time to write them down in
>>>>> English here:
>>>>>
>>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>>
>>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>>> the Ant scripts used in prior releases so there could certainly be
>>> mistakes
>>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>>> Future RMs, when we don't have to release build-tools, will have about
>>> 92
>>>>> steps. And I did not include voter verification checks the RM should
>>> run
>>>>> before opening a vote (verifying that the artifacts download and match
>>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>>> before
>>>>> sending out the vote. Maybe we should add those to the task list.
>>>>>
>>>>> I think there has been confusion about the use of Ant in the release
>>>>> process. Because I was the RM for the first set of FlexJS/Royale
>>> releases,
>>>>> and I'm a lazy person who hates typing at the command line, I created
>>> Ant
>>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>>> requirement that other RMs must use the Ant scripts for these
>>> commands. If
>>>>> you are the RM and like typing, go ahead.
>>>>>
>>>>> Then we found out that other people couldn't get through this task
>>>>> list. I think the 3 people who tried were having trouble with Maven
>>>>> uploads and downloads. So what I did was put the first 40 steps or so
>>> into
>>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>>> release. And that also saves on manually typing commands. But again,
>>>>> going forward, the RM gets to choose how they want to execute these
>>> steps.
>>>>>
>>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>>> once. I believe the recent threads have been about this single command
>>> out
>>>>> of the 100+ commands. This is why this has been so frustrating to me.
>>> I
>>>>> believe there is a solid technical reason for that one command: it
>>> proves
>>>>> that the build.xml files in the source packages can build the .tar.gz
>>> that
>>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>>
>>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>>> would ask that the RM complete as much of the automated code-coverage
>>>>> testing as possible before posting the release for a vote. That one
>>>>> command increases our code coverage by running the build.xml files. We
>>>>> should be always working to increase automated code coverage in the RC.
>>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>>> run
>>>>> because a failed RC means going back through many of the first 25
>>> commands
>>>>> again and wastes other people's time. Each RC is more emails to read
>>> and
>>>>> more time from the voters and testers.
>>>>>
>>>>> If there are other ways for the RM to get the same or better code
>>>>> coverage on the build.xml files before posting the RC, we can discuss
>>> those
>>>>> options.
>>>>>
>>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>>> save other people time. Let's do that in creating releases too.
>>>>>
>>>>> One issue that was brought up recently was whether it is a good
>>>>> decision to have the RM test all of the build platforms we support.
>>>>> Suppose we add some other build system support or more in the future?
>>>>> Again, the code coverage principle applies here, but also, I would like
>>> us
>>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>>> possible. So instead of having separate votes/features/release-dates
>>> for
>>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>>> artifacts, I think we should have one vote and keep them all in sync.
>>> If
>>>>> we do ever get around to monthly or bi-monthly releases, I think
>>> separate
>>>>> build platform releases would be too much work.
>>>>>
>>>>> But consider this thought I just had today: the RM doesn't really
>>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>>> separate/alternative release process, they are just another way of
>>>>> executing the first 40 steps. Using CI jobs actually requires
>>> additional
>>>>> command-line cut-and-paste to push commits on the CI server and to sign
>>> and
>>>>> validate binaries locally, but that's the trade-off of not having to
>>>>> configure your machine to successfully run all of the automated tests
>>> and
>>>>> build systems, and being able to run a command by filling in the version
>>>>> number and rc number and hitting the "ok" button instead of making sure
>>> you
>>>>> got the whole command typed in correctly.
>>>>>
>>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>>> run
>>>>> the first 12) and it will run tasks 26 through 32, and if it is
>>> successful,
>>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>>> also use the CI jobs that generate the emails to make sure the subject
>>> and
>>>>> content is correct and contains the usual instructions so we have
>>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>>> steps
>>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>>> artifacts on dist.a.o as well.
>>>>>
>>>>> I would like you all to help maintain the list of 100 steps and other
>>>>> documents related to the release process, and improve the CI jobs and
>>> Ant
>>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>>> that I
>>>>> have hopefully explained our release process better, that we can see
>>> that
>>>>> these 100+ steps just have to be done in some way. The RM can figure
>>> out
>>>>> what way works best for them, but they must get through all of them.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>
>
>
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
that's very good news! good luck with getting it :)
El vie., 10 abr. 2020 a las 7:08, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> I'm still back on getting compiler-build-tools 1.2.0 released. What was
> posted on dist for compiler-build-tools was not complete, and I am trying
> to get the CI server to do it using JGit because that is more secure, but
> had to fix a JGit bug first. I hope the first 7 steps of the actual Royale
> release go quickly once we get to that point.
>
> -Alex
>
> On 4/9/20, 12:28 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> don't understand the problem. Chris and I was able to reach step 7.
> The big
> problem is there with compiler generating classes with lines in
> different
> orders depending on OS (and probably JDK vendor). I think solving that
> will
> make you move from the problematic point. But don't understand that you
> have problems in steps 1 to 6.
>
>
>
> El jue., 9 abr. 2020 a las 9:21, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > FWIW, I saw Royale_Compiler_Build_Tools_Release_Step_002 work. I'm
> done
> > for tonight. If anyone is bored, they can try to get the
> > Royale_Compiler_Build_Tools_Release_Step_002_Sign target to work in
> > compiler-build-tools/releasesteps.xml by renaming
> > Royale_Compiler_Build_Tools_Release_Step_003_Sign and fixing up the
> paths.
> > Otherwise I will start there tomorrow evening.
> >
> > -Alex
> >
> > On 4/8/20, 9:03 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
> >
> > >sounds good :)
> >
> > Hi Carlos,
> >
> > This sounds like a good plan to me too. Alex and I will do our
> best to
> > get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8
> in May,
> > and you will be in charge of releasing 0.9.9 in June.
> >
> > Are we still in agreement on that?
> >
> > Thanks,
> > Yishay
> >
> > From: Carlos Rovira<ma...@apache.org>
> > Sent: Thursday, April 2, 2020 6:47 PM
> > To: Apache Royale Development<ma...@royale.apache.org>
> > Subject: Re: Royale Releases
> >
> > Hi Harbs,
> >
> > sounds good :)
> >
> > As well, I expect I can do 0.9.9 in June from my local machine
> with the
> > process we already exposed too :)
> >
> > Thanks
> >
> > Carlos
> >
> >
> > El jue., 2 abr. 2020 a las 15:50, Harbs (<harbs.lists@gmail.com
> >)
> > escribió:
> >
> > > I spent over an hour with Alex on the Zoom last night trying to
> > understand
> > > all the different technical points.
> > >
> > > One point which became clear to me last night is that Ant and
> Maven
> > are
> > > distributed differently so there are points of failure that
> one has
> > which
> > > the other doesn’t.
> > >
> > > I also want to stress that Alex is actually a fan of Maven.
> > >
> > > We all want the Maven release to be easier, but somehow this
> is being
> > > conflated with bashing Ant.
> > >
> > > As far as I’m concerned, the steps forward are:
> > >
> > > 1. Yishay should work on releasing 0.9.7.
> > > 2. He will hopefully be supported by Alex, Chris and Carlos to
> make
> > it as
> > > smooth as possible.
> > > 3. When he’s done, I plan on sitting down with him to discuss
> his
> > > experience.
> > > 4. I plan on working on releasing 0.9.8 sometime in May.
> > > 5. While I’m working on 0.9.8 I expect to use Yishay’s
> experiences
> > as well
> > > as my own to try and understand as much about the process as I
> can
> > (Ant,
> > > Maven and NPM too).
> > > 6. I hope to work with anyone who wants to help to improve the
> > process as
> > > much as I can.
> > >
> > > Sounds OK?
> > >
> > > Harbs
> > >
> > > > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <
> > christofer.dutz@c-ware.de>
> > > wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I would say we have coverage for both maven ant equally as
> we're
> > > building the same code.
> > > >
> > > > However we are missing the important assertions. It's not
> that the
> > Ant
> > > build is running some tests Maven isn't.
> > > > It's just that the settings for Ant seem to be different
> than for
> > Maven
> > > and the Ant ones happen to work.
> > > >
> > > > Ideally there would be real tests that test the output of
> both to
> > see if
> > > it works in both cases.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> > > >
> > > > Adding more coverage for Maven is good.
> > > >
> > > > Removing coverage for Ant is not.
> > > >
> > > > Do you agree?
> > > >
> > > >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> > carlosrovira@apache.org>
> > > wrote:
> > > >>
> > > >> Hi Harbs,
> > > >>
> > > >> I think what we're trying to say is that until now we
> released
> > with
> > > Maven
> > > >> and Ant, and that was hiding a flaw in Maven (SVG example).
> So
> > that
> > > means
> > > >> what we were trying to cover was not covered clearly, so the
> > premise is
> > > not
> > > >> right.
> > > >>
> > > >>
> > > >>
> > > >> El jue., 2 abr. 2020 a las 14:56, Harbs (<
> harbs.lists@gmail.com>)
> > > escribió:
> > > >>
> > > >>> No one is arguing that we shouldn’t add more tests.
> > > >>>
> > > >>> Please let’s not make it seem like there’s a disagreement
> about
> > that.
> > > >>>
> > > >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> > carlosrovira@apache.org>
> > > >>> wrote:
> > > >>>>
> > > >>>> Hi Alex,
> > > >>>>
> > > >>>> first, many thanks for the detailed email. I'll comment
> on this
> > later
> > > as
> > > >>> I
> > > >>>> have more time.
> > > >>>>
> > > >>>> For now, to add up a recent example on what Chris
> commented: If
> > you
> > > all
> > > >>>> remember a week ago I was trying to use SVG Images in a
> blog
> > example
> > > that
> > > >>>> was published 2 days ago. Nobody tried SVG Images before
> > building with
> > > >>>> maven, I know that since maven was not properly
> configured and
> > using
> > > that
> > > >>>> component from Maven was failing with an RTE. Probably we
> have
> > more
> > > >>> things
> > > >>>> not working the same way when build from Maven and Ant,
> and
> > that's
> > > >>>> something that will need people using that code paths in
> test
> > > >>> applications
> > > >>>> (or in their own apps) to see if things works properly.
> > > >>>>
> > > >>>> I was recently introduced to "examples-integrationtest" by
> > Chris,
> > > that I
> > > >>>> plan to use soon as I can. I think is a great idea, since
> you
> > get a
> > > >>> Firefox
> > > >>>> running test interface of the real use of some concrete
> royale
> > code. I
> > > >>>> think passed until now unnoticed by all of us, and seems a
> > powerful
> > > tool.
> > > >>>> There's already an example about FlexStore with some basic
> > assertions.
> > > >>>>
> > > >>>> Again, thanks, and will comment on the rest later
> > > >>>>
> > > >>>> Carlos
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > > >>> christofer.dutz@c-ware.de>)
> > > >>>> escribió:
> > > >>>>
> > > >>>>> Hi Alex,
> > > >>>>>
> > > >>>>> just a point you are bringing up: "Code coverage".
> > > >>>>>
> > > >>>>> I strongly dislike the idea of "asjs" effectively being
> the
> > test for
> > > the
> > > >>>>> compiler. The reasoning behind this is: yes you do get
> more
> > code
> > > >>> covered,
> > > >>>>> but only the happy-path (ideally) and even if things go
> wrong,
> > the
> > > end
> > > >>>>> results aren't tested. Did add a module to asjs years ago
> > > >>>>> ("examples-integrationtest") that deployed the examples
> in a
> > tomcat
> > > >>> server
> > > >>>>> then opens a Firefox browser and clicks through 2 of the
> > examples (I
> > > >>> added
> > > >>>>> two dummy tests as an example, but seems no one touched
> this
> > after
> > > me).
> > > >>> I
> > > >>>>> did this because I remember us working on asjs for weeks
> > without
> > > anyone
> > > >>>>> noticing the compiler wasn't producing runnable code ...
> same
> > with
> > > the
> > > >>>>> little unit-tests that are still run for every example,
> that
> > simply
> > > >>> check
> > > >>>>> if an output is generated, because we had a prolonged
> period
> > of time
> > > >>> where
> > > >>>>> we were all working on different parts, but for quite
> some
> > time the
> > > >>>>> application compilation just didn't output anything and
> no one
> > > noticed.
> > > >>>>>
> > > >>>>> So coverage is nothing without assertions (my opinion)
> ... ok
> > ...
> > > it's
> > > >>>>> slightly better than no coverage, but not much, in my
> opinion.
> > > >>>>>
> > > >>>>> I think in parallel to this release discussions I have
> seen
> > numerous
> > > >>>>> threads about someone doing something that broke
> something for
> > > someone
> > > >>>>> else. This could be addressed by increasing coverage by
> > providing
> > > >>> explicit
> > > >>>>> tests.
> > > >>>>>
> > > >>>>> Coming back to the releases:
> > > >>>>> I have no objections, if you do a "release" locally and
> > automate the
> > > >>>>> validation on the CI server (Which effectively would be
> your
> > proposal
> > > >>> to do
> > > >>>>> the first 12 steps on local hardware and the 13th on the
> CI
> > server).
> > > I
> > > >>> even
> > > >>>>> think that's a good idea ... There could be one step for
> > building a
> > > >>> release
> > > >>>>> from a given "git tag" for every build system and generic
> > means to
> > > >>> compare
> > > >>>>> tar.gz and zips produced by any build system with that of
> > another
> > > >>> (ideally
> > > >>>>> with better output than just a plain "true/false"). This
> would
> > even
> > > >>> help to
> > > >>>>> iron out the last potentially existing bumps out of the
> Maven
> > > >>> distribution.
> > > >>>>>
> > > >>>>> Chris
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> > <ah...@adobe.com.INVALID>:
> > > >>>>>
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> This is my attempt to explain what goes into a release
> in
> > hopes that
> > > >>>>> we can understand and agree on what our release process
> is. It
> > > became
> > > >>>>> apparent in my reading of the wiki page with the new
> Maven
> > steps and
> > > in
> > > >>>>> talking with Harbs today that there are still many
> > misunderstandings
> > > >>> about
> > > >>>>> what we do to create a release. I don't generally like
> writing
> > > >>>>> instructions in English because it is easy to be
> ambiguous.
> > All of
> > > the
> > > >>>>> steps that we use to create releases had been captured
> in Ant
> > scripts
> > > >>> in a
> > > >>>>> much more explicit way, IMO, but I took the time to
> write them
> > down
> > > in
> > > >>>>> English here:
> > > >>>>>
> > > >>>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243311339&sdata=kCFsrIpYZG9ZUk6hbZPaqtfGoIaVWjUo3ZBlfb98aNs%3D&reserved=0
> > > >>>>>
> > > >>>>> I did this quickly by scanning the CI steps, the new
> Maven
> > steps and
> > > >>>>> the Ant scripts used in prior releases so there could
> > certainly be
> > > >>> mistakes
> > > >>>>> and missed steps. If I did my math right, the RM for
> 0.9.7
> > will
> > > have to
> > > >>>>> complete over 100 tasks (essentially, typing a
> command-line 100
> > > times).
> > > >>>>> Future RMs, when we don't have to release build-tools,
> will
> > have
> > > about
> > > >>> 92
> > > >>>>> steps. And I did not include voter verification checks
> the RM
> > should
> > > >>> run
> > > >>>>> before opening a vote (verifying that the artifacts
> download
> > and
> > > match
> > > >>>>> their checksums, etc). As an RM, I run a bunch of tests
> on
> > the RC
> > > >>> before
> > > >>>>> sending out the vote. Maybe we should add those to the
> task
> > list.
> > > >>>>>
> > > >>>>> I think there has been confusion about the use of Ant
> in the
> > release
> > > >>>>> process. Because I was the RM for the first set of
> > FlexJS/Royale
> > > >>> releases,
> > > >>>>> and I'm a lazy person who hates typing at the command
> line, I
> > created
> > > >>> Ant
> > > >>>>> scripts to execute these 100 steps. But I agree that it
> is
> > not a
> > > >>>>> requirement that other RMs must use the Ant scripts for
> these
> > > >>> commands. If
> > > >>>>> you are the RM and like typing, go ahead.
> > > >>>>>
> > > >>>>> Then we found out that other people couldn't get
> through this
> > task
> > > >>>>> list. I think the 3 people who tried were having
> trouble with
> > Maven
> > > >>>>> uploads and downloads. So what I did was put the first
> 40
> > steps or
> > > so
> > > >>> into
> > > >>>>> Jenkins jobs. And by doing that, Piotr was able to
> produce
> > our last
> > > >>>>> release. And that also saves on manually typing
> commands. But
> > > again,
> > > >>>>> going forward, the RM gets to choose how they want to
> execute
> > these
> > > >>> steps.
> > > >>>>>
> > > >>>>> If you scan the set of steps, you'll see that "ant" is
> only
> > in there
> > > >>>>> once. I believe the recent threads have been about this
> single
> > > command
> > > >>> out
> > > >>>>> of the 100+ commands. This is why this has been so
> > frustrating to
> > > me.
> > > >>> I
> > > >>>>> believe there is a solid technical reason for that one
> > command: it
> > > >>> proves
> > > >>>>> that the build.xml files in the source packages can
> build the
> > .tar.gz
> > > >>> that
> > > >>>>> are useful to NPM and IDE users who use Ant and want to
> test a
> > > change.
> > > >>>>>
> > > >>>>> I think of it as code-coverage. If we had code-coverage
> > tools, we
> > > >>>>> would ask that the RM complete as much of the automated
> > code-coverage
> > > >>>>> testing as possible before posting the release for a
> vote.
> > That one
> > > >>>>> command increases our code coverage by running the
> build.xml
> > files.
> > > We
> > > >>>>> should be always working to increase automated code
> coverage
> > in the
> > > RC.
> > > >>>>> Certainly for me as RM, I will gladly watch TV as the
> > automated tests
> > > >>> run
> > > >>>>> because a failed RC means going back through many of the
> first
> > 25
> > > >>> commands
> > > >>>>> again and wastes other people's time. Each RC is more
> emails
> > to read
> > > >>> and
> > > >>>>> more time from the voters and testers.
> > > >>>>>
> > > >>>>> If there are other ways for the RM to get the same or
> better
> > code
> > > >>>>> coverage on the build.xml files before posting the RC,
> we can
> > discuss
> > > >>> those
> > > >>>>> options.
> > > >>>>>
> > > >>>>> I am hopeful we can all agree on these simple
> principles:
> > Strive
> > > for
> > > >>>>> better code coverage and fewer failed RCs. Royale's main
> > purpose is
> > > to
> > > >>>>> save other people time. Let's do that in creating
> releases
> > too.
> > > >>>>>
> > > >>>>> One issue that was brought up recently was whether it
> is a
> > good
> > > >>>>> decision to have the RM test all of the build platforms
> we
> > support.
> > > >>>>> Suppose we add some other build system support or more
> in the
> > future?
> > > >>>>> Again, the code coverage principle applies here, but
> also, I
> > would
> > > like
> > > >>> us
> > > >>>>> to retain feature parity, and I also hope for as few RCs
> and
> > votes as
> > > >>>>> possible. So instead of having separate
> > votes/features/release-dates
> > > >>> for
> > > >>>>> the Maven artifacts vs the Ant artifacts vs the
> > SomeFutureBuildTech
> > > >>>>> artifacts, I think we should have one vote and keep them
> all
> > in sync.
> > > >>> If
> > > >>>>> we do ever get around to monthly or bi-monthly releases,
> I
> > think
> > > >>> separate
> > > >>>>> build platform releases would be too much work.
> > > >>>>>
> > > >>>>> But consider this thought I just had today: the RM
> doesn't
> > really
> > > >>>>> have to choose to do all 100 commands on a local machine
> or
> > with Ant
> > > >>>>> scripts or do the first 40 via CI. The RM can actually
> pick
> > and
> > > choose
> > > >>>>> commands to run on the CI server. The CI Jenkins jobs
> are not
> > a
> > > >>>>> separate/alternative release process, they are just
> another
> > way of
> > > >>>>> executing the first 40 steps. Using CI jobs actually
> requires
> > > >>> additional
> > > >>>>> command-line cut-and-paste to push commits on the CI
> server
> > and to
> > > sign
> > > >>> and
> > > >>>>> validate binaries locally, but that's the trade-off of
> not
> > having to
> > > >>>>> configure your machine to successfully run all of the
> > automated tests
> > > >>> and
> > > >>>>> build systems, and being able to run a command by
> filling in
> > the
> > > version
> > > >>>>> number and rc number and hitting the "ok" button instead
> of
> > making
> > > sure
> > > >>> you
> > > >>>>> got the whole command typed in correctly.
> > > >>>>>
> > > >>>>> So, an RM can run the first 25 steps locally, then go
> the CI
> > server
> > > >>>>> and run what is now Jenkins Job
> "Royale_Release_Step_013" (no
> > need to
> > > >>> run
> > > >>>>> the first 12) and it will run tasks 26 through 32, and
> if it is
> > > >>> successful,
> > > >>>>> then the RM has proven code coverage of the build.xml
> files.
> > (If the
> > > >>>>> resulting tar.gz and zips are not posted, then the RM
> should
> > verify
> > > that
> > > >>>>> they match the ones from Maven distribution). I would
> > encourage RMs
> > > to
> > > >>>>> also use the CI jobs that generate the emails to make
> sure the
> > > subject
> > > >>> and
> > > >>>>> content is correct and contains the usual instructions
> so we
> > have
> > > >>>>> consistency. Maybe someday there will be CI jobs to do
> the
> > last 60+
> > > >>> steps
> > > >>>>> if that helps. We could add a Jenkins job that runs an
> Ant
> > build on
> > > RC
> > > >>>>> artifacts on dist.a.o as well.
> > > >>>>>
> > > >>>>> I would like you all to help maintain the list of 100
> steps
> > and
> > > other
> > > >>>>> documents related to the release process, and improve
> the CI
> > jobs and
> > > >>> Ant
> > > >>>>> steps if it helps you be a more efficient RM. I am
> hopeful
> > that now
> > > >>> that I
> > > >>>>> have hopefully explained our release process better,
> that we
> > can see
> > > >>> that
> > > >>>>> these 100+ steps just have to be done in some way. The
> RM can
> > figure
> > > >>> out
> > > >>>>> what way works best for them, but they must get through
> all of
> > them.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> -Alex
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>> --
> > > >>>> Carlos Rovira
> > > >>>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243311339&sdata=zhSGBpwSbNGTi7hyxmt%2BEVqr7FB482WmDn8zK6NAicg%3D&reserved=0
> > > >>>
> > > >>>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0
> > > >
> > > >
> > > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I have seen the CI server produce a valid set of bits for compiler-build-tools 1.2.0. Yishay, please find time to try out the Royale_Compiler_Build_Tools_Release_Steps_001 and others.
I will be testing out the Royale_Release_Steps shortly.
-Alex
On 4/9/20, 10:08 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
Hi Carlos,
I'm still back on getting compiler-build-tools 1.2.0 released. What was posted on dist for compiler-build-tools was not complete, and I am trying to get the CI server to do it using JGit because that is more secure, but had to fix a JGit bug first. I hope the first 7 steps of the actual Royale release go quickly once we get to that point.
-Alex
On 4/9/20, 12:28 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
don't understand the problem. Chris and I was able to reach step 7. The big
problem is there with compiler generating classes with lines in different
orders depending on OS (and probably JDK vendor). I think solving that will
make you move from the problematic point. But don't understand that you
have problems in steps 1 to 6.
El jue., 9 abr. 2020 a las 9:21, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> FWIW, I saw Royale_Compiler_Build_Tools_Release_Step_002 work. I'm done
> for tonight. If anyone is bored, they can try to get the
> Royale_Compiler_Build_Tools_Release_Step_002_Sign target to work in
> compiler-build-tools/releasesteps.xml by renaming
> Royale_Compiler_Build_Tools_Release_Step_003_Sign and fixing up the paths.
> Otherwise I will start there tomorrow evening.
>
> -Alex
>
> On 4/8/20, 9:03 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
> >sounds good :)
>
> Hi Carlos,
>
> This sounds like a good plan to me too. Alex and I will do our best to
> get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May,
> and you will be in charge of releasing 0.9.9 in June.
>
> Are we still in agreement on that?
>
> Thanks,
> Yishay
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Thursday, April 2, 2020 6:47 PM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: Royale Releases
>
> Hi Harbs,
>
> sounds good :)
>
> As well, I expect I can do 0.9.9 in June from my local machine with the
> process we already exposed too :)
>
> Thanks
>
> Carlos
>
>
> El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > I spent over an hour with Alex on the Zoom last night trying to
> understand
> > all the different technical points.
> >
> > One point which became clear to me last night is that Ant and Maven
> are
> > distributed differently so there are points of failure that one has
> which
> > the other doesn’t.
> >
> > I also want to stress that Alex is actually a fan of Maven.
> >
> > We all want the Maven release to be easier, but somehow this is being
> > conflated with bashing Ant.
> >
> > As far as I’m concerned, the steps forward are:
> >
> > 1. Yishay should work on releasing 0.9.7.
> > 2. He will hopefully be supported by Alex, Chris and Carlos to make
> it as
> > smooth as possible.
> > 3. When he’s done, I plan on sitting down with him to discuss his
> > experience.
> > 4. I plan on working on releasing 0.9.8 sometime in May.
> > 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences
> as well
> > as my own to try and understand as much about the process as I can
> (Ant,
> > Maven and NPM too).
> > 6. I hope to work with anyone who wants to help to improve the
> process as
> > much as I can.
> >
> > Sounds OK?
> >
> > Harbs
> >
> > > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <
> christofer.dutz@c-ware.de>
> > wrote:
> > >
> > > Hi folks,
> > >
> > > I would say we have coverage for both maven ant equally as we're
> > building the same code.
> > >
> > > However we are missing the important assertions. It's not that the
> Ant
> > build is running some tests Maven isn't.
> > > It's just that the settings for Ant seem to be different than for
> Maven
> > and the Ant ones happen to work.
> > >
> > > Ideally there would be real tests that test the output of both to
> see if
> > it works in both cases.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> > >
> > > Adding more coverage for Maven is good.
> > >
> > > Removing coverage for Ant is not.
> > >
> > > Do you agree?
> > >
> > >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> carlosrovira@apache.org>
> > wrote:
> > >>
> > >> Hi Harbs,
> > >>
> > >> I think what we're trying to say is that until now we released
> with
> > Maven
> > >> and Ant, and that was hiding a flaw in Maven (SVG example). So
> that
> > means
> > >> what we were trying to cover was not covered clearly, so the
> premise is
> > not
> > >> right.
> > >>
> > >>
> > >>
> > >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> > escribió:
> > >>
> > >>> No one is arguing that we shouldn’t add more tests.
> > >>>
> > >>> Please let’s not make it seem like there’s a disagreement about
> that.
> > >>>
> > >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> carlosrovira@apache.org>
> > >>> wrote:
> > >>>>
> > >>>> Hi Alex,
> > >>>>
> > >>>> first, many thanks for the detailed email. I'll comment on this
> later
> > as
> > >>> I
> > >>>> have more time.
> > >>>>
> > >>>> For now, to add up a recent example on what Chris commented: If
> you
> > all
> > >>>> remember a week ago I was trying to use SVG Images in a blog
> example
> > that
> > >>>> was published 2 days ago. Nobody tried SVG Images before
> building with
> > >>>> maven, I know that since maven was not properly configured and
> using
> > that
> > >>>> component from Maven was failing with an RTE. Probably we have
> more
> > >>> things
> > >>>> not working the same way when build from Maven and Ant, and
> that's
> > >>>> something that will need people using that code paths in test
> > >>> applications
> > >>>> (or in their own apps) to see if things works properly.
> > >>>>
> > >>>> I was recently introduced to "examples-integrationtest" by
> Chris,
> > that I
> > >>>> plan to use soon as I can. I think is a great idea, since you
> get a
> > >>> Firefox
> > >>>> running test interface of the real use of some concrete royale
> code. I
> > >>>> think passed until now unnoticed by all of us, and seems a
> powerful
> > tool.
> > >>>> There's already an example about FlexStore with some basic
> assertions.
> > >>>>
> > >>>> Again, thanks, and will comment on the rest later
> > >>>>
> > >>>> Carlos
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > >>> christofer.dutz@c-ware.de>)
> > >>>> escribió:
> > >>>>
> > >>>>> Hi Alex,
> > >>>>>
> > >>>>> just a point you are bringing up: "Code coverage".
> > >>>>>
> > >>>>> I strongly dislike the idea of "asjs" effectively being the
> test for
> > the
> > >>>>> compiler. The reasoning behind this is: yes you do get more
> code
> > >>> covered,
> > >>>>> but only the happy-path (ideally) and even if things go wrong,
> the
> > end
> > >>>>> results aren't tested. Did add a module to asjs years ago
> > >>>>> ("examples-integrationtest") that deployed the examples in a
> tomcat
> > >>> server
> > >>>>> then opens a Firefox browser and clicks through 2 of the
> examples (I
> > >>> added
> > >>>>> two dummy tests as an example, but seems no one touched this
> after
> > me).
> > >>> I
> > >>>>> did this because I remember us working on asjs for weeks
> without
> > anyone
> > >>>>> noticing the compiler wasn't producing runnable code ... same
> with
> > the
> > >>>>> little unit-tests that are still run for every example, that
> simply
> > >>> check
> > >>>>> if an output is generated, because we had a prolonged period
> of time
> > >>> where
> > >>>>> we were all working on different parts, but for quite some
> time the
> > >>>>> application compilation just didn't output anything and no one
> > noticed.
> > >>>>>
> > >>>>> So coverage is nothing without assertions (my opinion) ... ok
> ...
> > it's
> > >>>>> slightly better than no coverage, but not much, in my opinion.
> > >>>>>
> > >>>>> I think in parallel to this release discussions I have seen
> numerous
> > >>>>> threads about someone doing something that broke something for
> > someone
> > >>>>> else. This could be addressed by increasing coverage by
> providing
> > >>> explicit
> > >>>>> tests.
> > >>>>>
> > >>>>> Coming back to the releases:
> > >>>>> I have no objections, if you do a "release" locally and
> automate the
> > >>>>> validation on the CI server (Which effectively would be your
> proposal
> > >>> to do
> > >>>>> the first 12 steps on local hardware and the 13th on the CI
> server).
> > I
> > >>> even
> > >>>>> think that's a good idea ... There could be one step for
> building a
> > >>> release
> > >>>>> from a given "git tag" for every build system and generic
> means to
> > >>> compare
> > >>>>> tar.gz and zips produced by any build system with that of
> another
> > >>> (ideally
> > >>>>> with better output than just a plain "true/false"). This would
> even
> > >>> help to
> > >>>>> iron out the last potentially existing bumps out of the Maven
> > >>> distribution.
> > >>>>>
> > >>>>> Chris
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> <ah...@adobe.com.INVALID>:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> This is my attempt to explain what goes into a release in
> hopes that
> > >>>>> we can understand and agree on what our release process is. It
> > became
> > >>>>> apparent in my reading of the wiki page with the new Maven
> steps and
> > in
> > >>>>> talking with Harbs today that there are still many
> misunderstandings
> > >>> about
> > >>>>> what we do to create a release. I don't generally like writing
> > >>>>> instructions in English because it is easy to be ambiguous.
> All of
> > the
> > >>>>> steps that we use to create releases had been captured in Ant
> scripts
> > >>> in a
> > >>>>> much more explicit way, IMO, but I took the time to write them
> down
> > in
> > >>>>> English here:
> > >>>>>
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C6b91bc1eaebb42a6c63608d7dd0d2f75%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220921015610688&sdata=mdxxorwRJaqIxpjv%2FK9gDL4wWx%2FJOhHMPzuPmdbgwJY%3D&reserved=0
> > >>>>>
> > >>>>> I did this quickly by scanning the CI steps, the new Maven
> steps and
> > >>>>> the Ant scripts used in prior releases so there could
> certainly be
> > >>> mistakes
> > >>>>> and missed steps. If I did my math right, the RM for 0.9.7
> will
> > have to
> > >>>>> complete over 100 tasks (essentially, typing a command-line 100
> > times).
> > >>>>> Future RMs, when we don't have to release build-tools, will
> have
> > about
> > >>> 92
> > >>>>> steps. And I did not include voter verification checks the RM
> should
> > >>> run
> > >>>>> before opening a vote (verifying that the artifacts download
> and
> > match
> > >>>>> their checksums, etc). As an RM, I run a bunch of tests on
> the RC
> > >>> before
> > >>>>> sending out the vote. Maybe we should add those to the task
> list.
> > >>>>>
> > >>>>> I think there has been confusion about the use of Ant in the
> release
> > >>>>> process. Because I was the RM for the first set of
> FlexJS/Royale
> > >>> releases,
> > >>>>> and I'm a lazy person who hates typing at the command line, I
> created
> > >>> Ant
> > >>>>> scripts to execute these 100 steps. But I agree that it is
> not a
> > >>>>> requirement that other RMs must use the Ant scripts for these
> > >>> commands. If
> > >>>>> you are the RM and like typing, go ahead.
> > >>>>>
> > >>>>> Then we found out that other people couldn't get through this
> task
> > >>>>> list. I think the 3 people who tried were having trouble with
> Maven
> > >>>>> uploads and downloads. So what I did was put the first 40
> steps or
> > so
> > >>> into
> > >>>>> Jenkins jobs. And by doing that, Piotr was able to produce
> our last
> > >>>>> release. And that also saves on manually typing commands. But
> > again,
> > >>>>> going forward, the RM gets to choose how they want to execute
> these
> > >>> steps.
> > >>>>>
> > >>>>> If you scan the set of steps, you'll see that "ant" is only
> in there
> > >>>>> once. I believe the recent threads have been about this single
> > command
> > >>> out
> > >>>>> of the 100+ commands. This is why this has been so
> frustrating to
> > me.
> > >>> I
> > >>>>> believe there is a solid technical reason for that one
> command: it
> > >>> proves
> > >>>>> that the build.xml files in the source packages can build the
> .tar.gz
> > >>> that
> > >>>>> are useful to NPM and IDE users who use Ant and want to test a
> > change.
> > >>>>>
> > >>>>> I think of it as code-coverage. If we had code-coverage
> tools, we
> > >>>>> would ask that the RM complete as much of the automated
> code-coverage
> > >>>>> testing as possible before posting the release for a vote.
> That one
> > >>>>> command increases our code coverage by running the build.xml
> files.
> > We
> > >>>>> should be always working to increase automated code coverage
> in the
> > RC.
> > >>>>> Certainly for me as RM, I will gladly watch TV as the
> automated tests
> > >>> run
> > >>>>> because a failed RC means going back through many of the first
> 25
> > >>> commands
> > >>>>> again and wastes other people's time. Each RC is more emails
> to read
> > >>> and
> > >>>>> more time from the voters and testers.
> > >>>>>
> > >>>>> If there are other ways for the RM to get the same or better
> code
> > >>>>> coverage on the build.xml files before posting the RC, we can
> discuss
> > >>> those
> > >>>>> options.
> > >>>>>
> > >>>>> I am hopeful we can all agree on these simple principles:
> Strive
> > for
> > >>>>> better code coverage and fewer failed RCs. Royale's main
> purpose is
> > to
> > >>>>> save other people time. Let's do that in creating releases
> too.
> > >>>>>
> > >>>>> One issue that was brought up recently was whether it is a
> good
> > >>>>> decision to have the RM test all of the build platforms we
> support.
> > >>>>> Suppose we add some other build system support or more in the
> future?
> > >>>>> Again, the code coverage principle applies here, but also, I
> would
> > like
> > >>> us
> > >>>>> to retain feature parity, and I also hope for as few RCs and
> votes as
> > >>>>> possible. So instead of having separate
> votes/features/release-dates
> > >>> for
> > >>>>> the Maven artifacts vs the Ant artifacts vs the
> SomeFutureBuildTech
> > >>>>> artifacts, I think we should have one vote and keep them all
> in sync.
> > >>> If
> > >>>>> we do ever get around to monthly or bi-monthly releases, I
> think
> > >>> separate
> > >>>>> build platform releases would be too much work.
> > >>>>>
> > >>>>> But consider this thought I just had today: the RM doesn't
> really
> > >>>>> have to choose to do all 100 commands on a local machine or
> with Ant
> > >>>>> scripts or do the first 40 via CI. The RM can actually pick
> and
> > choose
> > >>>>> commands to run on the CI server. The CI Jenkins jobs are not
> a
> > >>>>> separate/alternative release process, they are just another
> way of
> > >>>>> executing the first 40 steps. Using CI jobs actually requires
> > >>> additional
> > >>>>> command-line cut-and-paste to push commits on the CI server
> and to
> > sign
> > >>> and
> > >>>>> validate binaries locally, but that's the trade-off of not
> having to
> > >>>>> configure your machine to successfully run all of the
> automated tests
> > >>> and
> > >>>>> build systems, and being able to run a command by filling in
> the
> > version
> > >>>>> number and rc number and hitting the "ok" button instead of
> making
> > sure
> > >>> you
> > >>>>> got the whole command typed in correctly.
> > >>>>>
> > >>>>> So, an RM can run the first 25 steps locally, then go the CI
> server
> > >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no
> need to
> > >>> run
> > >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> > >>> successful,
> > >>>>> then the RM has proven code coverage of the build.xml files.
> (If the
> > >>>>> resulting tar.gz and zips are not posted, then the RM should
> verify
> > that
> > >>>>> they match the ones from Maven distribution). I would
> encourage RMs
> > to
> > >>>>> also use the CI jobs that generate the emails to make sure the
> > subject
> > >>> and
> > >>>>> content is correct and contains the usual instructions so we
> have
> > >>>>> consistency. Maybe someday there will be CI jobs to do the
> last 60+
> > >>> steps
> > >>>>> if that helps. We could add a Jenkins job that runs an Ant
> build on
> > RC
> > >>>>> artifacts on dist.a.o as well.
> > >>>>>
> > >>>>> I would like you all to help maintain the list of 100 steps
> and
> > other
> > >>>>> documents related to the release process, and improve the CI
> jobs and
> > >>> Ant
> > >>>>> steps if it helps you be a more efficient RM. I am hopeful
> that now
> > >>> that I
> > >>>>> have hopefully explained our release process better, that we
> can see
> > >>> that
> > >>>>> these 100+ steps just have to be done in some way. The RM can
> figure
> > >>> out
> > >>>>> what way works best for them, but they must get through all of
> them.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Alex
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Rovira
> > >>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6b91bc1eaebb42a6c63608d7dd0d2f75%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220921015610688&sdata=deUpHgjUB0n57ZXyb6Jy3xGjDnI6SyU9NKEZWQvtTrQ%3D&reserved=0
> > >>>
> > >>>
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6b91bc1eaebb42a6c63608d7dd0d2f75%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220921015610688&sdata=deUpHgjUB0n57ZXyb6Jy3xGjDnI6SyU9NKEZWQvtTrQ%3D&reserved=0
> > >
> > >
> > >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6b91bc1eaebb42a6c63608d7dd0d2f75%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220921015610688&sdata=deUpHgjUB0n57ZXyb6Jy3xGjDnI6SyU9NKEZWQvtTrQ%3D&reserved=0
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6b91bc1eaebb42a6c63608d7dd0d2f75%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220921015610688&sdata=deUpHgjUB0n57ZXyb6Jy3xGjDnI6SyU9NKEZWQvtTrQ%3D&reserved=0
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I'm still back on getting compiler-build-tools 1.2.0 released. What was posted on dist for compiler-build-tools was not complete, and I am trying to get the CI server to do it using JGit because that is more secure, but had to fix a JGit bug first. I hope the first 7 steps of the actual Royale release go quickly once we get to that point.
-Alex
On 4/9/20, 12:28 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
don't understand the problem. Chris and I was able to reach step 7. The big
problem is there with compiler generating classes with lines in different
orders depending on OS (and probably JDK vendor). I think solving that will
make you move from the problematic point. But don't understand that you
have problems in steps 1 to 6.
El jue., 9 abr. 2020 a las 9:21, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> FWIW, I saw Royale_Compiler_Build_Tools_Release_Step_002 work. I'm done
> for tonight. If anyone is bored, they can try to get the
> Royale_Compiler_Build_Tools_Release_Step_002_Sign target to work in
> compiler-build-tools/releasesteps.xml by renaming
> Royale_Compiler_Build_Tools_Release_Step_003_Sign and fixing up the paths.
> Otherwise I will start there tomorrow evening.
>
> -Alex
>
> On 4/8/20, 9:03 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
> >sounds good :)
>
> Hi Carlos,
>
> This sounds like a good plan to me too. Alex and I will do our best to
> get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May,
> and you will be in charge of releasing 0.9.9 in June.
>
> Are we still in agreement on that?
>
> Thanks,
> Yishay
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Thursday, April 2, 2020 6:47 PM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: Royale Releases
>
> Hi Harbs,
>
> sounds good :)
>
> As well, I expect I can do 0.9.9 in June from my local machine with the
> process we already exposed too :)
>
> Thanks
>
> Carlos
>
>
> El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > I spent over an hour with Alex on the Zoom last night trying to
> understand
> > all the different technical points.
> >
> > One point which became clear to me last night is that Ant and Maven
> are
> > distributed differently so there are points of failure that one has
> which
> > the other doesn’t.
> >
> > I also want to stress that Alex is actually a fan of Maven.
> >
> > We all want the Maven release to be easier, but somehow this is being
> > conflated with bashing Ant.
> >
> > As far as I’m concerned, the steps forward are:
> >
> > 1. Yishay should work on releasing 0.9.7.
> > 2. He will hopefully be supported by Alex, Chris and Carlos to make
> it as
> > smooth as possible.
> > 3. When he’s done, I plan on sitting down with him to discuss his
> > experience.
> > 4. I plan on working on releasing 0.9.8 sometime in May.
> > 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences
> as well
> > as my own to try and understand as much about the process as I can
> (Ant,
> > Maven and NPM too).
> > 6. I hope to work with anyone who wants to help to improve the
> process as
> > much as I can.
> >
> > Sounds OK?
> >
> > Harbs
> >
> > > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <
> christofer.dutz@c-ware.de>
> > wrote:
> > >
> > > Hi folks,
> > >
> > > I would say we have coverage for both maven ant equally as we're
> > building the same code.
> > >
> > > However we are missing the important assertions. It's not that the
> Ant
> > build is running some tests Maven isn't.
> > > It's just that the settings for Ant seem to be different than for
> Maven
> > and the Ant ones happen to work.
> > >
> > > Ideally there would be real tests that test the output of both to
> see if
> > it works in both cases.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> > >
> > > Adding more coverage for Maven is good.
> > >
> > > Removing coverage for Ant is not.
> > >
> > > Do you agree?
> > >
> > >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> carlosrovira@apache.org>
> > wrote:
> > >>
> > >> Hi Harbs,
> > >>
> > >> I think what we're trying to say is that until now we released
> with
> > Maven
> > >> and Ant, and that was hiding a flaw in Maven (SVG example). So
> that
> > means
> > >> what we were trying to cover was not covered clearly, so the
> premise is
> > not
> > >> right.
> > >>
> > >>
> > >>
> > >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> > escribió:
> > >>
> > >>> No one is arguing that we shouldn’t add more tests.
> > >>>
> > >>> Please let’s not make it seem like there’s a disagreement about
> that.
> > >>>
> > >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> carlosrovira@apache.org>
> > >>> wrote:
> > >>>>
> > >>>> Hi Alex,
> > >>>>
> > >>>> first, many thanks for the detailed email. I'll comment on this
> later
> > as
> > >>> I
> > >>>> have more time.
> > >>>>
> > >>>> For now, to add up a recent example on what Chris commented: If
> you
> > all
> > >>>> remember a week ago I was trying to use SVG Images in a blog
> example
> > that
> > >>>> was published 2 days ago. Nobody tried SVG Images before
> building with
> > >>>> maven, I know that since maven was not properly configured and
> using
> > that
> > >>>> component from Maven was failing with an RTE. Probably we have
> more
> > >>> things
> > >>>> not working the same way when build from Maven and Ant, and
> that's
> > >>>> something that will need people using that code paths in test
> > >>> applications
> > >>>> (or in their own apps) to see if things works properly.
> > >>>>
> > >>>> I was recently introduced to "examples-integrationtest" by
> Chris,
> > that I
> > >>>> plan to use soon as I can. I think is a great idea, since you
> get a
> > >>> Firefox
> > >>>> running test interface of the real use of some concrete royale
> code. I
> > >>>> think passed until now unnoticed by all of us, and seems a
> powerful
> > tool.
> > >>>> There's already an example about FlexStore with some basic
> assertions.
> > >>>>
> > >>>> Again, thanks, and will comment on the rest later
> > >>>>
> > >>>> Carlos
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > >>> christofer.dutz@c-ware.de>)
> > >>>> escribió:
> > >>>>
> > >>>>> Hi Alex,
> > >>>>>
> > >>>>> just a point you are bringing up: "Code coverage".
> > >>>>>
> > >>>>> I strongly dislike the idea of "asjs" effectively being the
> test for
> > the
> > >>>>> compiler. The reasoning behind this is: yes you do get more
> code
> > >>> covered,
> > >>>>> but only the happy-path (ideally) and even if things go wrong,
> the
> > end
> > >>>>> results aren't tested. Did add a module to asjs years ago
> > >>>>> ("examples-integrationtest") that deployed the examples in a
> tomcat
> > >>> server
> > >>>>> then opens a Firefox browser and clicks through 2 of the
> examples (I
> > >>> added
> > >>>>> two dummy tests as an example, but seems no one touched this
> after
> > me).
> > >>> I
> > >>>>> did this because I remember us working on asjs for weeks
> without
> > anyone
> > >>>>> noticing the compiler wasn't producing runnable code ... same
> with
> > the
> > >>>>> little unit-tests that are still run for every example, that
> simply
> > >>> check
> > >>>>> if an output is generated, because we had a prolonged period
> of time
> > >>> where
> > >>>>> we were all working on different parts, but for quite some
> time the
> > >>>>> application compilation just didn't output anything and no one
> > noticed.
> > >>>>>
> > >>>>> So coverage is nothing without assertions (my opinion) ... ok
> ...
> > it's
> > >>>>> slightly better than no coverage, but not much, in my opinion.
> > >>>>>
> > >>>>> I think in parallel to this release discussions I have seen
> numerous
> > >>>>> threads about someone doing something that broke something for
> > someone
> > >>>>> else. This could be addressed by increasing coverage by
> providing
> > >>> explicit
> > >>>>> tests.
> > >>>>>
> > >>>>> Coming back to the releases:
> > >>>>> I have no objections, if you do a "release" locally and
> automate the
> > >>>>> validation on the CI server (Which effectively would be your
> proposal
> > >>> to do
> > >>>>> the first 12 steps on local hardware and the 13th on the CI
> server).
> > I
> > >>> even
> > >>>>> think that's a good idea ... There could be one step for
> building a
> > >>> release
> > >>>>> from a given "git tag" for every build system and generic
> means to
> > >>> compare
> > >>>>> tar.gz and zips produced by any build system with that of
> another
> > >>> (ideally
> > >>>>> with better output than just a plain "true/false"). This would
> even
> > >>> help to
> > >>>>> iron out the last potentially existing bumps out of the Maven
> > >>> distribution.
> > >>>>>
> > >>>>> Chris
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> <ah...@adobe.com.INVALID>:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> This is my attempt to explain what goes into a release in
> hopes that
> > >>>>> we can understand and agree on what our release process is. It
> > became
> > >>>>> apparent in my reading of the wiki page with the new Maven
> steps and
> > in
> > >>>>> talking with Harbs today that there are still many
> misunderstandings
> > >>> about
> > >>>>> what we do to create a release. I don't generally like writing
> > >>>>> instructions in English because it is easy to be ambiguous.
> All of
> > the
> > >>>>> steps that we use to create releases had been captured in Ant
> scripts
> > >>> in a
> > >>>>> much more explicit way, IMO, but I took the time to write them
> down
> > in
> > >>>>> English here:
> > >>>>>
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243311339&sdata=kCFsrIpYZG9ZUk6hbZPaqtfGoIaVWjUo3ZBlfb98aNs%3D&reserved=0
> > >>>>>
> > >>>>> I did this quickly by scanning the CI steps, the new Maven
> steps and
> > >>>>> the Ant scripts used in prior releases so there could
> certainly be
> > >>> mistakes
> > >>>>> and missed steps. If I did my math right, the RM for 0.9.7
> will
> > have to
> > >>>>> complete over 100 tasks (essentially, typing a command-line 100
> > times).
> > >>>>> Future RMs, when we don't have to release build-tools, will
> have
> > about
> > >>> 92
> > >>>>> steps. And I did not include voter verification checks the RM
> should
> > >>> run
> > >>>>> before opening a vote (verifying that the artifacts download
> and
> > match
> > >>>>> their checksums, etc). As an RM, I run a bunch of tests on
> the RC
> > >>> before
> > >>>>> sending out the vote. Maybe we should add those to the task
> list.
> > >>>>>
> > >>>>> I think there has been confusion about the use of Ant in the
> release
> > >>>>> process. Because I was the RM for the first set of
> FlexJS/Royale
> > >>> releases,
> > >>>>> and I'm a lazy person who hates typing at the command line, I
> created
> > >>> Ant
> > >>>>> scripts to execute these 100 steps. But I agree that it is
> not a
> > >>>>> requirement that other RMs must use the Ant scripts for these
> > >>> commands. If
> > >>>>> you are the RM and like typing, go ahead.
> > >>>>>
> > >>>>> Then we found out that other people couldn't get through this
> task
> > >>>>> list. I think the 3 people who tried were having trouble with
> Maven
> > >>>>> uploads and downloads. So what I did was put the first 40
> steps or
> > so
> > >>> into
> > >>>>> Jenkins jobs. And by doing that, Piotr was able to produce
> our last
> > >>>>> release. And that also saves on manually typing commands. But
> > again,
> > >>>>> going forward, the RM gets to choose how they want to execute
> these
> > >>> steps.
> > >>>>>
> > >>>>> If you scan the set of steps, you'll see that "ant" is only
> in there
> > >>>>> once. I believe the recent threads have been about this single
> > command
> > >>> out
> > >>>>> of the 100+ commands. This is why this has been so
> frustrating to
> > me.
> > >>> I
> > >>>>> believe there is a solid technical reason for that one
> command: it
> > >>> proves
> > >>>>> that the build.xml files in the source packages can build the
> .tar.gz
> > >>> that
> > >>>>> are useful to NPM and IDE users who use Ant and want to test a
> > change.
> > >>>>>
> > >>>>> I think of it as code-coverage. If we had code-coverage
> tools, we
> > >>>>> would ask that the RM complete as much of the automated
> code-coverage
> > >>>>> testing as possible before posting the release for a vote.
> That one
> > >>>>> command increases our code coverage by running the build.xml
> files.
> > We
> > >>>>> should be always working to increase automated code coverage
> in the
> > RC.
> > >>>>> Certainly for me as RM, I will gladly watch TV as the
> automated tests
> > >>> run
> > >>>>> because a failed RC means going back through many of the first
> 25
> > >>> commands
> > >>>>> again and wastes other people's time. Each RC is more emails
> to read
> > >>> and
> > >>>>> more time from the voters and testers.
> > >>>>>
> > >>>>> If there are other ways for the RM to get the same or better
> code
> > >>>>> coverage on the build.xml files before posting the RC, we can
> discuss
> > >>> those
> > >>>>> options.
> > >>>>>
> > >>>>> I am hopeful we can all agree on these simple principles:
> Strive
> > for
> > >>>>> better code coverage and fewer failed RCs. Royale's main
> purpose is
> > to
> > >>>>> save other people time. Let's do that in creating releases
> too.
> > >>>>>
> > >>>>> One issue that was brought up recently was whether it is a
> good
> > >>>>> decision to have the RM test all of the build platforms we
> support.
> > >>>>> Suppose we add some other build system support or more in the
> future?
> > >>>>> Again, the code coverage principle applies here, but also, I
> would
> > like
> > >>> us
> > >>>>> to retain feature parity, and I also hope for as few RCs and
> votes as
> > >>>>> possible. So instead of having separate
> votes/features/release-dates
> > >>> for
> > >>>>> the Maven artifacts vs the Ant artifacts vs the
> SomeFutureBuildTech
> > >>>>> artifacts, I think we should have one vote and keep them all
> in sync.
> > >>> If
> > >>>>> we do ever get around to monthly or bi-monthly releases, I
> think
> > >>> separate
> > >>>>> build platform releases would be too much work.
> > >>>>>
> > >>>>> But consider this thought I just had today: the RM doesn't
> really
> > >>>>> have to choose to do all 100 commands on a local machine or
> with Ant
> > >>>>> scripts or do the first 40 via CI. The RM can actually pick
> and
> > choose
> > >>>>> commands to run on the CI server. The CI Jenkins jobs are not
> a
> > >>>>> separate/alternative release process, they are just another
> way of
> > >>>>> executing the first 40 steps. Using CI jobs actually requires
> > >>> additional
> > >>>>> command-line cut-and-paste to push commits on the CI server
> and to
> > sign
> > >>> and
> > >>>>> validate binaries locally, but that's the trade-off of not
> having to
> > >>>>> configure your machine to successfully run all of the
> automated tests
> > >>> and
> > >>>>> build systems, and being able to run a command by filling in
> the
> > version
> > >>>>> number and rc number and hitting the "ok" button instead of
> making
> > sure
> > >>> you
> > >>>>> got the whole command typed in correctly.
> > >>>>>
> > >>>>> So, an RM can run the first 25 steps locally, then go the CI
> server
> > >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no
> need to
> > >>> run
> > >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> > >>> successful,
> > >>>>> then the RM has proven code coverage of the build.xml files.
> (If the
> > >>>>> resulting tar.gz and zips are not posted, then the RM should
> verify
> > that
> > >>>>> they match the ones from Maven distribution). I would
> encourage RMs
> > to
> > >>>>> also use the CI jobs that generate the emails to make sure the
> > subject
> > >>> and
> > >>>>> content is correct and contains the usual instructions so we
> have
> > >>>>> consistency. Maybe someday there will be CI jobs to do the
> last 60+
> > >>> steps
> > >>>>> if that helps. We could add a Jenkins job that runs an Ant
> build on
> > RC
> > >>>>> artifacts on dist.a.o as well.
> > >>>>>
> > >>>>> I would like you all to help maintain the list of 100 steps
> and
> > other
> > >>>>> documents related to the release process, and improve the CI
> jobs and
> > >>> Ant
> > >>>>> steps if it helps you be a more efficient RM. I am hopeful
> that now
> > >>> that I
> > >>>>> have hopefully explained our release process better, that we
> can see
> > >>> that
> > >>>>> these 100+ steps just have to be done in some way. The RM can
> figure
> > >>> out
> > >>>>> what way works best for them, but they must get through all of
> them.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Alex
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Rovira
> > >>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243311339&sdata=zhSGBpwSbNGTi7hyxmt%2BEVqr7FB482WmDn8zK6NAicg%3D&reserved=0
> > >>>
> > >>>
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0
> > >
> > >
> > >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
don't understand the problem. Chris and I was able to reach step 7. The big
problem is there with compiler generating classes with lines in different
orders depending on OS (and probably JDK vendor). I think solving that will
make you move from the problematic point. But don't understand that you
have problems in steps 1 to 6.
El jue., 9 abr. 2020 a las 9:21, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> FWIW, I saw Royale_Compiler_Build_Tools_Release_Step_002 work. I'm done
> for tonight. If anyone is bored, they can try to get the
> Royale_Compiler_Build_Tools_Release_Step_002_Sign target to work in
> compiler-build-tools/releasesteps.xml by renaming
> Royale_Compiler_Build_Tools_Release_Step_003_Sign and fixing up the paths.
> Otherwise I will start there tomorrow evening.
>
> -Alex
>
> On 4/8/20, 9:03 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
> >sounds good :)
>
> Hi Carlos,
>
> This sounds like a good plan to me too. Alex and I will do our best to
> get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May,
> and you will be in charge of releasing 0.9.9 in June.
>
> Are we still in agreement on that?
>
> Thanks,
> Yishay
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Thursday, April 2, 2020 6:47 PM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: Royale Releases
>
> Hi Harbs,
>
> sounds good :)
>
> As well, I expect I can do 0.9.9 in June from my local machine with the
> process we already exposed too :)
>
> Thanks
>
> Carlos
>
>
> El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > I spent over an hour with Alex on the Zoom last night trying to
> understand
> > all the different technical points.
> >
> > One point which became clear to me last night is that Ant and Maven
> are
> > distributed differently so there are points of failure that one has
> which
> > the other doesn’t.
> >
> > I also want to stress that Alex is actually a fan of Maven.
> >
> > We all want the Maven release to be easier, but somehow this is being
> > conflated with bashing Ant.
> >
> > As far as I’m concerned, the steps forward are:
> >
> > 1. Yishay should work on releasing 0.9.7.
> > 2. He will hopefully be supported by Alex, Chris and Carlos to make
> it as
> > smooth as possible.
> > 3. When he’s done, I plan on sitting down with him to discuss his
> > experience.
> > 4. I plan on working on releasing 0.9.8 sometime in May.
> > 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences
> as well
> > as my own to try and understand as much about the process as I can
> (Ant,
> > Maven and NPM too).
> > 6. I hope to work with anyone who wants to help to improve the
> process as
> > much as I can.
> >
> > Sounds OK?
> >
> > Harbs
> >
> > > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <
> christofer.dutz@c-ware.de>
> > wrote:
> > >
> > > Hi folks,
> > >
> > > I would say we have coverage for both maven ant equally as we're
> > building the same code.
> > >
> > > However we are missing the important assertions. It's not that the
> Ant
> > build is running some tests Maven isn't.
> > > It's just that the settings for Ant seem to be different than for
> Maven
> > and the Ant ones happen to work.
> > >
> > > Ideally there would be real tests that test the output of both to
> see if
> > it works in both cases.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> > >
> > > Adding more coverage for Maven is good.
> > >
> > > Removing coverage for Ant is not.
> > >
> > > Do you agree?
> > >
> > >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <
> carlosrovira@apache.org>
> > wrote:
> > >>
> > >> Hi Harbs,
> > >>
> > >> I think what we're trying to say is that until now we released
> with
> > Maven
> > >> and Ant, and that was hiding a flaw in Maven (SVG example). So
> that
> > means
> > >> what we were trying to cover was not covered clearly, so the
> premise is
> > not
> > >> right.
> > >>
> > >>
> > >>
> > >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> > escribió:
> > >>
> > >>> No one is arguing that we shouldn’t add more tests.
> > >>>
> > >>> Please let’s not make it seem like there’s a disagreement about
> that.
> > >>>
> > >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <
> carlosrovira@apache.org>
> > >>> wrote:
> > >>>>
> > >>>> Hi Alex,
> > >>>>
> > >>>> first, many thanks for the detailed email. I'll comment on this
> later
> > as
> > >>> I
> > >>>> have more time.
> > >>>>
> > >>>> For now, to add up a recent example on what Chris commented: If
> you
> > all
> > >>>> remember a week ago I was trying to use SVG Images in a blog
> example
> > that
> > >>>> was published 2 days ago. Nobody tried SVG Images before
> building with
> > >>>> maven, I know that since maven was not properly configured and
> using
> > that
> > >>>> component from Maven was failing with an RTE. Probably we have
> more
> > >>> things
> > >>>> not working the same way when build from Maven and Ant, and
> that's
> > >>>> something that will need people using that code paths in test
> > >>> applications
> > >>>> (or in their own apps) to see if things works properly.
> > >>>>
> > >>>> I was recently introduced to "examples-integrationtest" by
> Chris,
> > that I
> > >>>> plan to use soon as I can. I think is a great idea, since you
> get a
> > >>> Firefox
> > >>>> running test interface of the real use of some concrete royale
> code. I
> > >>>> think passed until now unnoticed by all of us, and seems a
> powerful
> > tool.
> > >>>> There's already an example about FlexStore with some basic
> assertions.
> > >>>>
> > >>>> Again, thanks, and will comment on the rest later
> > >>>>
> > >>>> Carlos
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > >>> christofer.dutz@c-ware.de>)
> > >>>> escribió:
> > >>>>
> > >>>>> Hi Alex,
> > >>>>>
> > >>>>> just a point you are bringing up: "Code coverage".
> > >>>>>
> > >>>>> I strongly dislike the idea of "asjs" effectively being the
> test for
> > the
> > >>>>> compiler. The reasoning behind this is: yes you do get more
> code
> > >>> covered,
> > >>>>> but only the happy-path (ideally) and even if things go wrong,
> the
> > end
> > >>>>> results aren't tested. Did add a module to asjs years ago
> > >>>>> ("examples-integrationtest") that deployed the examples in a
> tomcat
> > >>> server
> > >>>>> then opens a Firefox browser and clicks through 2 of the
> examples (I
> > >>> added
> > >>>>> two dummy tests as an example, but seems no one touched this
> after
> > me).
> > >>> I
> > >>>>> did this because I remember us working on asjs for weeks
> without
> > anyone
> > >>>>> noticing the compiler wasn't producing runnable code ... same
> with
> > the
> > >>>>> little unit-tests that are still run for every example, that
> simply
> > >>> check
> > >>>>> if an output is generated, because we had a prolonged period
> of time
> > >>> where
> > >>>>> we were all working on different parts, but for quite some
> time the
> > >>>>> application compilation just didn't output anything and no one
> > noticed.
> > >>>>>
> > >>>>> So coverage is nothing without assertions (my opinion) ... ok
> ...
> > it's
> > >>>>> slightly better than no coverage, but not much, in my opinion.
> > >>>>>
> > >>>>> I think in parallel to this release discussions I have seen
> numerous
> > >>>>> threads about someone doing something that broke something for
> > someone
> > >>>>> else. This could be addressed by increasing coverage by
> providing
> > >>> explicit
> > >>>>> tests.
> > >>>>>
> > >>>>> Coming back to the releases:
> > >>>>> I have no objections, if you do a "release" locally and
> automate the
> > >>>>> validation on the CI server (Which effectively would be your
> proposal
> > >>> to do
> > >>>>> the first 12 steps on local hardware and the 13th on the CI
> server).
> > I
> > >>> even
> > >>>>> think that's a good idea ... There could be one step for
> building a
> > >>> release
> > >>>>> from a given "git tag" for every build system and generic
> means to
> > >>> compare
> > >>>>> tar.gz and zips produced by any build system with that of
> another
> > >>> (ideally
> > >>>>> with better output than just a plain "true/false"). This would
> even
> > >>> help to
> > >>>>> iron out the last potentially existing bumps out of the Maven
> > >>> distribution.
> > >>>>>
> > >>>>> Chris
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui"
> <ah...@adobe.com.INVALID>:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> This is my attempt to explain what goes into a release in
> hopes that
> > >>>>> we can understand and agree on what our release process is. It
> > became
> > >>>>> apparent in my reading of the wiki page with the new Maven
> steps and
> > in
> > >>>>> talking with Harbs today that there are still many
> misunderstandings
> > >>> about
> > >>>>> what we do to create a release. I don't generally like writing
> > >>>>> instructions in English because it is easy to be ambiguous.
> All of
> > the
> > >>>>> steps that we use to create releases had been captured in Ant
> scripts
> > >>> in a
> > >>>>> much more explicit way, IMO, but I took the time to write them
> down
> > in
> > >>>>> English here:
> > >>>>>
> > >>>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=LEnt8RHhcRGzOkRz4JOCLeJrfBFNnD3Y6th4M51XUGE%3D&reserved=0
> > >>>>>
> > >>>>> I did this quickly by scanning the CI steps, the new Maven
> steps and
> > >>>>> the Ant scripts used in prior releases so there could
> certainly be
> > >>> mistakes
> > >>>>> and missed steps. If I did my math right, the RM for 0.9.7
> will
> > have to
> > >>>>> complete over 100 tasks (essentially, typing a command-line 100
> > times).
> > >>>>> Future RMs, when we don't have to release build-tools, will
> have
> > about
> > >>> 92
> > >>>>> steps. And I did not include voter verification checks the RM
> should
> > >>> run
> > >>>>> before opening a vote (verifying that the artifacts download
> and
> > match
> > >>>>> their checksums, etc). As an RM, I run a bunch of tests on
> the RC
> > >>> before
> > >>>>> sending out the vote. Maybe we should add those to the task
> list.
> > >>>>>
> > >>>>> I think there has been confusion about the use of Ant in the
> release
> > >>>>> process. Because I was the RM for the first set of
> FlexJS/Royale
> > >>> releases,
> > >>>>> and I'm a lazy person who hates typing at the command line, I
> created
> > >>> Ant
> > >>>>> scripts to execute these 100 steps. But I agree that it is
> not a
> > >>>>> requirement that other RMs must use the Ant scripts for these
> > >>> commands. If
> > >>>>> you are the RM and like typing, go ahead.
> > >>>>>
> > >>>>> Then we found out that other people couldn't get through this
> task
> > >>>>> list. I think the 3 people who tried were having trouble with
> Maven
> > >>>>> uploads and downloads. So what I did was put the first 40
> steps or
> > so
> > >>> into
> > >>>>> Jenkins jobs. And by doing that, Piotr was able to produce
> our last
> > >>>>> release. And that also saves on manually typing commands. But
> > again,
> > >>>>> going forward, the RM gets to choose how they want to execute
> these
> > >>> steps.
> > >>>>>
> > >>>>> If you scan the set of steps, you'll see that "ant" is only
> in there
> > >>>>> once. I believe the recent threads have been about this single
> > command
> > >>> out
> > >>>>> of the 100+ commands. This is why this has been so
> frustrating to
> > me.
> > >>> I
> > >>>>> believe there is a solid technical reason for that one
> command: it
> > >>> proves
> > >>>>> that the build.xml files in the source packages can build the
> .tar.gz
> > >>> that
> > >>>>> are useful to NPM and IDE users who use Ant and want to test a
> > change.
> > >>>>>
> > >>>>> I think of it as code-coverage. If we had code-coverage
> tools, we
> > >>>>> would ask that the RM complete as much of the automated
> code-coverage
> > >>>>> testing as possible before posting the release for a vote.
> That one
> > >>>>> command increases our code coverage by running the build.xml
> files.
> > We
> > >>>>> should be always working to increase automated code coverage
> in the
> > RC.
> > >>>>> Certainly for me as RM, I will gladly watch TV as the
> automated tests
> > >>> run
> > >>>>> because a failed RC means going back through many of the first
> 25
> > >>> commands
> > >>>>> again and wastes other people's time. Each RC is more emails
> to read
> > >>> and
> > >>>>> more time from the voters and testers.
> > >>>>>
> > >>>>> If there are other ways for the RM to get the same or better
> code
> > >>>>> coverage on the build.xml files before posting the RC, we can
> discuss
> > >>> those
> > >>>>> options.
> > >>>>>
> > >>>>> I am hopeful we can all agree on these simple principles:
> Strive
> > for
> > >>>>> better code coverage and fewer failed RCs. Royale's main
> purpose is
> > to
> > >>>>> save other people time. Let's do that in creating releases
> too.
> > >>>>>
> > >>>>> One issue that was brought up recently was whether it is a
> good
> > >>>>> decision to have the RM test all of the build platforms we
> support.
> > >>>>> Suppose we add some other build system support or more in the
> future?
> > >>>>> Again, the code coverage principle applies here, but also, I
> would
> > like
> > >>> us
> > >>>>> to retain feature parity, and I also hope for as few RCs and
> votes as
> > >>>>> possible. So instead of having separate
> votes/features/release-dates
> > >>> for
> > >>>>> the Maven artifacts vs the Ant artifacts vs the
> SomeFutureBuildTech
> > >>>>> artifacts, I think we should have one vote and keep them all
> in sync.
> > >>> If
> > >>>>> we do ever get around to monthly or bi-monthly releases, I
> think
> > >>> separate
> > >>>>> build platform releases would be too much work.
> > >>>>>
> > >>>>> But consider this thought I just had today: the RM doesn't
> really
> > >>>>> have to choose to do all 100 commands on a local machine or
> with Ant
> > >>>>> scripts or do the first 40 via CI. The RM can actually pick
> and
> > choose
> > >>>>> commands to run on the CI server. The CI Jenkins jobs are not
> a
> > >>>>> separate/alternative release process, they are just another
> way of
> > >>>>> executing the first 40 steps. Using CI jobs actually requires
> > >>> additional
> > >>>>> command-line cut-and-paste to push commits on the CI server
> and to
> > sign
> > >>> and
> > >>>>> validate binaries locally, but that's the trade-off of not
> having to
> > >>>>> configure your machine to successfully run all of the
> automated tests
> > >>> and
> > >>>>> build systems, and being able to run a command by filling in
> the
> > version
> > >>>>> number and rc number and hitting the "ok" button instead of
> making
> > sure
> > >>> you
> > >>>>> got the whole command typed in correctly.
> > >>>>>
> > >>>>> So, an RM can run the first 25 steps locally, then go the CI
> server
> > >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no
> need to
> > >>> run
> > >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> > >>> successful,
> > >>>>> then the RM has proven code coverage of the build.xml files.
> (If the
> > >>>>> resulting tar.gz and zips are not posted, then the RM should
> verify
> > that
> > >>>>> they match the ones from Maven distribution). I would
> encourage RMs
> > to
> > >>>>> also use the CI jobs that generate the emails to make sure the
> > subject
> > >>> and
> > >>>>> content is correct and contains the usual instructions so we
> have
> > >>>>> consistency. Maybe someday there will be CI jobs to do the
> last 60+
> > >>> steps
> > >>>>> if that helps. We could add a Jenkins job that runs an Ant
> build on
> > RC
> > >>>>> artifacts on dist.a.o as well.
> > >>>>>
> > >>>>> I would like you all to help maintain the list of 100 steps
> and
> > other
> > >>>>> documents related to the release process, and improve the CI
> jobs and
> > >>> Ant
> > >>>>> steps if it helps you be a more efficient RM. I am hopeful
> that now
> > >>> that I
> > >>>>> have hopefully explained our release process better, that we
> can see
> > >>> that
> > >>>>> these 100+ steps just have to be done in some way. The RM can
> figure
> > >>> out
> > >>>>> what way works best for them, but they must get through all of
> them.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Alex
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Rovira
> > >>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0
> > >>>
> > >>>
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0
> > >
> > >
> > >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I saw Royale_Compiler_Build_Tools_Release_Step_002 work. I'm done for tonight. If anyone is bored, they can try to get the Royale_Compiler_Build_Tools_Release_Step_002_Sign target to work in compiler-build-tools/releasesteps.xml by renaming Royale_Compiler_Build_Tools_Release_Step_003_Sign and fixing up the paths. Otherwise I will start there tomorrow evening.
-Alex
On 4/8/20, 9:03 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>sounds good :)
Hi Carlos,
This sounds like a good plan to me too. Alex and I will do our best to get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May, and you will be in charge of releasing 0.9.9 in June.
Are we still in agreement on that?
Thanks,
Yishay
From: Carlos Rovira<ma...@apache.org>
Sent: Thursday, April 2, 2020 6:47 PM
To: Apache Royale Development<ma...@royale.apache.org>
Subject: Re: Royale Releases
Hi Harbs,
sounds good :)
As well, I expect I can do 0.9.9 in June from my local machine with the
process we already exposed too :)
Thanks
Carlos
El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>) escribió:
> I spent over an hour with Alex on the Zoom last night trying to understand
> all the different technical points.
>
> One point which became clear to me last night is that Ant and Maven are
> distributed differently so there are points of failure that one has which
> the other doesn’t.
>
> I also want to stress that Alex is actually a fan of Maven.
>
> We all want the Maven release to be easier, but somehow this is being
> conflated with bashing Ant.
>
> As far as I’m concerned, the steps forward are:
>
> 1. Yishay should work on releasing 0.9.7.
> 2. He will hopefully be supported by Alex, Chris and Carlos to make it as
> smooth as possible.
> 3. When he’s done, I plan on sitting down with him to discuss his
> experience.
> 4. I plan on working on releasing 0.9.8 sometime in May.
> 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences as well
> as my own to try and understand as much about the process as I can (Ant,
> Maven and NPM too).
> 6. I hope to work with anyone who wants to help to improve the process as
> much as I can.
>
> Sounds OK?
>
> Harbs
>
> > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <ch...@c-ware.de>
> wrote:
> >
> > Hi folks,
> >
> > I would say we have coverage for both maven ant equally as we're
> building the same code.
> >
> > However we are missing the important assertions. It's not that the Ant
> build is running some tests Maven isn't.
> > It's just that the settings for Ant seem to be different than for Maven
> and the Ant ones happen to work.
> >
> > Ideally there would be real tests that test the output of both to see if
> it works in both cases.
> >
> > Chris
> >
> >
> >
> > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> >
> > Adding more coverage for Maven is good.
> >
> > Removing coverage for Ant is not.
> >
> > Do you agree?
> >
> >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> I think what we're trying to say is that until now we released with
> Maven
> >> and Ant, and that was hiding a flaw in Maven (SVG example). So that
> means
> >> what we were trying to cover was not covered clearly, so the premise is
> not
> >> right.
> >>
> >>
> >>
> >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> escribió:
> >>
> >>> No one is arguing that we shouldn’t add more tests.
> >>>
> >>> Please let’s not make it seem like there’s a disagreement about that.
> >>>
> >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi Alex,
> >>>>
> >>>> first, many thanks for the detailed email. I'll comment on this later
> as
> >>> I
> >>>> have more time.
> >>>>
> >>>> For now, to add up a recent example on what Chris commented: If you
> all
> >>>> remember a week ago I was trying to use SVG Images in a blog example
> that
> >>>> was published 2 days ago. Nobody tried SVG Images before building with
> >>>> maven, I know that since maven was not properly configured and using
> that
> >>>> component from Maven was failing with an RTE. Probably we have more
> >>> things
> >>>> not working the same way when build from Maven and Ant, and that's
> >>>> something that will need people using that code paths in test
> >>> applications
> >>>> (or in their own apps) to see if things works properly.
> >>>>
> >>>> I was recently introduced to "examples-integrationtest" by Chris,
> that I
> >>>> plan to use soon as I can. I think is a great idea, since you get a
> >>> Firefox
> >>>> running test interface of the real use of some concrete royale code. I
> >>>> think passed until now unnoticed by all of us, and seems a powerful
> tool.
> >>>> There's already an example about FlexStore with some basic assertions.
> >>>>
> >>>> Again, thanks, and will comment on the rest later
> >>>>
> >>>> Carlos
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >>> christofer.dutz@c-ware.de>)
> >>>> escribió:
> >>>>
> >>>>> Hi Alex,
> >>>>>
> >>>>> just a point you are bringing up: "Code coverage".
> >>>>>
> >>>>> I strongly dislike the idea of "asjs" effectively being the test for
> the
> >>>>> compiler. The reasoning behind this is: yes you do get more code
> >>> covered,
> >>>>> but only the happy-path (ideally) and even if things go wrong, the
> end
> >>>>> results aren't tested. Did add a module to asjs years ago
> >>>>> ("examples-integrationtest") that deployed the examples in a tomcat
> >>> server
> >>>>> then opens a Firefox browser and clicks through 2 of the examples (I
> >>> added
> >>>>> two dummy tests as an example, but seems no one touched this after
> me).
> >>> I
> >>>>> did this because I remember us working on asjs for weeks without
> anyone
> >>>>> noticing the compiler wasn't producing runnable code ... same with
> the
> >>>>> little unit-tests that are still run for every example, that simply
> >>> check
> >>>>> if an output is generated, because we had a prolonged period of time
> >>> where
> >>>>> we were all working on different parts, but for quite some time the
> >>>>> application compilation just didn't output anything and no one
> noticed.
> >>>>>
> >>>>> So coverage is nothing without assertions (my opinion) ... ok ...
> it's
> >>>>> slightly better than no coverage, but not much, in my opinion.
> >>>>>
> >>>>> I think in parallel to this release discussions I have seen numerous
> >>>>> threads about someone doing something that broke something for
> someone
> >>>>> else. This could be addressed by increasing coverage by providing
> >>> explicit
> >>>>> tests.
> >>>>>
> >>>>> Coming back to the releases:
> >>>>> I have no objections, if you do a "release" locally and automate the
> >>>>> validation on the CI server (Which effectively would be your proposal
> >>> to do
> >>>>> the first 12 steps on local hardware and the 13th on the CI server).
> I
> >>> even
> >>>>> think that's a good idea ... There could be one step for building a
> >>> release
> >>>>> from a given "git tag" for every build system and generic means to
> >>> compare
> >>>>> tar.gz and zips produced by any build system with that of another
> >>> (ideally
> >>>>> with better output than just a plain "true/false"). This would even
> >>> help to
> >>>>> iron out the last potentially existing bumps out of the Maven
> >>> distribution.
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>>
> >>>>>
> >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> This is my attempt to explain what goes into a release in hopes that
> >>>>> we can understand and agree on what our release process is. It
> became
> >>>>> apparent in my reading of the wiki page with the new Maven steps and
> in
> >>>>> talking with Harbs today that there are still many misunderstandings
> >>> about
> >>>>> what we do to create a release. I don't generally like writing
> >>>>> instructions in English because it is easy to be ambiguous. All of
> the
> >>>>> steps that we use to create releases had been captured in Ant scripts
> >>> in a
> >>>>> much more explicit way, IMO, but I took the time to write them down
> in
> >>>>> English here:
> >>>>>
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=LEnt8RHhcRGzOkRz4JOCLeJrfBFNnD3Y6th4M51XUGE%3D&reserved=0
> >>>>>
> >>>>> I did this quickly by scanning the CI steps, the new Maven steps and
> >>>>> the Ant scripts used in prior releases so there could certainly be
> >>> mistakes
> >>>>> and missed steps. If I did my math right, the RM for 0.9.7 will
> have to
> >>>>> complete over 100 tasks (essentially, typing a command-line 100
> times).
> >>>>> Future RMs, when we don't have to release build-tools, will have
> about
> >>> 92
> >>>>> steps. And I did not include voter verification checks the RM should
> >>> run
> >>>>> before opening a vote (verifying that the artifacts download and
> match
> >>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
> >>> before
> >>>>> sending out the vote. Maybe we should add those to the task list.
> >>>>>
> >>>>> I think there has been confusion about the use of Ant in the release
> >>>>> process. Because I was the RM for the first set of FlexJS/Royale
> >>> releases,
> >>>>> and I'm a lazy person who hates typing at the command line, I created
> >>> Ant
> >>>>> scripts to execute these 100 steps. But I agree that it is not a
> >>>>> requirement that other RMs must use the Ant scripts for these
> >>> commands. If
> >>>>> you are the RM and like typing, go ahead.
> >>>>>
> >>>>> Then we found out that other people couldn't get through this task
> >>>>> list. I think the 3 people who tried were having trouble with Maven
> >>>>> uploads and downloads. So what I did was put the first 40 steps or
> so
> >>> into
> >>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >>>>> release. And that also saves on manually typing commands. But
> again,
> >>>>> going forward, the RM gets to choose how they want to execute these
> >>> steps.
> >>>>>
> >>>>> If you scan the set of steps, you'll see that "ant" is only in there
> >>>>> once. I believe the recent threads have been about this single
> command
> >>> out
> >>>>> of the 100+ commands. This is why this has been so frustrating to
> me.
> >>> I
> >>>>> believe there is a solid technical reason for that one command: it
> >>> proves
> >>>>> that the build.xml files in the source packages can build the .tar.gz
> >>> that
> >>>>> are useful to NPM and IDE users who use Ant and want to test a
> change.
> >>>>>
> >>>>> I think of it as code-coverage. If we had code-coverage tools, we
> >>>>> would ask that the RM complete as much of the automated code-coverage
> >>>>> testing as possible before posting the release for a vote. That one
> >>>>> command increases our code coverage by running the build.xml files.
> We
> >>>>> should be always working to increase automated code coverage in the
> RC.
> >>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
> >>> run
> >>>>> because a failed RC means going back through many of the first 25
> >>> commands
> >>>>> again and wastes other people's time. Each RC is more emails to read
> >>> and
> >>>>> more time from the voters and testers.
> >>>>>
> >>>>> If there are other ways for the RM to get the same or better code
> >>>>> coverage on the build.xml files before posting the RC, we can discuss
> >>> those
> >>>>> options.
> >>>>>
> >>>>> I am hopeful we can all agree on these simple principles: Strive
> for
> >>>>> better code coverage and fewer failed RCs. Royale's main purpose is
> to
> >>>>> save other people time. Let's do that in creating releases too.
> >>>>>
> >>>>> One issue that was brought up recently was whether it is a good
> >>>>> decision to have the RM test all of the build platforms we support.
> >>>>> Suppose we add some other build system support or more in the future?
> >>>>> Again, the code coverage principle applies here, but also, I would
> like
> >>> us
> >>>>> to retain feature parity, and I also hope for as few RCs and votes as
> >>>>> possible. So instead of having separate votes/features/release-dates
> >>> for
> >>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >>>>> artifacts, I think we should have one vote and keep them all in sync.
> >>> If
> >>>>> we do ever get around to monthly or bi-monthly releases, I think
> >>> separate
> >>>>> build platform releases would be too much work.
> >>>>>
> >>>>> But consider this thought I just had today: the RM doesn't really
> >>>>> have to choose to do all 100 commands on a local machine or with Ant
> >>>>> scripts or do the first 40 via CI. The RM can actually pick and
> choose
> >>>>> commands to run on the CI server. The CI Jenkins jobs are not a
> >>>>> separate/alternative release process, they are just another way of
> >>>>> executing the first 40 steps. Using CI jobs actually requires
> >>> additional
> >>>>> command-line cut-and-paste to push commits on the CI server and to
> sign
> >>> and
> >>>>> validate binaries locally, but that's the trade-off of not having to
> >>>>> configure your machine to successfully run all of the automated tests
> >>> and
> >>>>> build systems, and being able to run a command by filling in the
> version
> >>>>> number and rc number and hitting the "ok" button instead of making
> sure
> >>> you
> >>>>> got the whole command typed in correctly.
> >>>>>
> >>>>> So, an RM can run the first 25 steps locally, then go the CI server
> >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
> >>> run
> >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> >>> successful,
> >>>>> then the RM has proven code coverage of the build.xml files. (If the
> >>>>> resulting tar.gz and zips are not posted, then the RM should verify
> that
> >>>>> they match the ones from Maven distribution). I would encourage RMs
> to
> >>>>> also use the CI jobs that generate the emails to make sure the
> subject
> >>> and
> >>>>> content is correct and contains the usual instructions so we have
> >>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
> >>> steps
> >>>>> if that helps. We could add a Jenkins job that runs an Ant build on
> RC
> >>>>> artifacts on dist.a.o as well.
> >>>>>
> >>>>> I would like you all to help maintain the list of 100 steps and
> other
> >>>>> documents related to the release process, and improve the CI jobs and
> >>> Ant
> >>>>> steps if it helps you be a more efficient RM. I am hopeful that now
> >>> that I
> >>>>> have hopefully explained our release process better, that we can see
> >>> that
> >>>>> these 100+ steps just have to be done in some way. The RM can figure
> >>> out
> >>>>> what way works best for them, but they must get through all of them.
> >>>>>
> >>>>> Thanks,
> >>>>> -Alex
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0
> >>>
> >>>
> >>
> >> --
> >> Carlos Rovira
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0
> >
> >
> >
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Yishay,
if you both think that can be done, it's ok for me.
I was proposing changing order since I know I can have a release in few
time and what delays me more is the voting waiting times, so it make sense
to do something we already have and in parallel work in something that
still requires work.
So in the end we have both things done in the proposed period.
So if you think you can get it in that time, it's ok for me.
If you think you'll have some problem on the way don't hesitate in say it.
People is waiting for us.
Thanks!
Carlos
El jue., 9 abr. 2020 a las 6:03, Yishay Weiss (<yi...@hotmail.com>)
escribió:
> >sounds good :)
>
> Hi Carlos,
>
> This sounds like a good plan to me too. Alex and I will do our best to get
> 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May, and
> you will be in charge of releasing 0.9.9 in June.
>
> Are we still in agreement on that?
>
> Thanks,
> Yishay
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Thursday, April 2, 2020 6:47 PM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: Royale Releases
>
> Hi Harbs,
>
> sounds good :)
>
> As well, I expect I can do 0.9.9 in June from my local machine with the
> process we already exposed too :)
>
> Thanks
>
> Carlos
>
>
> El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > I spent over an hour with Alex on the Zoom last night trying to
> understand
> > all the different technical points.
> >
> > One point which became clear to me last night is that Ant and Maven are
> > distributed differently so there are points of failure that one has which
> > the other doesn’t.
> >
> > I also want to stress that Alex is actually a fan of Maven.
> >
> > We all want the Maven release to be easier, but somehow this is being
> > conflated with bashing Ant.
> >
> > As far as I’m concerned, the steps forward are:
> >
> > 1. Yishay should work on releasing 0.9.7.
> > 2. He will hopefully be supported by Alex, Chris and Carlos to make it as
> > smooth as possible.
> > 3. When he’s done, I plan on sitting down with him to discuss his
> > experience.
> > 4. I plan on working on releasing 0.9.8 sometime in May.
> > 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences as
> well
> > as my own to try and understand as much about the process as I can (Ant,
> > Maven and NPM too).
> > 6. I hope to work with anyone who wants to help to improve the process as
> > much as I can.
> >
> > Sounds OK?
> >
> > Harbs
> >
> > > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> > wrote:
> > >
> > > Hi folks,
> > >
> > > I would say we have coverage for both maven ant equally as we're
> > building the same code.
> > >
> > > However we are missing the important assertions. It's not that the Ant
> > build is running some tests Maven isn't.
> > > It's just that the settings for Ant seem to be different than for Maven
> > and the Ant ones happen to work.
> > >
> > > Ideally there would be real tests that test the output of both to see
> if
> > it works in both cases.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> > >
> > > Adding more coverage for Maven is good.
> > >
> > > Removing coverage for Ant is not.
> > >
> > > Do you agree?
> > >
> > >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org>
> > wrote:
> > >>
> > >> Hi Harbs,
> > >>
> > >> I think what we're trying to say is that until now we released with
> > Maven
> > >> and Ant, and that was hiding a flaw in Maven (SVG example). So that
> > means
> > >> what we were trying to cover was not covered clearly, so the premise
> is
> > not
> > >> right.
> > >>
> > >>
> > >>
> > >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> > escribió:
> > >>
> > >>> No one is arguing that we shouldn’t add more tests.
> > >>>
> > >>> Please let’s not make it seem like there’s a disagreement about that.
> > >>>
> > >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <carlosrovira@apache.org
> >
> > >>> wrote:
> > >>>>
> > >>>> Hi Alex,
> > >>>>
> > >>>> first, many thanks for the detailed email. I'll comment on this
> later
> > as
> > >>> I
> > >>>> have more time.
> > >>>>
> > >>>> For now, to add up a recent example on what Chris commented: If you
> > all
> > >>>> remember a week ago I was trying to use SVG Images in a blog example
> > that
> > >>>> was published 2 days ago. Nobody tried SVG Images before building
> with
> > >>>> maven, I know that since maven was not properly configured and using
> > that
> > >>>> component from Maven was failing with an RTE. Probably we have more
> > >>> things
> > >>>> not working the same way when build from Maven and Ant, and that's
> > >>>> something that will need people using that code paths in test
> > >>> applications
> > >>>> (or in their own apps) to see if things works properly.
> > >>>>
> > >>>> I was recently introduced to "examples-integrationtest" by Chris,
> > that I
> > >>>> plan to use soon as I can. I think is a great idea, since you get a
> > >>> Firefox
> > >>>> running test interface of the real use of some concrete royale
> code. I
> > >>>> think passed until now unnoticed by all of us, and seems a powerful
> > tool.
> > >>>> There's already an example about FlexStore with some basic
> assertions.
> > >>>>
> > >>>> Again, thanks, and will comment on the rest later
> > >>>>
> > >>>> Carlos
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > >>> christofer.dutz@c-ware.de>)
> > >>>> escribió:
> > >>>>
> > >>>>> Hi Alex,
> > >>>>>
> > >>>>> just a point you are bringing up: "Code coverage".
> > >>>>>
> > >>>>> I strongly dislike the idea of "asjs" effectively being the test
> for
> > the
> > >>>>> compiler. The reasoning behind this is: yes you do get more code
> > >>> covered,
> > >>>>> but only the happy-path (ideally) and even if things go wrong, the
> > end
> > >>>>> results aren't tested. Did add a module to asjs years ago
> > >>>>> ("examples-integrationtest") that deployed the examples in a tomcat
> > >>> server
> > >>>>> then opens a Firefox browser and clicks through 2 of the examples
> (I
> > >>> added
> > >>>>> two dummy tests as an example, but seems no one touched this after
> > me).
> > >>> I
> > >>>>> did this because I remember us working on asjs for weeks without
> > anyone
> > >>>>> noticing the compiler wasn't producing runnable code ... same with
> > the
> > >>>>> little unit-tests that are still run for every example, that simply
> > >>> check
> > >>>>> if an output is generated, because we had a prolonged period of
> time
> > >>> where
> > >>>>> we were all working on different parts, but for quite some time the
> > >>>>> application compilation just didn't output anything and no one
> > noticed.
> > >>>>>
> > >>>>> So coverage is nothing without assertions (my opinion) ... ok ...
> > it's
> > >>>>> slightly better than no coverage, but not much, in my opinion.
> > >>>>>
> > >>>>> I think in parallel to this release discussions I have seen
> numerous
> > >>>>> threads about someone doing something that broke something for
> > someone
> > >>>>> else. This could be addressed by increasing coverage by providing
> > >>> explicit
> > >>>>> tests.
> > >>>>>
> > >>>>> Coming back to the releases:
> > >>>>> I have no objections, if you do a "release" locally and automate
> the
> > >>>>> validation on the CI server (Which effectively would be your
> proposal
> > >>> to do
> > >>>>> the first 12 steps on local hardware and the 13th on the CI
> server).
> > I
> > >>> even
> > >>>>> think that's a good idea ... There could be one step for building a
> > >>> release
> > >>>>> from a given "git tag" for every build system and generic means to
> > >>> compare
> > >>>>> tar.gz and zips produced by any build system with that of another
> > >>> (ideally
> > >>>>> with better output than just a plain "true/false"). This would even
> > >>> help to
> > >>>>> iron out the last potentially existing bumps out of the Maven
> > >>> distribution.
> > >>>>>
> > >>>>> Chris
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <aharui@adobe.com.INVALID
> >:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> This is my attempt to explain what goes into a release in hopes
> that
> > >>>>> we can understand and agree on what our release process is. It
> > became
> > >>>>> apparent in my reading of the wiki page with the new Maven steps
> and
> > in
> > >>>>> talking with Harbs today that there are still many
> misunderstandings
> > >>> about
> > >>>>> what we do to create a release. I don't generally like writing
> > >>>>> instructions in English because it is easy to be ambiguous. All of
> > the
> > >>>>> steps that we use to create releases had been captured in Ant
> scripts
> > >>> in a
> > >>>>> much more explicit way, IMO, but I took the time to write them down
> > in
> > >>>>> English here:
> > >>>>>
> > >>>
> > https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
> > >>>>>
> > >>>>> I did this quickly by scanning the CI steps, the new Maven steps
> and
> > >>>>> the Ant scripts used in prior releases so there could certainly be
> > >>> mistakes
> > >>>>> and missed steps. If I did my math right, the RM for 0.9.7 will
> > have to
> > >>>>> complete over 100 tasks (essentially, typing a command-line 100
> > times).
> > >>>>> Future RMs, when we don't have to release build-tools, will have
> > about
> > >>> 92
> > >>>>> steps. And I did not include voter verification checks the RM
> should
> > >>> run
> > >>>>> before opening a vote (verifying that the artifacts download and
> > match
> > >>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
> > >>> before
> > >>>>> sending out the vote. Maybe we should add those to the task list.
> > >>>>>
> > >>>>> I think there has been confusion about the use of Ant in the
> release
> > >>>>> process. Because I was the RM for the first set of FlexJS/Royale
> > >>> releases,
> > >>>>> and I'm a lazy person who hates typing at the command line, I
> created
> > >>> Ant
> > >>>>> scripts to execute these 100 steps. But I agree that it is not a
> > >>>>> requirement that other RMs must use the Ant scripts for these
> > >>> commands. If
> > >>>>> you are the RM and like typing, go ahead.
> > >>>>>
> > >>>>> Then we found out that other people couldn't get through this task
> > >>>>> list. I think the 3 people who tried were having trouble with
> Maven
> > >>>>> uploads and downloads. So what I did was put the first 40 steps or
> > so
> > >>> into
> > >>>>> Jenkins jobs. And by doing that, Piotr was able to produce our
> last
> > >>>>> release. And that also saves on manually typing commands. But
> > again,
> > >>>>> going forward, the RM gets to choose how they want to execute these
> > >>> steps.
> > >>>>>
> > >>>>> If you scan the set of steps, you'll see that "ant" is only in
> there
> > >>>>> once. I believe the recent threads have been about this single
> > command
> > >>> out
> > >>>>> of the 100+ commands. This is why this has been so frustrating to
> > me.
> > >>> I
> > >>>>> believe there is a solid technical reason for that one command: it
> > >>> proves
> > >>>>> that the build.xml files in the source packages can build the
> .tar.gz
> > >>> that
> > >>>>> are useful to NPM and IDE users who use Ant and want to test a
> > change.
> > >>>>>
> > >>>>> I think of it as code-coverage. If we had code-coverage tools, we
> > >>>>> would ask that the RM complete as much of the automated
> code-coverage
> > >>>>> testing as possible before posting the release for a vote. That
> one
> > >>>>> command increases our code coverage by running the build.xml files.
> > We
> > >>>>> should be always working to increase automated code coverage in the
> > RC.
> > >>>>> Certainly for me as RM, I will gladly watch TV as the automated
> tests
> > >>> run
> > >>>>> because a failed RC means going back through many of the first 25
> > >>> commands
> > >>>>> again and wastes other people's time. Each RC is more emails to
> read
> > >>> and
> > >>>>> more time from the voters and testers.
> > >>>>>
> > >>>>> If there are other ways for the RM to get the same or better code
> > >>>>> coverage on the build.xml files before posting the RC, we can
> discuss
> > >>> those
> > >>>>> options.
> > >>>>>
> > >>>>> I am hopeful we can all agree on these simple principles: Strive
> > for
> > >>>>> better code coverage and fewer failed RCs. Royale's main purpose
> is
> > to
> > >>>>> save other people time. Let's do that in creating releases too.
> > >>>>>
> > >>>>> One issue that was brought up recently was whether it is a good
> > >>>>> decision to have the RM test all of the build platforms we support.
> > >>>>> Suppose we add some other build system support or more in the
> future?
> > >>>>> Again, the code coverage principle applies here, but also, I would
> > like
> > >>> us
> > >>>>> to retain feature parity, and I also hope for as few RCs and votes
> as
> > >>>>> possible. So instead of having separate
> votes/features/release-dates
> > >>> for
> > >>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> > >>>>> artifacts, I think we should have one vote and keep them all in
> sync.
> > >>> If
> > >>>>> we do ever get around to monthly or bi-monthly releases, I think
> > >>> separate
> > >>>>> build platform releases would be too much work.
> > >>>>>
> > >>>>> But consider this thought I just had today: the RM doesn't really
> > >>>>> have to choose to do all 100 commands on a local machine or with
> Ant
> > >>>>> scripts or do the first 40 via CI. The RM can actually pick and
> > choose
> > >>>>> commands to run on the CI server. The CI Jenkins jobs are not a
> > >>>>> separate/alternative release process, they are just another way of
> > >>>>> executing the first 40 steps. Using CI jobs actually requires
> > >>> additional
> > >>>>> command-line cut-and-paste to push commits on the CI server and to
> > sign
> > >>> and
> > >>>>> validate binaries locally, but that's the trade-off of not having
> to
> > >>>>> configure your machine to successfully run all of the automated
> tests
> > >>> and
> > >>>>> build systems, and being able to run a command by filling in the
> > version
> > >>>>> number and rc number and hitting the "ok" button instead of making
> > sure
> > >>> you
> > >>>>> got the whole command typed in correctly.
> > >>>>>
> > >>>>> So, an RM can run the first 25 steps locally, then go the CI
> server
> > >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need
> to
> > >>> run
> > >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> > >>> successful,
> > >>>>> then the RM has proven code coverage of the build.xml files. (If
> the
> > >>>>> resulting tar.gz and zips are not posted, then the RM should verify
> > that
> > >>>>> they match the ones from Maven distribution). I would encourage
> RMs
> > to
> > >>>>> also use the CI jobs that generate the emails to make sure the
> > subject
> > >>> and
> > >>>>> content is correct and contains the usual instructions so we have
> > >>>>> consistency. Maybe someday there will be CI jobs to do the last
> 60+
> > >>> steps
> > >>>>> if that helps. We could add a Jenkins job that runs an Ant build
> on
> > RC
> > >>>>> artifacts on dist.a.o as well.
> > >>>>>
> > >>>>> I would like you all to help maintain the list of 100 steps and
> > other
> > >>>>> documents related to the release process, and improve the CI jobs
> and
> > >>> Ant
> > >>>>> steps if it helps you be a more efficient RM. I am hopeful that
> now
> > >>> that I
> > >>>>> have hopefully explained our release process better, that we can
> see
> > >>> that
> > >>>>> these 100+ steps just have to be done in some way. The RM can
> figure
> > >>> out
> > >>>>> what way works best for them, but they must get through all of
> them.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> -Alex
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Carlos Rovira
> > >>>> http://about.me/carlosrovira
> > >>>
> > >>>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> http://about.me/carlosrovira
> > >
> > >
> > >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
RE: Royale Releases
Posted by Yishay Weiss <yi...@hotmail.com>.
>sounds good :)
Hi Carlos,
This sounds like a good plan to me too. Alex and I will do our best to get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May, and you will be in charge of releasing 0.9.9 in June.
Are we still in agreement on that?
Thanks,
Yishay
From: Carlos Rovira<ma...@apache.org>
Sent: Thursday, April 2, 2020 6:47 PM
To: Apache Royale Development<ma...@royale.apache.org>
Subject: Re: Royale Releases
Hi Harbs,
sounds good :)
As well, I expect I can do 0.9.9 in June from my local machine with the
process we already exposed too :)
Thanks
Carlos
El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>) escribió:
> I spent over an hour with Alex on the Zoom last night trying to understand
> all the different technical points.
>
> One point which became clear to me last night is that Ant and Maven are
> distributed differently so there are points of failure that one has which
> the other doesn’t.
>
> I also want to stress that Alex is actually a fan of Maven.
>
> We all want the Maven release to be easier, but somehow this is being
> conflated with bashing Ant.
>
> As far as I’m concerned, the steps forward are:
>
> 1. Yishay should work on releasing 0.9.7.
> 2. He will hopefully be supported by Alex, Chris and Carlos to make it as
> smooth as possible.
> 3. When he’s done, I plan on sitting down with him to discuss his
> experience.
> 4. I plan on working on releasing 0.9.8 sometime in May.
> 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences as well
> as my own to try and understand as much about the process as I can (Ant,
> Maven and NPM too).
> 6. I hope to work with anyone who wants to help to improve the process as
> much as I can.
>
> Sounds OK?
>
> Harbs
>
> > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <ch...@c-ware.de>
> wrote:
> >
> > Hi folks,
> >
> > I would say we have coverage for both maven ant equally as we're
> building the same code.
> >
> > However we are missing the important assertions. It's not that the Ant
> build is running some tests Maven isn't.
> > It's just that the settings for Ant seem to be different than for Maven
> and the Ant ones happen to work.
> >
> > Ideally there would be real tests that test the output of both to see if
> it works in both cases.
> >
> > Chris
> >
> >
> >
> > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> >
> > Adding more coverage for Maven is good.
> >
> > Removing coverage for Ant is not.
> >
> > Do you agree?
> >
> >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> I think what we're trying to say is that until now we released with
> Maven
> >> and Ant, and that was hiding a flaw in Maven (SVG example). So that
> means
> >> what we were trying to cover was not covered clearly, so the premise is
> not
> >> right.
> >>
> >>
> >>
> >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> escribió:
> >>
> >>> No one is arguing that we shouldn’t add more tests.
> >>>
> >>> Please let’s not make it seem like there’s a disagreement about that.
> >>>
> >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi Alex,
> >>>>
> >>>> first, many thanks for the detailed email. I'll comment on this later
> as
> >>> I
> >>>> have more time.
> >>>>
> >>>> For now, to add up a recent example on what Chris commented: If you
> all
> >>>> remember a week ago I was trying to use SVG Images in a blog example
> that
> >>>> was published 2 days ago. Nobody tried SVG Images before building with
> >>>> maven, I know that since maven was not properly configured and using
> that
> >>>> component from Maven was failing with an RTE. Probably we have more
> >>> things
> >>>> not working the same way when build from Maven and Ant, and that's
> >>>> something that will need people using that code paths in test
> >>> applications
> >>>> (or in their own apps) to see if things works properly.
> >>>>
> >>>> I was recently introduced to "examples-integrationtest" by Chris,
> that I
> >>>> plan to use soon as I can. I think is a great idea, since you get a
> >>> Firefox
> >>>> running test interface of the real use of some concrete royale code. I
> >>>> think passed until now unnoticed by all of us, and seems a powerful
> tool.
> >>>> There's already an example about FlexStore with some basic assertions.
> >>>>
> >>>> Again, thanks, and will comment on the rest later
> >>>>
> >>>> Carlos
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >>> christofer.dutz@c-ware.de>)
> >>>> escribió:
> >>>>
> >>>>> Hi Alex,
> >>>>>
> >>>>> just a point you are bringing up: "Code coverage".
> >>>>>
> >>>>> I strongly dislike the idea of "asjs" effectively being the test for
> the
> >>>>> compiler. The reasoning behind this is: yes you do get more code
> >>> covered,
> >>>>> but only the happy-path (ideally) and even if things go wrong, the
> end
> >>>>> results aren't tested. Did add a module to asjs years ago
> >>>>> ("examples-integrationtest") that deployed the examples in a tomcat
> >>> server
> >>>>> then opens a Firefox browser and clicks through 2 of the examples (I
> >>> added
> >>>>> two dummy tests as an example, but seems no one touched this after
> me).
> >>> I
> >>>>> did this because I remember us working on asjs for weeks without
> anyone
> >>>>> noticing the compiler wasn't producing runnable code ... same with
> the
> >>>>> little unit-tests that are still run for every example, that simply
> >>> check
> >>>>> if an output is generated, because we had a prolonged period of time
> >>> where
> >>>>> we were all working on different parts, but for quite some time the
> >>>>> application compilation just didn't output anything and no one
> noticed.
> >>>>>
> >>>>> So coverage is nothing without assertions (my opinion) ... ok ...
> it's
> >>>>> slightly better than no coverage, but not much, in my opinion.
> >>>>>
> >>>>> I think in parallel to this release discussions I have seen numerous
> >>>>> threads about someone doing something that broke something for
> someone
> >>>>> else. This could be addressed by increasing coverage by providing
> >>> explicit
> >>>>> tests.
> >>>>>
> >>>>> Coming back to the releases:
> >>>>> I have no objections, if you do a "release" locally and automate the
> >>>>> validation on the CI server (Which effectively would be your proposal
> >>> to do
> >>>>> the first 12 steps on local hardware and the 13th on the CI server).
> I
> >>> even
> >>>>> think that's a good idea ... There could be one step for building a
> >>> release
> >>>>> from a given "git tag" for every build system and generic means to
> >>> compare
> >>>>> tar.gz and zips produced by any build system with that of another
> >>> (ideally
> >>>>> with better output than just a plain "true/false"). This would even
> >>> help to
> >>>>> iron out the last potentially existing bumps out of the Maven
> >>> distribution.
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>>
> >>>>>
> >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> This is my attempt to explain what goes into a release in hopes that
> >>>>> we can understand and agree on what our release process is. It
> became
> >>>>> apparent in my reading of the wiki page with the new Maven steps and
> in
> >>>>> talking with Harbs today that there are still many misunderstandings
> >>> about
> >>>>> what we do to create a release. I don't generally like writing
> >>>>> instructions in English because it is easy to be ambiguous. All of
> the
> >>>>> steps that we use to create releases had been captured in Ant scripts
> >>> in a
> >>>>> much more explicit way, IMO, but I took the time to write them down
> in
> >>>>> English here:
> >>>>>
> >>>
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
> >>>>>
> >>>>> I did this quickly by scanning the CI steps, the new Maven steps and
> >>>>> the Ant scripts used in prior releases so there could certainly be
> >>> mistakes
> >>>>> and missed steps. If I did my math right, the RM for 0.9.7 will
> have to
> >>>>> complete over 100 tasks (essentially, typing a command-line 100
> times).
> >>>>> Future RMs, when we don't have to release build-tools, will have
> about
> >>> 92
> >>>>> steps. And I did not include voter verification checks the RM should
> >>> run
> >>>>> before opening a vote (verifying that the artifacts download and
> match
> >>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
> >>> before
> >>>>> sending out the vote. Maybe we should add those to the task list.
> >>>>>
> >>>>> I think there has been confusion about the use of Ant in the release
> >>>>> process. Because I was the RM for the first set of FlexJS/Royale
> >>> releases,
> >>>>> and I'm a lazy person who hates typing at the command line, I created
> >>> Ant
> >>>>> scripts to execute these 100 steps. But I agree that it is not a
> >>>>> requirement that other RMs must use the Ant scripts for these
> >>> commands. If
> >>>>> you are the RM and like typing, go ahead.
> >>>>>
> >>>>> Then we found out that other people couldn't get through this task
> >>>>> list. I think the 3 people who tried were having trouble with Maven
> >>>>> uploads and downloads. So what I did was put the first 40 steps or
> so
> >>> into
> >>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >>>>> release. And that also saves on manually typing commands. But
> again,
> >>>>> going forward, the RM gets to choose how they want to execute these
> >>> steps.
> >>>>>
> >>>>> If you scan the set of steps, you'll see that "ant" is only in there
> >>>>> once. I believe the recent threads have been about this single
> command
> >>> out
> >>>>> of the 100+ commands. This is why this has been so frustrating to
> me.
> >>> I
> >>>>> believe there is a solid technical reason for that one command: it
> >>> proves
> >>>>> that the build.xml files in the source packages can build the .tar.gz
> >>> that
> >>>>> are useful to NPM and IDE users who use Ant and want to test a
> change.
> >>>>>
> >>>>> I think of it as code-coverage. If we had code-coverage tools, we
> >>>>> would ask that the RM complete as much of the automated code-coverage
> >>>>> testing as possible before posting the release for a vote. That one
> >>>>> command increases our code coverage by running the build.xml files.
> We
> >>>>> should be always working to increase automated code coverage in the
> RC.
> >>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
> >>> run
> >>>>> because a failed RC means going back through many of the first 25
> >>> commands
> >>>>> again and wastes other people's time. Each RC is more emails to read
> >>> and
> >>>>> more time from the voters and testers.
> >>>>>
> >>>>> If there are other ways for the RM to get the same or better code
> >>>>> coverage on the build.xml files before posting the RC, we can discuss
> >>> those
> >>>>> options.
> >>>>>
> >>>>> I am hopeful we can all agree on these simple principles: Strive
> for
> >>>>> better code coverage and fewer failed RCs. Royale's main purpose is
> to
> >>>>> save other people time. Let's do that in creating releases too.
> >>>>>
> >>>>> One issue that was brought up recently was whether it is a good
> >>>>> decision to have the RM test all of the build platforms we support.
> >>>>> Suppose we add some other build system support or more in the future?
> >>>>> Again, the code coverage principle applies here, but also, I would
> like
> >>> us
> >>>>> to retain feature parity, and I also hope for as few RCs and votes as
> >>>>> possible. So instead of having separate votes/features/release-dates
> >>> for
> >>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >>>>> artifacts, I think we should have one vote and keep them all in sync.
> >>> If
> >>>>> we do ever get around to monthly or bi-monthly releases, I think
> >>> separate
> >>>>> build platform releases would be too much work.
> >>>>>
> >>>>> But consider this thought I just had today: the RM doesn't really
> >>>>> have to choose to do all 100 commands on a local machine or with Ant
> >>>>> scripts or do the first 40 via CI. The RM can actually pick and
> choose
> >>>>> commands to run on the CI server. The CI Jenkins jobs are not a
> >>>>> separate/alternative release process, they are just another way of
> >>>>> executing the first 40 steps. Using CI jobs actually requires
> >>> additional
> >>>>> command-line cut-and-paste to push commits on the CI server and to
> sign
> >>> and
> >>>>> validate binaries locally, but that's the trade-off of not having to
> >>>>> configure your machine to successfully run all of the automated tests
> >>> and
> >>>>> build systems, and being able to run a command by filling in the
> version
> >>>>> number and rc number and hitting the "ok" button instead of making
> sure
> >>> you
> >>>>> got the whole command typed in correctly.
> >>>>>
> >>>>> So, an RM can run the first 25 steps locally, then go the CI server
> >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
> >>> run
> >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> >>> successful,
> >>>>> then the RM has proven code coverage of the build.xml files. (If the
> >>>>> resulting tar.gz and zips are not posted, then the RM should verify
> that
> >>>>> they match the ones from Maven distribution). I would encourage RMs
> to
> >>>>> also use the CI jobs that generate the emails to make sure the
> subject
> >>> and
> >>>>> content is correct and contains the usual instructions so we have
> >>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
> >>> steps
> >>>>> if that helps. We could add a Jenkins job that runs an Ant build on
> RC
> >>>>> artifacts on dist.a.o as well.
> >>>>>
> >>>>> I would like you all to help maintain the list of 100 steps and
> other
> >>>>> documents related to the release process, and improve the CI jobs and
> >>> Ant
> >>>>> steps if it helps you be a more efficient RM. I am hopeful that now
> >>> that I
> >>>>> have hopefully explained our release process better, that we can see
> >>> that
> >>>>> these 100+ steps just have to be done in some way. The RM can figure
> >>> out
> >>>>> what way works best for them, but they must get through all of them.
> >>>>>
> >>>>> Thanks,
> >>>>> -Alex
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> http://about.me/carlosrovira
> >>>
> >>>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >
> >
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
sounds good :)
As well, I expect I can do 0.9.9 in June from my local machine with the
process we already exposed too :)
Thanks
Carlos
El jue., 2 abr. 2020 a las 15:50, Harbs (<ha...@gmail.com>) escribió:
> I spent over an hour with Alex on the Zoom last night trying to understand
> all the different technical points.
>
> One point which became clear to me last night is that Ant and Maven are
> distributed differently so there are points of failure that one has which
> the other doesn’t.
>
> I also want to stress that Alex is actually a fan of Maven.
>
> We all want the Maven release to be easier, but somehow this is being
> conflated with bashing Ant.
>
> As far as I’m concerned, the steps forward are:
>
> 1. Yishay should work on releasing 0.9.7.
> 2. He will hopefully be supported by Alex, Chris and Carlos to make it as
> smooth as possible.
> 3. When he’s done, I plan on sitting down with him to discuss his
> experience.
> 4. I plan on working on releasing 0.9.8 sometime in May.
> 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences as well
> as my own to try and understand as much about the process as I can (Ant,
> Maven and NPM too).
> 6. I hope to work with anyone who wants to help to improve the process as
> much as I can.
>
> Sounds OK?
>
> Harbs
>
> > On Apr 2, 2020, at 4:38 PM, Christofer Dutz <ch...@c-ware.de>
> wrote:
> >
> > Hi folks,
> >
> > I would say we have coverage for both maven ant equally as we're
> building the same code.
> >
> > However we are missing the important assertions. It's not that the Ant
> build is running some tests Maven isn't.
> > It's just that the settings for Ant seem to be different than for Maven
> and the Ant ones happen to work.
> >
> > Ideally there would be real tests that test the output of both to see if
> it works in both cases.
> >
> > Chris
> >
> >
> >
> > Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
> >
> > Adding more coverage for Maven is good.
> >
> > Removing coverage for Ant is not.
> >
> > Do you agree?
> >
> >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >>
> >> Hi Harbs,
> >>
> >> I think what we're trying to say is that until now we released with
> Maven
> >> and Ant, and that was hiding a flaw in Maven (SVG example). So that
> means
> >> what we were trying to cover was not covered clearly, so the premise is
> not
> >> right.
> >>
> >>
> >>
> >> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> escribió:
> >>
> >>> No one is arguing that we shouldn’t add more tests.
> >>>
> >>> Please let’s not make it seem like there’s a disagreement about that.
> >>>
> >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi Alex,
> >>>>
> >>>> first, many thanks for the detailed email. I'll comment on this later
> as
> >>> I
> >>>> have more time.
> >>>>
> >>>> For now, to add up a recent example on what Chris commented: If you
> all
> >>>> remember a week ago I was trying to use SVG Images in a blog example
> that
> >>>> was published 2 days ago. Nobody tried SVG Images before building with
> >>>> maven, I know that since maven was not properly configured and using
> that
> >>>> component from Maven was failing with an RTE. Probably we have more
> >>> things
> >>>> not working the same way when build from Maven and Ant, and that's
> >>>> something that will need people using that code paths in test
> >>> applications
> >>>> (or in their own apps) to see if things works properly.
> >>>>
> >>>> I was recently introduced to "examples-integrationtest" by Chris,
> that I
> >>>> plan to use soon as I can. I think is a great idea, since you get a
> >>> Firefox
> >>>> running test interface of the real use of some concrete royale code. I
> >>>> think passed until now unnoticed by all of us, and seems a powerful
> tool.
> >>>> There's already an example about FlexStore with some basic assertions.
> >>>>
> >>>> Again, thanks, and will comment on the rest later
> >>>>
> >>>> Carlos
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >>> christofer.dutz@c-ware.de>)
> >>>> escribió:
> >>>>
> >>>>> Hi Alex,
> >>>>>
> >>>>> just a point you are bringing up: "Code coverage".
> >>>>>
> >>>>> I strongly dislike the idea of "asjs" effectively being the test for
> the
> >>>>> compiler. The reasoning behind this is: yes you do get more code
> >>> covered,
> >>>>> but only the happy-path (ideally) and even if things go wrong, the
> end
> >>>>> results aren't tested. Did add a module to asjs years ago
> >>>>> ("examples-integrationtest") that deployed the examples in a tomcat
> >>> server
> >>>>> then opens a Firefox browser and clicks through 2 of the examples (I
> >>> added
> >>>>> two dummy tests as an example, but seems no one touched this after
> me).
> >>> I
> >>>>> did this because I remember us working on asjs for weeks without
> anyone
> >>>>> noticing the compiler wasn't producing runnable code ... same with
> the
> >>>>> little unit-tests that are still run for every example, that simply
> >>> check
> >>>>> if an output is generated, because we had a prolonged period of time
> >>> where
> >>>>> we were all working on different parts, but for quite some time the
> >>>>> application compilation just didn't output anything and no one
> noticed.
> >>>>>
> >>>>> So coverage is nothing without assertions (my opinion) ... ok ...
> it's
> >>>>> slightly better than no coverage, but not much, in my opinion.
> >>>>>
> >>>>> I think in parallel to this release discussions I have seen numerous
> >>>>> threads about someone doing something that broke something for
> someone
> >>>>> else. This could be addressed by increasing coverage by providing
> >>> explicit
> >>>>> tests.
> >>>>>
> >>>>> Coming back to the releases:
> >>>>> I have no objections, if you do a "release" locally and automate the
> >>>>> validation on the CI server (Which effectively would be your proposal
> >>> to do
> >>>>> the first 12 steps on local hardware and the 13th on the CI server).
> I
> >>> even
> >>>>> think that's a good idea ... There could be one step for building a
> >>> release
> >>>>> from a given "git tag" for every build system and generic means to
> >>> compare
> >>>>> tar.gz and zips produced by any build system with that of another
> >>> (ideally
> >>>>> with better output than just a plain "true/false"). This would even
> >>> help to
> >>>>> iron out the last potentially existing bumps out of the Maven
> >>> distribution.
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>>
> >>>>>
> >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> This is my attempt to explain what goes into a release in hopes that
> >>>>> we can understand and agree on what our release process is. It
> became
> >>>>> apparent in my reading of the wiki page with the new Maven steps and
> in
> >>>>> talking with Harbs today that there are still many misunderstandings
> >>> about
> >>>>> what we do to create a release. I don't generally like writing
> >>>>> instructions in English because it is easy to be ambiguous. All of
> the
> >>>>> steps that we use to create releases had been captured in Ant scripts
> >>> in a
> >>>>> much more explicit way, IMO, but I took the time to write them down
> in
> >>>>> English here:
> >>>>>
> >>>
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
> >>>>>
> >>>>> I did this quickly by scanning the CI steps, the new Maven steps and
> >>>>> the Ant scripts used in prior releases so there could certainly be
> >>> mistakes
> >>>>> and missed steps. If I did my math right, the RM for 0.9.7 will
> have to
> >>>>> complete over 100 tasks (essentially, typing a command-line 100
> times).
> >>>>> Future RMs, when we don't have to release build-tools, will have
> about
> >>> 92
> >>>>> steps. And I did not include voter verification checks the RM should
> >>> run
> >>>>> before opening a vote (verifying that the artifacts download and
> match
> >>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
> >>> before
> >>>>> sending out the vote. Maybe we should add those to the task list.
> >>>>>
> >>>>> I think there has been confusion about the use of Ant in the release
> >>>>> process. Because I was the RM for the first set of FlexJS/Royale
> >>> releases,
> >>>>> and I'm a lazy person who hates typing at the command line, I created
> >>> Ant
> >>>>> scripts to execute these 100 steps. But I agree that it is not a
> >>>>> requirement that other RMs must use the Ant scripts for these
> >>> commands. If
> >>>>> you are the RM and like typing, go ahead.
> >>>>>
> >>>>> Then we found out that other people couldn't get through this task
> >>>>> list. I think the 3 people who tried were having trouble with Maven
> >>>>> uploads and downloads. So what I did was put the first 40 steps or
> so
> >>> into
> >>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >>>>> release. And that also saves on manually typing commands. But
> again,
> >>>>> going forward, the RM gets to choose how they want to execute these
> >>> steps.
> >>>>>
> >>>>> If you scan the set of steps, you'll see that "ant" is only in there
> >>>>> once. I believe the recent threads have been about this single
> command
> >>> out
> >>>>> of the 100+ commands. This is why this has been so frustrating to
> me.
> >>> I
> >>>>> believe there is a solid technical reason for that one command: it
> >>> proves
> >>>>> that the build.xml files in the source packages can build the .tar.gz
> >>> that
> >>>>> are useful to NPM and IDE users who use Ant and want to test a
> change.
> >>>>>
> >>>>> I think of it as code-coverage. If we had code-coverage tools, we
> >>>>> would ask that the RM complete as much of the automated code-coverage
> >>>>> testing as possible before posting the release for a vote. That one
> >>>>> command increases our code coverage by running the build.xml files.
> We
> >>>>> should be always working to increase automated code coverage in the
> RC.
> >>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
> >>> run
> >>>>> because a failed RC means going back through many of the first 25
> >>> commands
> >>>>> again and wastes other people's time. Each RC is more emails to read
> >>> and
> >>>>> more time from the voters and testers.
> >>>>>
> >>>>> If there are other ways for the RM to get the same or better code
> >>>>> coverage on the build.xml files before posting the RC, we can discuss
> >>> those
> >>>>> options.
> >>>>>
> >>>>> I am hopeful we can all agree on these simple principles: Strive
> for
> >>>>> better code coverage and fewer failed RCs. Royale's main purpose is
> to
> >>>>> save other people time. Let's do that in creating releases too.
> >>>>>
> >>>>> One issue that was brought up recently was whether it is a good
> >>>>> decision to have the RM test all of the build platforms we support.
> >>>>> Suppose we add some other build system support or more in the future?
> >>>>> Again, the code coverage principle applies here, but also, I would
> like
> >>> us
> >>>>> to retain feature parity, and I also hope for as few RCs and votes as
> >>>>> possible. So instead of having separate votes/features/release-dates
> >>> for
> >>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >>>>> artifacts, I think we should have one vote and keep them all in sync.
> >>> If
> >>>>> we do ever get around to monthly or bi-monthly releases, I think
> >>> separate
> >>>>> build platform releases would be too much work.
> >>>>>
> >>>>> But consider this thought I just had today: the RM doesn't really
> >>>>> have to choose to do all 100 commands on a local machine or with Ant
> >>>>> scripts or do the first 40 via CI. The RM can actually pick and
> choose
> >>>>> commands to run on the CI server. The CI Jenkins jobs are not a
> >>>>> separate/alternative release process, they are just another way of
> >>>>> executing the first 40 steps. Using CI jobs actually requires
> >>> additional
> >>>>> command-line cut-and-paste to push commits on the CI server and to
> sign
> >>> and
> >>>>> validate binaries locally, but that's the trade-off of not having to
> >>>>> configure your machine to successfully run all of the automated tests
> >>> and
> >>>>> build systems, and being able to run a command by filling in the
> version
> >>>>> number and rc number and hitting the "ok" button instead of making
> sure
> >>> you
> >>>>> got the whole command typed in correctly.
> >>>>>
> >>>>> So, an RM can run the first 25 steps locally, then go the CI server
> >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
> >>> run
> >>>>> the first 12) and it will run tasks 26 through 32, and if it is
> >>> successful,
> >>>>> then the RM has proven code coverage of the build.xml files. (If the
> >>>>> resulting tar.gz and zips are not posted, then the RM should verify
> that
> >>>>> they match the ones from Maven distribution). I would encourage RMs
> to
> >>>>> also use the CI jobs that generate the emails to make sure the
> subject
> >>> and
> >>>>> content is correct and contains the usual instructions so we have
> >>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
> >>> steps
> >>>>> if that helps. We could add a Jenkins job that runs an Ant build on
> RC
> >>>>> artifacts on dist.a.o as well.
> >>>>>
> >>>>> I would like you all to help maintain the list of 100 steps and
> other
> >>>>> documents related to the release process, and improve the CI jobs and
> >>> Ant
> >>>>> steps if it helps you be a more efficient RM. I am hopeful that now
> >>> that I
> >>>>> have hopefully explained our release process better, that we can see
> >>> that
> >>>>> these 100+ steps just have to be done in some way. The RM can figure
> >>> out
> >>>>> what way works best for them, but they must get through all of them.
> >>>>>
> >>>>> Thanks,
> >>>>> -Alex
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> http://about.me/carlosrovira
> >>>
> >>>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >
> >
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Harbs <ha...@gmail.com>.
I spent over an hour with Alex on the Zoom last night trying to understand all the different technical points.
One point which became clear to me last night is that Ant and Maven are distributed differently so there are points of failure that one has which the other doesn’t.
I also want to stress that Alex is actually a fan of Maven.
We all want the Maven release to be easier, but somehow this is being conflated with bashing Ant.
As far as I’m concerned, the steps forward are:
1. Yishay should work on releasing 0.9.7.
2. He will hopefully be supported by Alex, Chris and Carlos to make it as smooth as possible.
3. When he’s done, I plan on sitting down with him to discuss his experience.
4. I plan on working on releasing 0.9.8 sometime in May.
5. While I’m working on 0.9.8 I expect to use Yishay’s experiences as well as my own to try and understand as much about the process as I can (Ant, Maven and NPM too).
6. I hope to work with anyone who wants to help to improve the process as much as I can.
Sounds OK?
Harbs
> On Apr 2, 2020, at 4:38 PM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi folks,
>
> I would say we have coverage for both maven ant equally as we're building the same code.
>
> However we are missing the important assertions. It's not that the Ant build is running some tests Maven isn't.
> It's just that the settings for Ant seem to be different than for Maven and the Ant ones happen to work.
>
> Ideally there would be real tests that test the output of both to see if it works in both cases.
>
> Chris
>
>
>
> Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
>
> Adding more coverage for Maven is good.
>
> Removing coverage for Ant is not.
>
> Do you agree?
>
>> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>>
>> Hi Harbs,
>>
>> I think what we're trying to say is that until now we released with Maven
>> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
>> what we were trying to cover was not covered clearly, so the premise is not
>> right.
>>
>>
>>
>> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>>
>>> No one is arguing that we shouldn’t add more tests.
>>>
>>> Please let’s not make it seem like there’s a disagreement about that.
>>>
>>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>>> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> first, many thanks for the detailed email. I'll comment on this later as
>>> I
>>>> have more time.
>>>>
>>>> For now, to add up a recent example on what Chris commented: If you all
>>>> remember a week ago I was trying to use SVG Images in a blog example that
>>>> was published 2 days ago. Nobody tried SVG Images before building with
>>>> maven, I know that since maven was not properly configured and using that
>>>> component from Maven was failing with an RTE. Probably we have more
>>> things
>>>> not working the same way when build from Maven and Ant, and that's
>>>> something that will need people using that code paths in test
>>> applications
>>>> (or in their own apps) to see if things works properly.
>>>>
>>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>>> plan to use soon as I can. I think is a great idea, since you get a
>>> Firefox
>>>> running test interface of the real use of some concrete royale code. I
>>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>>> There's already an example about FlexStore with some basic assertions.
>>>>
>>>> Again, thanks, and will comment on the rest later
>>>>
>>>> Carlos
>>>>
>>>>
>>>>
>>>>
>>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>>> christofer.dutz@c-ware.de>)
>>>> escribió:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> just a point you are bringing up: "Code coverage".
>>>>>
>>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>>> compiler. The reasoning behind this is: yes you do get more code
>>> covered,
>>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>>> results aren't tested. Did add a module to asjs years ago
>>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>>> server
>>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>>> added
>>>>> two dummy tests as an example, but seems no one touched this after me).
>>> I
>>>>> did this because I remember us working on asjs for weeks without anyone
>>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>>> little unit-tests that are still run for every example, that simply
>>> check
>>>>> if an output is generated, because we had a prolonged period of time
>>> where
>>>>> we were all working on different parts, but for quite some time the
>>>>> application compilation just didn't output anything and no one noticed.
>>>>>
>>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>>> slightly better than no coverage, but not much, in my opinion.
>>>>>
>>>>> I think in parallel to this release discussions I have seen numerous
>>>>> threads about someone doing something that broke something for someone
>>>>> else. This could be addressed by increasing coverage by providing
>>> explicit
>>>>> tests.
>>>>>
>>>>> Coming back to the releases:
>>>>> I have no objections, if you do a "release" locally and automate the
>>>>> validation on the CI server (Which effectively would be your proposal
>>> to do
>>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>>> even
>>>>> think that's a good idea ... There could be one step for building a
>>> release
>>>>> from a given "git tag" for every build system and generic means to
>>> compare
>>>>> tar.gz and zips produced by any build system with that of another
>>> (ideally
>>>>> with better output than just a plain "true/false"). This would even
>>> help to
>>>>> iron out the last potentially existing bumps out of the Maven
>>> distribution.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This is my attempt to explain what goes into a release in hopes that
>>>>> we can understand and agree on what our release process is. It became
>>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>>> talking with Harbs today that there are still many misunderstandings
>>> about
>>>>> what we do to create a release. I don't generally like writing
>>>>> instructions in English because it is easy to be ambiguous. All of the
>>>>> steps that we use to create releases had been captured in Ant scripts
>>> in a
>>>>> much more explicit way, IMO, but I took the time to write them down in
>>>>> English here:
>>>>>
>>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>>
>>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>>> the Ant scripts used in prior releases so there could certainly be
>>> mistakes
>>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>>> Future RMs, when we don't have to release build-tools, will have about
>>> 92
>>>>> steps. And I did not include voter verification checks the RM should
>>> run
>>>>> before opening a vote (verifying that the artifacts download and match
>>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>>> before
>>>>> sending out the vote. Maybe we should add those to the task list.
>>>>>
>>>>> I think there has been confusion about the use of Ant in the release
>>>>> process. Because I was the RM for the first set of FlexJS/Royale
>>> releases,
>>>>> and I'm a lazy person who hates typing at the command line, I created
>>> Ant
>>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>>> requirement that other RMs must use the Ant scripts for these
>>> commands. If
>>>>> you are the RM and like typing, go ahead.
>>>>>
>>>>> Then we found out that other people couldn't get through this task
>>>>> list. I think the 3 people who tried were having trouble with Maven
>>>>> uploads and downloads. So what I did was put the first 40 steps or so
>>> into
>>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>>> release. And that also saves on manually typing commands. But again,
>>>>> going forward, the RM gets to choose how they want to execute these
>>> steps.
>>>>>
>>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>>> once. I believe the recent threads have been about this single command
>>> out
>>>>> of the 100+ commands. This is why this has been so frustrating to me.
>>> I
>>>>> believe there is a solid technical reason for that one command: it
>>> proves
>>>>> that the build.xml files in the source packages can build the .tar.gz
>>> that
>>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>>
>>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>>> would ask that the RM complete as much of the automated code-coverage
>>>>> testing as possible before posting the release for a vote. That one
>>>>> command increases our code coverage by running the build.xml files. We
>>>>> should be always working to increase automated code coverage in the RC.
>>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>>> run
>>>>> because a failed RC means going back through many of the first 25
>>> commands
>>>>> again and wastes other people's time. Each RC is more emails to read
>>> and
>>>>> more time from the voters and testers.
>>>>>
>>>>> If there are other ways for the RM to get the same or better code
>>>>> coverage on the build.xml files before posting the RC, we can discuss
>>> those
>>>>> options.
>>>>>
>>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>>> save other people time. Let's do that in creating releases too.
>>>>>
>>>>> One issue that was brought up recently was whether it is a good
>>>>> decision to have the RM test all of the build platforms we support.
>>>>> Suppose we add some other build system support or more in the future?
>>>>> Again, the code coverage principle applies here, but also, I would like
>>> us
>>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>>> possible. So instead of having separate votes/features/release-dates
>>> for
>>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>>> artifacts, I think we should have one vote and keep them all in sync.
>>> If
>>>>> we do ever get around to monthly or bi-monthly releases, I think
>>> separate
>>>>> build platform releases would be too much work.
>>>>>
>>>>> But consider this thought I just had today: the RM doesn't really
>>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>>> separate/alternative release process, they are just another way of
>>>>> executing the first 40 steps. Using CI jobs actually requires
>>> additional
>>>>> command-line cut-and-paste to push commits on the CI server and to sign
>>> and
>>>>> validate binaries locally, but that's the trade-off of not having to
>>>>> configure your machine to successfully run all of the automated tests
>>> and
>>>>> build systems, and being able to run a command by filling in the version
>>>>> number and rc number and hitting the "ok" button instead of making sure
>>> you
>>>>> got the whole command typed in correctly.
>>>>>
>>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>>> run
>>>>> the first 12) and it will run tasks 26 through 32, and if it is
>>> successful,
>>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>>> also use the CI jobs that generate the emails to make sure the subject
>>> and
>>>>> content is correct and contains the usual instructions so we have
>>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>>> steps
>>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>>> artifacts on dist.a.o as well.
>>>>>
>>>>> I would like you all to help maintain the list of 100 steps and other
>>>>> documents related to the release process, and improve the CI jobs and
>>> Ant
>>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>>> that I
>>>>> have hopefully explained our release process better, that we can see
>>> that
>>>>> these 100+ steps just have to be done in some way. The RM can figure
>>> out
>>>>> what way works best for them, but they must get through all of them.
>>>>>
>>>>> Thanks,
>>>>> -Alex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>
>>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>
>
>
Re: Royale Releases
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi folks,
I would say we have coverage for both maven ant equally as we're building the same code.
However we are missing the important assertions. It's not that the Ant build is running some tests Maven isn't.
It's just that the settings for Ant seem to be different than for Maven and the Ant ones happen to work.
Ideally there would be real tests that test the output of both to see if it works in both cases.
Chris
Am 02.04.20, 15:15 schrieb "Harbs" <ha...@gmail.com>:
Adding more coverage for Maven is good.
Removing coverage for Ant is not.
Do you agree?
> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I think what we're trying to say is that until now we released with Maven
> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
> what we were trying to cover was not covered clearly, so the premise is not
> right.
>
>
>
> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>
>> No one is arguing that we shouldn’t add more tests.
>>
>> Please let’s not make it seem like there’s a disagreement about that.
>>
>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> first, many thanks for the detailed email. I'll comment on this later as
>> I
>>> have more time.
>>>
>>> For now, to add up a recent example on what Chris commented: If you all
>>> remember a week ago I was trying to use SVG Images in a blog example that
>>> was published 2 days ago. Nobody tried SVG Images before building with
>>> maven, I know that since maven was not properly configured and using that
>>> component from Maven was failing with an RTE. Probably we have more
>> things
>>> not working the same way when build from Maven and Ant, and that's
>>> something that will need people using that code paths in test
>> applications
>>> (or in their own apps) to see if things works properly.
>>>
>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>> plan to use soon as I can. I think is a great idea, since you get a
>> Firefox
>>> running test interface of the real use of some concrete royale code. I
>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>> There's already an example about FlexStore with some basic assertions.
>>>
>>> Again, thanks, and will comment on the rest later
>>>
>>> Carlos
>>>
>>>
>>>
>>>
>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> christofer.dutz@c-ware.de>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> just a point you are bringing up: "Code coverage".
>>>>
>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>> compiler. The reasoning behind this is: yes you do get more code
>> covered,
>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>> results aren't tested. Did add a module to asjs years ago
>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>> server
>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>> added
>>>> two dummy tests as an example, but seems no one touched this after me).
>> I
>>>> did this because I remember us working on asjs for weeks without anyone
>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>> little unit-tests that are still run for every example, that simply
>> check
>>>> if an output is generated, because we had a prolonged period of time
>> where
>>>> we were all working on different parts, but for quite some time the
>>>> application compilation just didn't output anything and no one noticed.
>>>>
>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>> slightly better than no coverage, but not much, in my opinion.
>>>>
>>>> I think in parallel to this release discussions I have seen numerous
>>>> threads about someone doing something that broke something for someone
>>>> else. This could be addressed by increasing coverage by providing
>> explicit
>>>> tests.
>>>>
>>>> Coming back to the releases:
>>>> I have no objections, if you do a "release" locally and automate the
>>>> validation on the CI server (Which effectively would be your proposal
>> to do
>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>> even
>>>> think that's a good idea ... There could be one step for building a
>> release
>>>> from a given "git tag" for every build system and generic means to
>> compare
>>>> tar.gz and zips produced by any build system with that of another
>> (ideally
>>>> with better output than just a plain "true/false"). This would even
>> help to
>>>> iron out the last potentially existing bumps out of the Maven
>> distribution.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>
>>>> Hi,
>>>>
>>>> This is my attempt to explain what goes into a release in hopes that
>>>> we can understand and agree on what our release process is. It became
>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>> talking with Harbs today that there are still many misunderstandings
>> about
>>>> what we do to create a release. I don't generally like writing
>>>> instructions in English because it is easy to be ambiguous. All of the
>>>> steps that we use to create releases had been captured in Ant scripts
>> in a
>>>> much more explicit way, IMO, but I took the time to write them down in
>>>> English here:
>>>>
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>
>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>> the Ant scripts used in prior releases so there could certainly be
>> mistakes
>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>> Future RMs, when we don't have to release build-tools, will have about
>> 92
>>>> steps. And I did not include voter verification checks the RM should
>> run
>>>> before opening a vote (verifying that the artifacts download and match
>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>> before
>>>> sending out the vote. Maybe we should add those to the task list.
>>>>
>>>> I think there has been confusion about the use of Ant in the release
>>>> process. Because I was the RM for the first set of FlexJS/Royale
>> releases,
>>>> and I'm a lazy person who hates typing at the command line, I created
>> Ant
>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>> requirement that other RMs must use the Ant scripts for these
>> commands. If
>>>> you are the RM and like typing, go ahead.
>>>>
>>>> Then we found out that other people couldn't get through this task
>>>> list. I think the 3 people who tried were having trouble with Maven
>>>> uploads and downloads. So what I did was put the first 40 steps or so
>> into
>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>> release. And that also saves on manually typing commands. But again,
>>>> going forward, the RM gets to choose how they want to execute these
>> steps.
>>>>
>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>> once. I believe the recent threads have been about this single command
>> out
>>>> of the 100+ commands. This is why this has been so frustrating to me.
>> I
>>>> believe there is a solid technical reason for that one command: it
>> proves
>>>> that the build.xml files in the source packages can build the .tar.gz
>> that
>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>
>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>> would ask that the RM complete as much of the automated code-coverage
>>>> testing as possible before posting the release for a vote. That one
>>>> command increases our code coverage by running the build.xml files. We
>>>> should be always working to increase automated code coverage in the RC.
>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>> run
>>>> because a failed RC means going back through many of the first 25
>> commands
>>>> again and wastes other people's time. Each RC is more emails to read
>> and
>>>> more time from the voters and testers.
>>>>
>>>> If there are other ways for the RM to get the same or better code
>>>> coverage on the build.xml files before posting the RC, we can discuss
>> those
>>>> options.
>>>>
>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>> save other people time. Let's do that in creating releases too.
>>>>
>>>> One issue that was brought up recently was whether it is a good
>>>> decision to have the RM test all of the build platforms we support.
>>>> Suppose we add some other build system support or more in the future?
>>>> Again, the code coverage principle applies here, but also, I would like
>> us
>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>> possible. So instead of having separate votes/features/release-dates
>> for
>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>> artifacts, I think we should have one vote and keep them all in sync.
>> If
>>>> we do ever get around to monthly or bi-monthly releases, I think
>> separate
>>>> build platform releases would be too much work.
>>>>
>>>> But consider this thought I just had today: the RM doesn't really
>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>> separate/alternative release process, they are just another way of
>>>> executing the first 40 steps. Using CI jobs actually requires
>> additional
>>>> command-line cut-and-paste to push commits on the CI server and to sign
>> and
>>>> validate binaries locally, but that's the trade-off of not having to
>>>> configure your machine to successfully run all of the automated tests
>> and
>>>> build systems, and being able to run a command by filling in the version
>>>> number and rc number and hitting the "ok" button instead of making sure
>> you
>>>> got the whole command typed in correctly.
>>>>
>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>> run
>>>> the first 12) and it will run tasks 26 through 32, and if it is
>> successful,
>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>> also use the CI jobs that generate the emails to make sure the subject
>> and
>>>> content is correct and contains the usual instructions so we have
>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>> steps
>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>> artifacts on dist.a.o as well.
>>>>
>>>> I would like you all to help maintain the list of 100 steps and other
>>>> documents related to the release process, and improve the CI jobs and
>> Ant
>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>> that I
>>>> have hopefully explained our release process better, that we can see
>> that
>>>> these 100+ steps just have to be done in some way. The RM can figure
>> out
>>>> what way works best for them, but they must get through all of them.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Royale Releases
Posted by Harbs <ha...@gmail.com>.
We’re arguing semantics.
This has nothing to do with Alex’s main points and this discussion is distracting from the main issues.
> On Apr 2, 2020, at 4:25 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Harbs,
>
> again, don't think we're talking about removing code-coverage from anything.
> Code coverage must be in all Maven and Ant. Equally.
> What we're trying to say is that what is actually called "code coverage" is
> not really code coverage.
>
>
> El jue., 2 abr. 2020 a las 15:09, Harbs (<ha...@gmail.com>) escribió:
>
>> Adding more coverage for Maven is good.
>>
>> Removing coverage for Ant is not.
>>
>> Do you agree?
>>
>>> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi Harbs,
>>>
>>> I think what we're trying to say is that until now we released with Maven
>>> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
>>> what we were trying to cover was not covered clearly, so the premise is
>> not
>>> right.
>>>
>>>
>>>
>>> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
>> escribió:
>>>
>>>> No one is arguing that we shouldn’t add more tests.
>>>>
>>>> Please let’s not make it seem like there’s a disagreement about that.
>>>>
>>>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>>>> wrote:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>> first, many thanks for the detailed email. I'll comment on this later
>> as
>>>> I
>>>>> have more time.
>>>>>
>>>>> For now, to add up a recent example on what Chris commented: If you all
>>>>> remember a week ago I was trying to use SVG Images in a blog example
>> that
>>>>> was published 2 days ago. Nobody tried SVG Images before building with
>>>>> maven, I know that since maven was not properly configured and using
>> that
>>>>> component from Maven was failing with an RTE. Probably we have more
>>>> things
>>>>> not working the same way when build from Maven and Ant, and that's
>>>>> something that will need people using that code paths in test
>>>> applications
>>>>> (or in their own apps) to see if things works properly.
>>>>>
>>>>> I was recently introduced to "examples-integrationtest" by Chris, that
>> I
>>>>> plan to use soon as I can. I think is a great idea, since you get a
>>>> Firefox
>>>>> running test interface of the real use of some concrete royale code. I
>>>>> think passed until now unnoticed by all of us, and seems a powerful
>> tool.
>>>>> There's already an example about FlexStore with some basic assertions.
>>>>>
>>>>> Again, thanks, and will comment on the rest later
>>>>>
>>>>> Carlos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>>>> christofer.dutz@c-ware.de>)
>>>>> escribió:
>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> just a point you are bringing up: "Code coverage".
>>>>>>
>>>>>> I strongly dislike the idea of "asjs" effectively being the test for
>> the
>>>>>> compiler. The reasoning behind this is: yes you do get more code
>>>> covered,
>>>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>>>> results aren't tested. Did add a module to asjs years ago
>>>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>>>> server
>>>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>>>> added
>>>>>> two dummy tests as an example, but seems no one touched this after
>> me).
>>>> I
>>>>>> did this because I remember us working on asjs for weeks without
>> anyone
>>>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>>>> little unit-tests that are still run for every example, that simply
>>>> check
>>>>>> if an output is generated, because we had a prolonged period of time
>>>> where
>>>>>> we were all working on different parts, but for quite some time the
>>>>>> application compilation just didn't output anything and no one
>> noticed.
>>>>>>
>>>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>>>> slightly better than no coverage, but not much, in my opinion.
>>>>>>
>>>>>> I think in parallel to this release discussions I have seen numerous
>>>>>> threads about someone doing something that broke something for someone
>>>>>> else. This could be addressed by increasing coverage by providing
>>>> explicit
>>>>>> tests.
>>>>>>
>>>>>> Coming back to the releases:
>>>>>> I have no objections, if you do a "release" locally and automate the
>>>>>> validation on the CI server (Which effectively would be your proposal
>>>> to do
>>>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>>>> even
>>>>>> think that's a good idea ... There could be one step for building a
>>>> release
>>>>>> from a given "git tag" for every build system and generic means to
>>>> compare
>>>>>> tar.gz and zips produced by any build system with that of another
>>>> (ideally
>>>>>> with better output than just a plain "true/false"). This would even
>>>> help to
>>>>>> iron out the last potentially existing bumps out of the Maven
>>>> distribution.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This is my attempt to explain what goes into a release in hopes that
>>>>>> we can understand and agree on what our release process is. It became
>>>>>> apparent in my reading of the wiki page with the new Maven steps and
>> in
>>>>>> talking with Harbs today that there are still many misunderstandings
>>>> about
>>>>>> what we do to create a release. I don't generally like writing
>>>>>> instructions in English because it is easy to be ambiguous. All of
>> the
>>>>>> steps that we use to create releases had been captured in Ant scripts
>>>> in a
>>>>>> much more explicit way, IMO, but I took the time to write them down in
>>>>>> English here:
>>>>>>
>>>>
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>>>
>>>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>>>> the Ant scripts used in prior releases so there could certainly be
>>>> mistakes
>>>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have
>> to
>>>>>> complete over 100 tasks (essentially, typing a command-line 100
>> times).
>>>>>> Future RMs, when we don't have to release build-tools, will have about
>>>> 92
>>>>>> steps. And I did not include voter verification checks the RM should
>>>> run
>>>>>> before opening a vote (verifying that the artifacts download and match
>>>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>>>> before
>>>>>> sending out the vote. Maybe we should add those to the task list.
>>>>>>
>>>>>> I think there has been confusion about the use of Ant in the release
>>>>>> process. Because I was the RM for the first set of FlexJS/Royale
>>>> releases,
>>>>>> and I'm a lazy person who hates typing at the command line, I created
>>>> Ant
>>>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>>>> requirement that other RMs must use the Ant scripts for these
>>>> commands. If
>>>>>> you are the RM and like typing, go ahead.
>>>>>>
>>>>>> Then we found out that other people couldn't get through this task
>>>>>> list. I think the 3 people who tried were having trouble with Maven
>>>>>> uploads and downloads. So what I did was put the first 40 steps or so
>>>> into
>>>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>>>> release. And that also saves on manually typing commands. But again,
>>>>>> going forward, the RM gets to choose how they want to execute these
>>>> steps.
>>>>>>
>>>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>>>> once. I believe the recent threads have been about this single
>> command
>>>> out
>>>>>> of the 100+ commands. This is why this has been so frustrating to me.
>>>> I
>>>>>> believe there is a solid technical reason for that one command: it
>>>> proves
>>>>>> that the build.xml files in the source packages can build the .tar.gz
>>>> that
>>>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>>>
>>>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>>>> would ask that the RM complete as much of the automated code-coverage
>>>>>> testing as possible before posting the release for a vote. That one
>>>>>> command increases our code coverage by running the build.xml files.
>> We
>>>>>> should be always working to increase automated code coverage in the
>> RC.
>>>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>>>> run
>>>>>> because a failed RC means going back through many of the first 25
>>>> commands
>>>>>> again and wastes other people's time. Each RC is more emails to read
>>>> and
>>>>>> more time from the voters and testers.
>>>>>>
>>>>>> If there are other ways for the RM to get the same or better code
>>>>>> coverage on the build.xml files before posting the RC, we can discuss
>>>> those
>>>>>> options.
>>>>>>
>>>>>> I am hopeful we can all agree on these simple principles: Strive
>> for
>>>>>> better code coverage and fewer failed RCs. Royale's main purpose is
>> to
>>>>>> save other people time. Let's do that in creating releases too.
>>>>>>
>>>>>> One issue that was brought up recently was whether it is a good
>>>>>> decision to have the RM test all of the build platforms we support.
>>>>>> Suppose we add some other build system support or more in the future?
>>>>>> Again, the code coverage principle applies here, but also, I would
>> like
>>>> us
>>>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>>>> possible. So instead of having separate votes/features/release-dates
>>>> for
>>>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>>>> artifacts, I think we should have one vote and keep them all in sync.
>>>> If
>>>>>> we do ever get around to monthly or bi-monthly releases, I think
>>>> separate
>>>>>> build platform releases would be too much work.
>>>>>>
>>>>>> But consider this thought I just had today: the RM doesn't really
>>>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>>>> scripts or do the first 40 via CI. The RM can actually pick and
>> choose
>>>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>>>> separate/alternative release process, they are just another way of
>>>>>> executing the first 40 steps. Using CI jobs actually requires
>>>> additional
>>>>>> command-line cut-and-paste to push commits on the CI server and to
>> sign
>>>> and
>>>>>> validate binaries locally, but that's the trade-off of not having to
>>>>>> configure your machine to successfully run all of the automated tests
>>>> and
>>>>>> build systems, and being able to run a command by filling in the
>> version
>>>>>> number and rc number and hitting the "ok" button instead of making
>> sure
>>>> you
>>>>>> got the whole command typed in correctly.
>>>>>>
>>>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>>>> run
>>>>>> the first 12) and it will run tasks 26 through 32, and if it is
>>>> successful,
>>>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>>>> resulting tar.gz and zips are not posted, then the RM should verify
>> that
>>>>>> they match the ones from Maven distribution). I would encourage RMs
>> to
>>>>>> also use the CI jobs that generate the emails to make sure the subject
>>>> and
>>>>>> content is correct and contains the usual instructions so we have
>>>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>>>> steps
>>>>>> if that helps. We could add a Jenkins job that runs an Ant build on
>> RC
>>>>>> artifacts on dist.a.o as well.
>>>>>>
>>>>>> I would like you all to help maintain the list of 100 steps and
>> other
>>>>>> documents related to the release process, and improve the CI jobs and
>>>> Ant
>>>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>>>> that I
>>>>>> have hopefully explained our release process better, that we can see
>>>> that
>>>>>> these 100+ steps just have to be done in some way. The RM can figure
>>>> out
>>>>>> what way works best for them, but they must get through all of them.
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Harbs,
again, don't think we're talking about removing code-coverage from anything.
Code coverage must be in all Maven and Ant. Equally.
What we're trying to say is that what is actually called "code coverage" is
not really code coverage.
El jue., 2 abr. 2020 a las 15:09, Harbs (<ha...@gmail.com>) escribió:
> Adding more coverage for Maven is good.
>
> Removing coverage for Ant is not.
>
> Do you agree?
>
> > On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Harbs,
> >
> > I think what we're trying to say is that until now we released with Maven
> > and Ant, and that was hiding a flaw in Maven (SVG example). So that means
> > what we were trying to cover was not covered clearly, so the premise is
> not
> > right.
> >
> >
> >
> > El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>)
> escribió:
> >
> >> No one is arguing that we shouldn’t add more tests.
> >>
> >> Please let’s not make it seem like there’s a disagreement about that.
> >>
> >>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
> >> wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> first, many thanks for the detailed email. I'll comment on this later
> as
> >> I
> >>> have more time.
> >>>
> >>> For now, to add up a recent example on what Chris commented: If you all
> >>> remember a week ago I was trying to use SVG Images in a blog example
> that
> >>> was published 2 days ago. Nobody tried SVG Images before building with
> >>> maven, I know that since maven was not properly configured and using
> that
> >>> component from Maven was failing with an RTE. Probably we have more
> >> things
> >>> not working the same way when build from Maven and Ant, and that's
> >>> something that will need people using that code paths in test
> >> applications
> >>> (or in their own apps) to see if things works properly.
> >>>
> >>> I was recently introduced to "examples-integrationtest" by Chris, that
> I
> >>> plan to use soon as I can. I think is a great idea, since you get a
> >> Firefox
> >>> running test interface of the real use of some concrete royale code. I
> >>> think passed until now unnoticed by all of us, and seems a powerful
> tool.
> >>> There's already an example about FlexStore with some basic assertions.
> >>>
> >>> Again, thanks, and will comment on the rest later
> >>>
> >>> Carlos
> >>>
> >>>
> >>>
> >>>
> >>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >> christofer.dutz@c-ware.de>)
> >>> escribió:
> >>>
> >>>> Hi Alex,
> >>>>
> >>>> just a point you are bringing up: "Code coverage".
> >>>>
> >>>> I strongly dislike the idea of "asjs" effectively being the test for
> the
> >>>> compiler. The reasoning behind this is: yes you do get more code
> >> covered,
> >>>> but only the happy-path (ideally) and even if things go wrong, the end
> >>>> results aren't tested. Did add a module to asjs years ago
> >>>> ("examples-integrationtest") that deployed the examples in a tomcat
> >> server
> >>>> then opens a Firefox browser and clicks through 2 of the examples (I
> >> added
> >>>> two dummy tests as an example, but seems no one touched this after
> me).
> >> I
> >>>> did this because I remember us working on asjs for weeks without
> anyone
> >>>> noticing the compiler wasn't producing runnable code ... same with the
> >>>> little unit-tests that are still run for every example, that simply
> >> check
> >>>> if an output is generated, because we had a prolonged period of time
> >> where
> >>>> we were all working on different parts, but for quite some time the
> >>>> application compilation just didn't output anything and no one
> noticed.
> >>>>
> >>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
> >>>> slightly better than no coverage, but not much, in my opinion.
> >>>>
> >>>> I think in parallel to this release discussions I have seen numerous
> >>>> threads about someone doing something that broke something for someone
> >>>> else. This could be addressed by increasing coverage by providing
> >> explicit
> >>>> tests.
> >>>>
> >>>> Coming back to the releases:
> >>>> I have no objections, if you do a "release" locally and automate the
> >>>> validation on the CI server (Which effectively would be your proposal
> >> to do
> >>>> the first 12 steps on local hardware and the 13th on the CI server). I
> >> even
> >>>> think that's a good idea ... There could be one step for building a
> >> release
> >>>> from a given "git tag" for every build system and generic means to
> >> compare
> >>>> tar.gz and zips produced by any build system with that of another
> >> (ideally
> >>>> with better output than just a plain "true/false"). This would even
> >> help to
> >>>> iron out the last potentially existing bumps out of the Maven
> >> distribution.
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This is my attempt to explain what goes into a release in hopes that
> >>>> we can understand and agree on what our release process is. It became
> >>>> apparent in my reading of the wiki page with the new Maven steps and
> in
> >>>> talking with Harbs today that there are still many misunderstandings
> >> about
> >>>> what we do to create a release. I don't generally like writing
> >>>> instructions in English because it is easy to be ambiguous. All of
> the
> >>>> steps that we use to create releases had been captured in Ant scripts
> >> in a
> >>>> much more explicit way, IMO, but I took the time to write them down in
> >>>> English here:
> >>>>
> >>
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
> >>>>
> >>>> I did this quickly by scanning the CI steps, the new Maven steps and
> >>>> the Ant scripts used in prior releases so there could certainly be
> >> mistakes
> >>>> and missed steps. If I did my math right, the RM for 0.9.7 will have
> to
> >>>> complete over 100 tasks (essentially, typing a command-line 100
> times).
> >>>> Future RMs, when we don't have to release build-tools, will have about
> >> 92
> >>>> steps. And I did not include voter verification checks the RM should
> >> run
> >>>> before opening a vote (verifying that the artifacts download and match
> >>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
> >> before
> >>>> sending out the vote. Maybe we should add those to the task list.
> >>>>
> >>>> I think there has been confusion about the use of Ant in the release
> >>>> process. Because I was the RM for the first set of FlexJS/Royale
> >> releases,
> >>>> and I'm a lazy person who hates typing at the command line, I created
> >> Ant
> >>>> scripts to execute these 100 steps. But I agree that it is not a
> >>>> requirement that other RMs must use the Ant scripts for these
> >> commands. If
> >>>> you are the RM and like typing, go ahead.
> >>>>
> >>>> Then we found out that other people couldn't get through this task
> >>>> list. I think the 3 people who tried were having trouble with Maven
> >>>> uploads and downloads. So what I did was put the first 40 steps or so
> >> into
> >>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >>>> release. And that also saves on manually typing commands. But again,
> >>>> going forward, the RM gets to choose how they want to execute these
> >> steps.
> >>>>
> >>>> If you scan the set of steps, you'll see that "ant" is only in there
> >>>> once. I believe the recent threads have been about this single
> command
> >> out
> >>>> of the 100+ commands. This is why this has been so frustrating to me.
> >> I
> >>>> believe there is a solid technical reason for that one command: it
> >> proves
> >>>> that the build.xml files in the source packages can build the .tar.gz
> >> that
> >>>> are useful to NPM and IDE users who use Ant and want to test a change.
> >>>>
> >>>> I think of it as code-coverage. If we had code-coverage tools, we
> >>>> would ask that the RM complete as much of the automated code-coverage
> >>>> testing as possible before posting the release for a vote. That one
> >>>> command increases our code coverage by running the build.xml files.
> We
> >>>> should be always working to increase automated code coverage in the
> RC.
> >>>> Certainly for me as RM, I will gladly watch TV as the automated tests
> >> run
> >>>> because a failed RC means going back through many of the first 25
> >> commands
> >>>> again and wastes other people's time. Each RC is more emails to read
> >> and
> >>>> more time from the voters and testers.
> >>>>
> >>>> If there are other ways for the RM to get the same or better code
> >>>> coverage on the build.xml files before posting the RC, we can discuss
> >> those
> >>>> options.
> >>>>
> >>>> I am hopeful we can all agree on these simple principles: Strive
> for
> >>>> better code coverage and fewer failed RCs. Royale's main purpose is
> to
> >>>> save other people time. Let's do that in creating releases too.
> >>>>
> >>>> One issue that was brought up recently was whether it is a good
> >>>> decision to have the RM test all of the build platforms we support.
> >>>> Suppose we add some other build system support or more in the future?
> >>>> Again, the code coverage principle applies here, but also, I would
> like
> >> us
> >>>> to retain feature parity, and I also hope for as few RCs and votes as
> >>>> possible. So instead of having separate votes/features/release-dates
> >> for
> >>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >>>> artifacts, I think we should have one vote and keep them all in sync.
> >> If
> >>>> we do ever get around to monthly or bi-monthly releases, I think
> >> separate
> >>>> build platform releases would be too much work.
> >>>>
> >>>> But consider this thought I just had today: the RM doesn't really
> >>>> have to choose to do all 100 commands on a local machine or with Ant
> >>>> scripts or do the first 40 via CI. The RM can actually pick and
> choose
> >>>> commands to run on the CI server. The CI Jenkins jobs are not a
> >>>> separate/alternative release process, they are just another way of
> >>>> executing the first 40 steps. Using CI jobs actually requires
> >> additional
> >>>> command-line cut-and-paste to push commits on the CI server and to
> sign
> >> and
> >>>> validate binaries locally, but that's the trade-off of not having to
> >>>> configure your machine to successfully run all of the automated tests
> >> and
> >>>> build systems, and being able to run a command by filling in the
> version
> >>>> number and rc number and hitting the "ok" button instead of making
> sure
> >> you
> >>>> got the whole command typed in correctly.
> >>>>
> >>>> So, an RM can run the first 25 steps locally, then go the CI server
> >>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
> >> run
> >>>> the first 12) and it will run tasks 26 through 32, and if it is
> >> successful,
> >>>> then the RM has proven code coverage of the build.xml files. (If the
> >>>> resulting tar.gz and zips are not posted, then the RM should verify
> that
> >>>> they match the ones from Maven distribution). I would encourage RMs
> to
> >>>> also use the CI jobs that generate the emails to make sure the subject
> >> and
> >>>> content is correct and contains the usual instructions so we have
> >>>> consistency. Maybe someday there will be CI jobs to do the last 60+
> >> steps
> >>>> if that helps. We could add a Jenkins job that runs an Ant build on
> RC
> >>>> artifacts on dist.a.o as well.
> >>>>
> >>>> I would like you all to help maintain the list of 100 steps and
> other
> >>>> documents related to the release process, and improve the CI jobs and
> >> Ant
> >>>> steps if it helps you be a more efficient RM. I am hopeful that now
> >> that I
> >>>> have hopefully explained our release process better, that we can see
> >> that
> >>>> these 100+ steps just have to be done in some way. The RM can figure
> >> out
> >>>> what way works best for them, but they must get through all of them.
> >>>>
> >>>> Thanks,
> >>>> -Alex
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>> http://about.me/carlosrovira
> >>
> >>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Harbs <ha...@gmail.com>.
Adding more coverage for Maven is good.
Removing coverage for Ant is not.
Do you agree?
> On Apr 2, 2020, at 4:07 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I think what we're trying to say is that until now we released with Maven
> and Ant, and that was hiding a flaw in Maven (SVG example). So that means
> what we were trying to cover was not covered clearly, so the premise is not
> right.
>
>
>
> El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
>
>> No one is arguing that we shouldn’t add more tests.
>>
>> Please let’s not make it seem like there’s a disagreement about that.
>>
>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> first, many thanks for the detailed email. I'll comment on this later as
>> I
>>> have more time.
>>>
>>> For now, to add up a recent example on what Chris commented: If you all
>>> remember a week ago I was trying to use SVG Images in a blog example that
>>> was published 2 days ago. Nobody tried SVG Images before building with
>>> maven, I know that since maven was not properly configured and using that
>>> component from Maven was failing with an RTE. Probably we have more
>> things
>>> not working the same way when build from Maven and Ant, and that's
>>> something that will need people using that code paths in test
>> applications
>>> (or in their own apps) to see if things works properly.
>>>
>>> I was recently introduced to "examples-integrationtest" by Chris, that I
>>> plan to use soon as I can. I think is a great idea, since you get a
>> Firefox
>>> running test interface of the real use of some concrete royale code. I
>>> think passed until now unnoticed by all of us, and seems a powerful tool.
>>> There's already an example about FlexStore with some basic assertions.
>>>
>>> Again, thanks, and will comment on the rest later
>>>
>>> Carlos
>>>
>>>
>>>
>>>
>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> christofer.dutz@c-ware.de>)
>>> escribió:
>>>
>>>> Hi Alex,
>>>>
>>>> just a point you are bringing up: "Code coverage".
>>>>
>>>> I strongly dislike the idea of "asjs" effectively being the test for the
>>>> compiler. The reasoning behind this is: yes you do get more code
>> covered,
>>>> but only the happy-path (ideally) and even if things go wrong, the end
>>>> results aren't tested. Did add a module to asjs years ago
>>>> ("examples-integrationtest") that deployed the examples in a tomcat
>> server
>>>> then opens a Firefox browser and clicks through 2 of the examples (I
>> added
>>>> two dummy tests as an example, but seems no one touched this after me).
>> I
>>>> did this because I remember us working on asjs for weeks without anyone
>>>> noticing the compiler wasn't producing runnable code ... same with the
>>>> little unit-tests that are still run for every example, that simply
>> check
>>>> if an output is generated, because we had a prolonged period of time
>> where
>>>> we were all working on different parts, but for quite some time the
>>>> application compilation just didn't output anything and no one noticed.
>>>>
>>>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>>>> slightly better than no coverage, but not much, in my opinion.
>>>>
>>>> I think in parallel to this release discussions I have seen numerous
>>>> threads about someone doing something that broke something for someone
>>>> else. This could be addressed by increasing coverage by providing
>> explicit
>>>> tests.
>>>>
>>>> Coming back to the releases:
>>>> I have no objections, if you do a "release" locally and automate the
>>>> validation on the CI server (Which effectively would be your proposal
>> to do
>>>> the first 12 steps on local hardware and the 13th on the CI server). I
>> even
>>>> think that's a good idea ... There could be one step for building a
>> release
>>>> from a given "git tag" for every build system and generic means to
>> compare
>>>> tar.gz and zips produced by any build system with that of another
>> (ideally
>>>> with better output than just a plain "true/false"). This would even
>> help to
>>>> iron out the last potentially existing bumps out of the Maven
>> distribution.
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>>>
>>>> Hi,
>>>>
>>>> This is my attempt to explain what goes into a release in hopes that
>>>> we can understand and agree on what our release process is. It became
>>>> apparent in my reading of the wiki page with the new Maven steps and in
>>>> talking with Harbs today that there are still many misunderstandings
>> about
>>>> what we do to create a release. I don't generally like writing
>>>> instructions in English because it is easy to be ambiguous. All of the
>>>> steps that we use to create releases had been captured in Ant scripts
>> in a
>>>> much more explicit way, IMO, but I took the time to write them down in
>>>> English here:
>>>>
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>>>
>>>> I did this quickly by scanning the CI steps, the new Maven steps and
>>>> the Ant scripts used in prior releases so there could certainly be
>> mistakes
>>>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>>>> complete over 100 tasks (essentially, typing a command-line 100 times).
>>>> Future RMs, when we don't have to release build-tools, will have about
>> 92
>>>> steps. And I did not include voter verification checks the RM should
>> run
>>>> before opening a vote (verifying that the artifacts download and match
>>>> their checksums, etc). As an RM, I run a bunch of tests on the RC
>> before
>>>> sending out the vote. Maybe we should add those to the task list.
>>>>
>>>> I think there has been confusion about the use of Ant in the release
>>>> process. Because I was the RM for the first set of FlexJS/Royale
>> releases,
>>>> and I'm a lazy person who hates typing at the command line, I created
>> Ant
>>>> scripts to execute these 100 steps. But I agree that it is not a
>>>> requirement that other RMs must use the Ant scripts for these
>> commands. If
>>>> you are the RM and like typing, go ahead.
>>>>
>>>> Then we found out that other people couldn't get through this task
>>>> list. I think the 3 people who tried were having trouble with Maven
>>>> uploads and downloads. So what I did was put the first 40 steps or so
>> into
>>>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>>>> release. And that also saves on manually typing commands. But again,
>>>> going forward, the RM gets to choose how they want to execute these
>> steps.
>>>>
>>>> If you scan the set of steps, you'll see that "ant" is only in there
>>>> once. I believe the recent threads have been about this single command
>> out
>>>> of the 100+ commands. This is why this has been so frustrating to me.
>> I
>>>> believe there is a solid technical reason for that one command: it
>> proves
>>>> that the build.xml files in the source packages can build the .tar.gz
>> that
>>>> are useful to NPM and IDE users who use Ant and want to test a change.
>>>>
>>>> I think of it as code-coverage. If we had code-coverage tools, we
>>>> would ask that the RM complete as much of the automated code-coverage
>>>> testing as possible before posting the release for a vote. That one
>>>> command increases our code coverage by running the build.xml files. We
>>>> should be always working to increase automated code coverage in the RC.
>>>> Certainly for me as RM, I will gladly watch TV as the automated tests
>> run
>>>> because a failed RC means going back through many of the first 25
>> commands
>>>> again and wastes other people's time. Each RC is more emails to read
>> and
>>>> more time from the voters and testers.
>>>>
>>>> If there are other ways for the RM to get the same or better code
>>>> coverage on the build.xml files before posting the RC, we can discuss
>> those
>>>> options.
>>>>
>>>> I am hopeful we can all agree on these simple principles: Strive for
>>>> better code coverage and fewer failed RCs. Royale's main purpose is to
>>>> save other people time. Let's do that in creating releases too.
>>>>
>>>> One issue that was brought up recently was whether it is a good
>>>> decision to have the RM test all of the build platforms we support.
>>>> Suppose we add some other build system support or more in the future?
>>>> Again, the code coverage principle applies here, but also, I would like
>> us
>>>> to retain feature parity, and I also hope for as few RCs and votes as
>>>> possible. So instead of having separate votes/features/release-dates
>> for
>>>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>>>> artifacts, I think we should have one vote and keep them all in sync.
>> If
>>>> we do ever get around to monthly or bi-monthly releases, I think
>> separate
>>>> build platform releases would be too much work.
>>>>
>>>> But consider this thought I just had today: the RM doesn't really
>>>> have to choose to do all 100 commands on a local machine or with Ant
>>>> scripts or do the first 40 via CI. The RM can actually pick and choose
>>>> commands to run on the CI server. The CI Jenkins jobs are not a
>>>> separate/alternative release process, they are just another way of
>>>> executing the first 40 steps. Using CI jobs actually requires
>> additional
>>>> command-line cut-and-paste to push commits on the CI server and to sign
>> and
>>>> validate binaries locally, but that's the trade-off of not having to
>>>> configure your machine to successfully run all of the automated tests
>> and
>>>> build systems, and being able to run a command by filling in the version
>>>> number and rc number and hitting the "ok" button instead of making sure
>> you
>>>> got the whole command typed in correctly.
>>>>
>>>> So, an RM can run the first 25 steps locally, then go the CI server
>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
>> run
>>>> the first 12) and it will run tasks 26 through 32, and if it is
>> successful,
>>>> then the RM has proven code coverage of the build.xml files. (If the
>>>> resulting tar.gz and zips are not posted, then the RM should verify that
>>>> they match the ones from Maven distribution). I would encourage RMs to
>>>> also use the CI jobs that generate the emails to make sure the subject
>> and
>>>> content is correct and contains the usual instructions so we have
>>>> consistency. Maybe someday there will be CI jobs to do the last 60+
>> steps
>>>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>>>> artifacts on dist.a.o as well.
>>>>
>>>> I would like you all to help maintain the list of 100 steps and other
>>>> documents related to the release process, and improve the CI jobs and
>> Ant
>>>> steps if it helps you be a more efficient RM. I am hopeful that now
>> that I
>>>> have hopefully explained our release process better, that we can see
>> that
>>>> these 100+ steps just have to be done in some way. The RM can figure
>> out
>>>> what way works best for them, but they must get through all of them.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
I think what we're trying to say is that until now we released with Maven
and Ant, and that was hiding a flaw in Maven (SVG example). So that means
what we were trying to cover was not covered clearly, so the premise is not
right.
El jue., 2 abr. 2020 a las 14:56, Harbs (<ha...@gmail.com>) escribió:
> No one is arguing that we shouldn’t add more tests.
>
> Please let’s not make it seem like there’s a disagreement about that.
>
> > On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > first, many thanks for the detailed email. I'll comment on this later as
> I
> > have more time.
> >
> > For now, to add up a recent example on what Chris commented: If you all
> > remember a week ago I was trying to use SVG Images in a blog example that
> > was published 2 days ago. Nobody tried SVG Images before building with
> > maven, I know that since maven was not properly configured and using that
> > component from Maven was failing with an RTE. Probably we have more
> things
> > not working the same way when build from Maven and Ant, and that's
> > something that will need people using that code paths in test
> applications
> > (or in their own apps) to see if things works properly.
> >
> > I was recently introduced to "examples-integrationtest" by Chris, that I
> > plan to use soon as I can. I think is a great idea, since you get a
> Firefox
> > running test interface of the real use of some concrete royale code. I
> > think passed until now unnoticed by all of us, and seems a powerful tool.
> > There's already an example about FlexStore with some basic assertions.
> >
> > Again, thanks, and will comment on the rest later
> >
> > Carlos
> >
> >
> >
> >
> > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> christofer.dutz@c-ware.de>)
> > escribió:
> >
> >> Hi Alex,
> >>
> >> just a point you are bringing up: "Code coverage".
> >>
> >> I strongly dislike the idea of "asjs" effectively being the test for the
> >> compiler. The reasoning behind this is: yes you do get more code
> covered,
> >> but only the happy-path (ideally) and even if things go wrong, the end
> >> results aren't tested. Did add a module to asjs years ago
> >> ("examples-integrationtest") that deployed the examples in a tomcat
> server
> >> then opens a Firefox browser and clicks through 2 of the examples (I
> added
> >> two dummy tests as an example, but seems no one touched this after me).
> I
> >> did this because I remember us working on asjs for weeks without anyone
> >> noticing the compiler wasn't producing runnable code ... same with the
> >> little unit-tests that are still run for every example, that simply
> check
> >> if an output is generated, because we had a prolonged period of time
> where
> >> we were all working on different parts, but for quite some time the
> >> application compilation just didn't output anything and no one noticed.
> >>
> >> So coverage is nothing without assertions (my opinion) ... ok ... it's
> >> slightly better than no coverage, but not much, in my opinion.
> >>
> >> I think in parallel to this release discussions I have seen numerous
> >> threads about someone doing something that broke something for someone
> >> else. This could be addressed by increasing coverage by providing
> explicit
> >> tests.
> >>
> >> Coming back to the releases:
> >> I have no objections, if you do a "release" locally and automate the
> >> validation on the CI server (Which effectively would be your proposal
> to do
> >> the first 12 steps on local hardware and the 13th on the CI server). I
> even
> >> think that's a good idea ... There could be one step for building a
> release
> >> from a given "git tag" for every build system and generic means to
> compare
> >> tar.gz and zips produced by any build system with that of another
> (ideally
> >> with better output than just a plain "true/false"). This would even
> help to
> >> iron out the last potentially existing bumps out of the Maven
> distribution.
> >>
> >> Chris
> >>
> >>
> >>
> >> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>
> >> Hi,
> >>
> >> This is my attempt to explain what goes into a release in hopes that
> >> we can understand and agree on what our release process is. It became
> >> apparent in my reading of the wiki page with the new Maven steps and in
> >> talking with Harbs today that there are still many misunderstandings
> about
> >> what we do to create a release. I don't generally like writing
> >> instructions in English because it is easy to be ambiguous. All of the
> >> steps that we use to create releases had been captured in Ant scripts
> in a
> >> much more explicit way, IMO, but I took the time to write them down in
> >> English here:
> >>
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
> >>
> >> I did this quickly by scanning the CI steps, the new Maven steps and
> >> the Ant scripts used in prior releases so there could certainly be
> mistakes
> >> and missed steps. If I did my math right, the RM for 0.9.7 will have to
> >> complete over 100 tasks (essentially, typing a command-line 100 times).
> >> Future RMs, when we don't have to release build-tools, will have about
> 92
> >> steps. And I did not include voter verification checks the RM should
> run
> >> before opening a vote (verifying that the artifacts download and match
> >> their checksums, etc). As an RM, I run a bunch of tests on the RC
> before
> >> sending out the vote. Maybe we should add those to the task list.
> >>
> >> I think there has been confusion about the use of Ant in the release
> >> process. Because I was the RM for the first set of FlexJS/Royale
> releases,
> >> and I'm a lazy person who hates typing at the command line, I created
> Ant
> >> scripts to execute these 100 steps. But I agree that it is not a
> >> requirement that other RMs must use the Ant scripts for these
> commands. If
> >> you are the RM and like typing, go ahead.
> >>
> >> Then we found out that other people couldn't get through this task
> >> list. I think the 3 people who tried were having trouble with Maven
> >> uploads and downloads. So what I did was put the first 40 steps or so
> into
> >> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >> release. And that also saves on manually typing commands. But again,
> >> going forward, the RM gets to choose how they want to execute these
> steps.
> >>
> >> If you scan the set of steps, you'll see that "ant" is only in there
> >> once. I believe the recent threads have been about this single command
> out
> >> of the 100+ commands. This is why this has been so frustrating to me.
> I
> >> believe there is a solid technical reason for that one command: it
> proves
> >> that the build.xml files in the source packages can build the .tar.gz
> that
> >> are useful to NPM and IDE users who use Ant and want to test a change.
> >>
> >> I think of it as code-coverage. If we had code-coverage tools, we
> >> would ask that the RM complete as much of the automated code-coverage
> >> testing as possible before posting the release for a vote. That one
> >> command increases our code coverage by running the build.xml files. We
> >> should be always working to increase automated code coverage in the RC.
> >> Certainly for me as RM, I will gladly watch TV as the automated tests
> run
> >> because a failed RC means going back through many of the first 25
> commands
> >> again and wastes other people's time. Each RC is more emails to read
> and
> >> more time from the voters and testers.
> >>
> >> If there are other ways for the RM to get the same or better code
> >> coverage on the build.xml files before posting the RC, we can discuss
> those
> >> options.
> >>
> >> I am hopeful we can all agree on these simple principles: Strive for
> >> better code coverage and fewer failed RCs. Royale's main purpose is to
> >> save other people time. Let's do that in creating releases too.
> >>
> >> One issue that was brought up recently was whether it is a good
> >> decision to have the RM test all of the build platforms we support.
> >> Suppose we add some other build system support or more in the future?
> >> Again, the code coverage principle applies here, but also, I would like
> us
> >> to retain feature parity, and I also hope for as few RCs and votes as
> >> possible. So instead of having separate votes/features/release-dates
> for
> >> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >> artifacts, I think we should have one vote and keep them all in sync.
> If
> >> we do ever get around to monthly or bi-monthly releases, I think
> separate
> >> build platform releases would be too much work.
> >>
> >> But consider this thought I just had today: the RM doesn't really
> >> have to choose to do all 100 commands on a local machine or with Ant
> >> scripts or do the first 40 via CI. The RM can actually pick and choose
> >> commands to run on the CI server. The CI Jenkins jobs are not a
> >> separate/alternative release process, they are just another way of
> >> executing the first 40 steps. Using CI jobs actually requires
> additional
> >> command-line cut-and-paste to push commits on the CI server and to sign
> and
> >> validate binaries locally, but that's the trade-off of not having to
> >> configure your machine to successfully run all of the automated tests
> and
> >> build systems, and being able to run a command by filling in the version
> >> number and rc number and hitting the "ok" button instead of making sure
> you
> >> got the whole command typed in correctly.
> >>
> >> So, an RM can run the first 25 steps locally, then go the CI server
> >> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to
> run
> >> the first 12) and it will run tasks 26 through 32, and if it is
> successful,
> >> then the RM has proven code coverage of the build.xml files. (If the
> >> resulting tar.gz and zips are not posted, then the RM should verify that
> >> they match the ones from Maven distribution). I would encourage RMs to
> >> also use the CI jobs that generate the emails to make sure the subject
> and
> >> content is correct and contains the usual instructions so we have
> >> consistency. Maybe someday there will be CI jobs to do the last 60+
> steps
> >> if that helps. We could add a Jenkins job that runs an Ant build on RC
> >> artifacts on dist.a.o as well.
> >>
> >> I would like you all to help maintain the list of 100 steps and other
> >> documents related to the release process, and improve the CI jobs and
> Ant
> >> steps if it helps you be a more efficient RM. I am hopeful that now
> that I
> >> have hopefully explained our release process better, that we can see
> that
> >> these 100+ steps just have to be done in some way. The RM can figure
> out
> >> what way works best for them, but they must get through all of them.
> >>
> >> Thanks,
> >> -Alex
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Harbs <ha...@gmail.com>.
No one is arguing that we shouldn’t add more tests.
Please let’s not make it seem like there’s a disagreement about that.
> On Apr 2, 2020, at 10:46 AM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Alex,
>
> first, many thanks for the detailed email. I'll comment on this later as I
> have more time.
>
> For now, to add up a recent example on what Chris commented: If you all
> remember a week ago I was trying to use SVG Images in a blog example that
> was published 2 days ago. Nobody tried SVG Images before building with
> maven, I know that since maven was not properly configured and using that
> component from Maven was failing with an RTE. Probably we have more things
> not working the same way when build from Maven and Ant, and that's
> something that will need people using that code paths in test applications
> (or in their own apps) to see if things works properly.
>
> I was recently introduced to "examples-integrationtest" by Chris, that I
> plan to use soon as I can. I think is a great idea, since you get a Firefox
> running test interface of the real use of some concrete royale code. I
> think passed until now unnoticed by all of us, and seems a powerful tool.
> There's already an example about FlexStore with some basic assertions.
>
> Again, thanks, and will comment on the rest later
>
> Carlos
>
>
>
>
> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<ch...@c-ware.de>)
> escribió:
>
>> Hi Alex,
>>
>> just a point you are bringing up: "Code coverage".
>>
>> I strongly dislike the idea of "asjs" effectively being the test for the
>> compiler. The reasoning behind this is: yes you do get more code covered,
>> but only the happy-path (ideally) and even if things go wrong, the end
>> results aren't tested. Did add a module to asjs years ago
>> ("examples-integrationtest") that deployed the examples in a tomcat server
>> then opens a Firefox browser and clicks through 2 of the examples (I added
>> two dummy tests as an example, but seems no one touched this after me). I
>> did this because I remember us working on asjs for weeks without anyone
>> noticing the compiler wasn't producing runnable code ... same with the
>> little unit-tests that are still run for every example, that simply check
>> if an output is generated, because we had a prolonged period of time where
>> we were all working on different parts, but for quite some time the
>> application compilation just didn't output anything and no one noticed.
>>
>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>> slightly better than no coverage, but not much, in my opinion.
>>
>> I think in parallel to this release discussions I have seen numerous
>> threads about someone doing something that broke something for someone
>> else. This could be addressed by increasing coverage by providing explicit
>> tests.
>>
>> Coming back to the releases:
>> I have no objections, if you do a "release" locally and automate the
>> validation on the CI server (Which effectively would be your proposal to do
>> the first 12 steps on local hardware and the 13th on the CI server). I even
>> think that's a good idea ... There could be one step for building a release
>> from a given "git tag" for every build system and generic means to compare
>> tar.gz and zips produced by any build system with that of another (ideally
>> with better output than just a plain "true/false"). This would even help to
>> iron out the last potentially existing bumps out of the Maven distribution.
>>
>> Chris
>>
>>
>>
>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>
>> Hi,
>>
>> This is my attempt to explain what goes into a release in hopes that
>> we can understand and agree on what our release process is. It became
>> apparent in my reading of the wiki page with the new Maven steps and in
>> talking with Harbs today that there are still many misunderstandings about
>> what we do to create a release. I don't generally like writing
>> instructions in English because it is easy to be ambiguous. All of the
>> steps that we use to create releases had been captured in Ant scripts in a
>> much more explicit way, IMO, but I took the time to write them down in
>> English here:
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>
>> I did this quickly by scanning the CI steps, the new Maven steps and
>> the Ant scripts used in prior releases so there could certainly be mistakes
>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>> complete over 100 tasks (essentially, typing a command-line 100 times).
>> Future RMs, when we don't have to release build-tools, will have about 92
>> steps. And I did not include voter verification checks the RM should run
>> before opening a vote (verifying that the artifacts download and match
>> their checksums, etc). As an RM, I run a bunch of tests on the RC before
>> sending out the vote. Maybe we should add those to the task list.
>>
>> I think there has been confusion about the use of Ant in the release
>> process. Because I was the RM for the first set of FlexJS/Royale releases,
>> and I'm a lazy person who hates typing at the command line, I created Ant
>> scripts to execute these 100 steps. But I agree that it is not a
>> requirement that other RMs must use the Ant scripts for these commands. If
>> you are the RM and like typing, go ahead.
>>
>> Then we found out that other people couldn't get through this task
>> list. I think the 3 people who tried were having trouble with Maven
>> uploads and downloads. So what I did was put the first 40 steps or so into
>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>> release. And that also saves on manually typing commands. But again,
>> going forward, the RM gets to choose how they want to execute these steps.
>>
>> If you scan the set of steps, you'll see that "ant" is only in there
>> once. I believe the recent threads have been about this single command out
>> of the 100+ commands. This is why this has been so frustrating to me. I
>> believe there is a solid technical reason for that one command: it proves
>> that the build.xml files in the source packages can build the .tar.gz that
>> are useful to NPM and IDE users who use Ant and want to test a change.
>>
>> I think of it as code-coverage. If we had code-coverage tools, we
>> would ask that the RM complete as much of the automated code-coverage
>> testing as possible before posting the release for a vote. That one
>> command increases our code coverage by running the build.xml files. We
>> should be always working to increase automated code coverage in the RC.
>> Certainly for me as RM, I will gladly watch TV as the automated tests run
>> because a failed RC means going back through many of the first 25 commands
>> again and wastes other people's time. Each RC is more emails to read and
>> more time from the voters and testers.
>>
>> If there are other ways for the RM to get the same or better code
>> coverage on the build.xml files before posting the RC, we can discuss those
>> options.
>>
>> I am hopeful we can all agree on these simple principles: Strive for
>> better code coverage and fewer failed RCs. Royale's main purpose is to
>> save other people time. Let's do that in creating releases too.
>>
>> One issue that was brought up recently was whether it is a good
>> decision to have the RM test all of the build platforms we support.
>> Suppose we add some other build system support or more in the future?
>> Again, the code coverage principle applies here, but also, I would like us
>> to retain feature parity, and I also hope for as few RCs and votes as
>> possible. So instead of having separate votes/features/release-dates for
>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>> artifacts, I think we should have one vote and keep them all in sync. If
>> we do ever get around to monthly or bi-monthly releases, I think separate
>> build platform releases would be too much work.
>>
>> But consider this thought I just had today: the RM doesn't really
>> have to choose to do all 100 commands on a local machine or with Ant
>> scripts or do the first 40 via CI. The RM can actually pick and choose
>> commands to run on the CI server. The CI Jenkins jobs are not a
>> separate/alternative release process, they are just another way of
>> executing the first 40 steps. Using CI jobs actually requires additional
>> command-line cut-and-paste to push commits on the CI server and to sign and
>> validate binaries locally, but that's the trade-off of not having to
>> configure your machine to successfully run all of the automated tests and
>> build systems, and being able to run a command by filling in the version
>> number and rc number and hitting the "ok" button instead of making sure you
>> got the whole command typed in correctly.
>>
>> So, an RM can run the first 25 steps locally, then go the CI server
>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run
>> the first 12) and it will run tasks 26 through 32, and if it is successful,
>> then the RM has proven code coverage of the build.xml files. (If the
>> resulting tar.gz and zips are not posted, then the RM should verify that
>> they match the ones from Maven distribution). I would encourage RMs to
>> also use the CI jobs that generate the emails to make sure the subject and
>> content is correct and contains the usual instructions so we have
>> consistency. Maybe someday there will be CI jobs to do the last 60+ steps
>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>> artifacts on dist.a.o as well.
>>
>> I would like you all to help maintain the list of 100 steps and other
>> documents related to the release process, and improve the CI jobs and Ant
>> steps if it helps you be a more efficient RM. I am hopeful that now that I
>> have hopefully explained our release process better, that we can see that
>> these 100+ steps just have to be done in some way. The RM can figure out
>> what way works best for them, but they must get through all of them.
>>
>> Thanks,
>> -Alex
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Create new branch when creating a release (was Fwd: Royale
Releases)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It is Maven's default settings so it seems like their recommended workflow. Any changes to the develop branch after the release branches are cut are not going to be in the 0.9.7 artifacts, so I would think you would want to bump up the version to avoid confusion.
-Alex
On 4/13/20, 12:52 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi,
I don't think maven recommends doing this in concrete. Although if that was
the case, we are making many changes to the real process that is really
recommended, so doing something more don't thing will a problem in our case.
El lun., 13 abr. 2020 a las 9:42, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Why should we have a different branch strategy than what Maven recommends?
>
> On 4/13/20, 12:38 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I think there's a misunderstanding about this. Now that you passed
> compiler
> and reach typedefs, you can see we have commits in both repositories in
> develop branch with version changes. So this morning, building from
> sources
> is making me build 0.9.8 of compiler and typedefs. But people not
> working
> in release should be agnostic of all that process, and we should still
> be
> able to build 0.9.7-SNAPSHOT and commit to develop.
>
> For that reason in this thread I was proposing to create branches from
> the
> point where RM want to release, so people working on develop can
> continue
> its work.
>
> Right now my way to work is to not update develop with latest commits
> that
> increase versions in compiler and typedefs
>
> Thanks
>
>
>
> El mié., 8 abr. 2020 a las 19:24, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > ok
> >
> > El mié., 8 abr. 2020 a las 19:05, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> When I get to step 14, a release branch will be cut. I'm still
> back on
> >> step 2.
> >>
> >> -Alex
> >>
> >> On 4/8/20, 12:06 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> Hi Alex,
> >>
> >> I think we didn't understand each other. In this thread I was
> asking
> >> to
> >> avoid the use of "develop" branch to do the release, instead
> use a new
> >> branch (let's say we name it "release-process-0.9.7" and the RM
> can do
> >> whatever he needs there. In that way, the rest of us are not
> affected.
> >>
> >> Right now in Royale-compiler we have 2 commits about releasing
> >> build-tools,
> >> that I want to avoid. Those in particular are not problematic,
> but
> >> will be
> >> the ones for compiler, typedefs and framework in case the
> release is
> >> not
> >> done quickly.
> >>
> >> The main problems in the way we do now:
> >> - If release need to be aborted, will have lots of
> >> "[maven-release-plugin]"
> >> commits done and reverted.
> >> - developers using the current snapshot will need to not update
> the
> >> commits
> >> with the new versions to continue building the snapshot that is
> used
> >> in the
> >> rest of repos.
> >>
> >> so steps 14,18 and 22 was not what I was referring to.
> >>
> >> Thanks
> >>
> >>
> >> El vie., 3 abr. 2020 a las 6:38, Alex Harui
> (<aharui@adobe.com.invalid
> >> >)
> >> escribió:
> >>
> >> > Steps 14, 18, and 22 in [1] dictate the use of branches.
> >> >
> >> > [1]
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735551844&sdata=rFLF9sHz0Nu9VLOGmseps%2BrtcMjGcwoBoWc%2FA%2BOVXcc%3D&reserved=0
> >> >
> >> > -Alex
> >> >
> >> > On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > sending this again, since it was missed in the other
> thread,
> >> but is
> >> > something not related.
> >> >
> >> > ---------- Forwarded message ---------
> >> > De: Carlos Rovira <ca...@apache.org>
> >> > Date: jue., 2 abr. 2020 a las 14:32
> >> > Subject: Re: Royale Releases
> >> > To: Apache Royale Development <de...@royale.apache.org>
> >> >
> >> >
> >> > Hi,
> >> >
> >> > one thing I want to propose before other considerations:
> >> >
> >> > When starting work on a release, could we work on a new
> branch?
> >> >
> >> > so all commits go to that branch and when all is done then
> >> merge to
> >> > develop? I think that will generate less problems to
> people
> >> working in
> >> > develop branch since releases can be wrong or test can
> delay
> >> some days,
> >> > that means people can have versions updated while other
> parts
> >> of the
> >> > code
> >> > still require old versions, so that generate confusion.
> Doing
> >> all in a
> >> > new
> >> > branch and then merging after all votes passes, seems to
> me the
> >> best
> >> > way to
> >> > keep safe users working on develop.
> >> >
> >> > Thanks
> >> >
> >> >
> >> > El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
> >> > carlosrovira@apache.org>)
> >> > escribió:
> >> >
> >> > > Hi Alex,
> >> > >
> >> > > first, many thanks for the detailed email. I'll comment
> on
> >> this
> >> > later as I
> >> > > have more time.
> >> > >
> >> > > For now, to add up a recent example on what Chris
> commented:
> >> If you
> >> > all
> >> > > remember a week ago I was trying to use SVG Images in a
> blog
> >> example
> >> > that
> >> > > was published 2 days ago. Nobody tried SVG Images before
> >> building
> >> > with
> >> > > maven, I know that since maven was not properly
> configured
> >> and using
> >> > that
> >> > > component from Maven was failing with an RTE. Probably
> we
> >> have more
> >> > things
> >> > > not working the same way when build from Maven and Ant,
> and
> >> that's
> >> > > something that will need people using that code paths
> in test
> >> > applications
> >> > > (or in their own apps) to see if things works properly.
> >> > >
> >> > > I was recently introduced to "examples-integrationtest"
> by
> >> Chris,
> >> > that I
> >> > > plan to use soon as I can. I think is a great idea,
> since you
> >> get a
> >> > Firefox
> >> > > running test interface of the real use of some concrete
> >> royale code.
> >> > I
> >> > > think passed until now unnoticed by all of us, and
> seems a
> >> powerful
> >> > tool.
> >> > > There's already an example about FlexStore with some
> basic
> >> > assertions.
> >> > >
> >> > > Again, thanks, and will comment on the rest later
> >> > >
> >> > > Carlos
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >> > > christofer.dutz@c-ware.de>) escribió:
> >> > >
> >> > >> Hi Alex,
> >> > >>
> >> > >> just a point you are bringing up: "Code coverage".
> >> > >>
> >> > >> I strongly dislike the idea of "asjs" effectively
> being the
> >> test
> >> > for the
> >> > >> compiler. The reasoning behind this is: yes you do get
> more
> >> code
> >> > covered,
> >> > >> but only the happy-path (ideally) and even if things go
> >> wrong, the
> >> > end
> >> > >> results aren't tested. Did add a module to asjs years
> ago
> >> > >> ("examples-integrationtest") that deployed the
> examples in a
> >> tomcat
> >> > server
> >> > >> then opens a Firefox browser and clicks through 2 of
> the
> >> examples
> >> > (I added
> >> > >> two dummy tests as an example, but seems no one
> touched this
> >> after
> >> > me). I
> >> > >> did this because I remember us working on asjs for
> weeks
> >> without
> >> > anyone
> >> > >> noticing the compiler wasn't producing runnable code
> ...
> >> same with
> >> > the
> >> > >> little unit-tests that are still run for every
> example, that
> >> simply
> >> > check
> >> > >> if an output is generated, because we had a prolonged
> period
> >> of
> >> > time where
> >> > >> we were all working on different parts, but for quite
> some
> >> time the
> >> > >> application compilation just didn't output anything
> and no
> >> one
> >> > noticed.
> >> > >>
> >> > >> So coverage is nothing without assertions (my opinion)
> ...
> >> ok ...
> >> > it's
> >> > >> slightly better than no coverage, but not much, in my
> >> opinion.
> >> > >>
> >> > >> I think in parallel to this release discussions I have
> seen
> >> numerous
> >> > >> threads about someone doing something that broke
> something
> >> for
> >> > someone
> >> > >> else. This could be addressed by increasing coverage by
> >> providing
> >> > explicit
> >> > >> tests.
> >> > >>
> >> > >> Coming back to the releases:
> >> > >> I have no objections, if you do a "release" locally and
> >> automate the
> >> > >> validation on the CI server (Which effectively would
> be your
> >> > proposal to do
> >> > >> the first 12 steps on local hardware and the 13th on
> the CI
> >> > server). I even
> >> > >> think that's a good idea ... There could be one step
> for
> >> building a
> >> > release
> >> > >> from a given "git tag" for every build system and
> generic
> >> means to
> >> > compare
> >> > >> tar.gz and zips produced by any build system with that
> of
> >> another
> >> > (ideally
> >> > >> with better output than just a plain "true/false").
> This
> >> would even
> >> > help to
> >> > >> iron out the last potentially existing bumps out of
> the Maven
> >> > distribution.
> >> > >>
> >> > >> Chris
> >> > >>
> >> > >>
> >> > >>
> >> > >> Am 02.04.20, 07:59 schrieb "Alex Harui"
> >> <ah...@adobe.com.INVALID>:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> This is my attempt to explain what goes into a
> release
> >> in hopes
> >> > that
> >> > >> we can understand and agree on what our release
> process is.
> >> It
> >> > became
> >> > >> apparent in my reading of the wiki page with the new
> Maven
> >> steps
> >> > and in
> >> > >> talking with Harbs today that there are still many
> >> > misunderstandings about
> >> > >> what we do to create a release. I don't generally like
> >> writing
> >> > >> instructions in English because it is easy to be
> ambiguous.
> >> All of
> >> > the
> >> > >> steps that we use to create releases had been captured
> in Ant
> >> > scripts in a
> >> > >> much more explicit way, IMO, but I took the time to
> write
> >> them down
> >> > in
> >> > >> English here:
> >> > >>
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=c%2FJFP1SMJV%2Fvnuy2RL2u3MMoyNnwJnPBc8goVvmM9fM%3D&reserved=0
> >> > >>
> >> > >> I did this quickly by scanning the CI steps, the
> new
> >> Maven
> >> > steps and
> >> > >> the Ant scripts used in prior releases so there could
> >> certainly be
> >> > mistakes
> >> > >> and missed steps. If I did my math right, the RM for
> 0.9.7
> >> will
> >> > have to
> >> > >> complete over 100 tasks (essentially, typing a
> command-line
> >> 100
> >> > times).
> >> > >> Future RMs, when we don't have to release build-tools,
> will
> >> have
> >> > about 92
> >> > >> steps. And I did not include voter verification
> checks the
> >> RM
> >> > should run
> >> > >> before opening a vote (verifying that the artifacts
> download
> >> and
> >> > match
> >> > >> their checksums, etc). As an RM, I run a bunch of
> tests on
> >> the RC
> >> > before
> >> > >> sending out the vote. Maybe we should add those to
> the task
> >> list.
> >> > >>
> >> > >> I think there has been confusion about the use of
> Ant in
> >> the
> >> > release
> >> > >> process. Because I was the RM for the first set of
> >> FlexJS/Royale
> >> > releases,
> >> > >> and I'm a lazy person who hates typing at the command
> line, I
> >> > created Ant
> >> > >> scripts to execute these 100 steps. But I agree that
> it is
> >> not a
> >> > >> requirement that other RMs must use the Ant scripts
> for these
> >> > commands. If
> >> > >> you are the RM and like typing, go ahead.
> >> > >>
> >> > >> Then we found out that other people couldn't get
> through
> >> this
> >> > task
> >> > >> list. I think the 3 people who tried were having
> trouble
> >> with Maven
> >> > >> uploads and downloads. So what I did was put the
> first 40
> >> steps or
> >> > so into
> >> > >> Jenkins jobs. And by doing that, Piotr was able to
> produce
> >> our last
> >> > >> release. And that also saves on manually typing
> commands.
> >> But
> >> > again,
> >> > >> going forward, the RM gets to choose how they want to
> >> execute these
> >> > steps.
> >> > >>
> >> > >> If you scan the set of steps, you'll see that
> "ant" is
> >> only in
> >> > there
> >> > >> once. I believe the recent threads have been about
> this
> >> single
> >> > command out
> >> > >> of the 100+ commands. This is why this has been so
> >> frustrating to
> >> > me. I
> >> > >> believe there is a solid technical reason for that one
> >> command: it
> >> > proves
> >> > >> that the build.xml files in the source packages can
> build the
> >> > .tar.gz that
> >> > >> are useful to NPM and IDE users who use Ant and want
> to test
> >> a
> >> > change.
> >> > >>
> >> > >> I think of it as code-coverage. If we had
> code-coverage
> >> tools,
> >> > we
> >> > >> would ask that the RM complete as much of the automated
> >> > code-coverage
> >> > >> testing as possible before posting the release for a
> vote.
> >> That one
> >> > >> command increases our code coverage by running the
> build.xml
> >> > files. We
> >> > >> should be always working to increase automated code
> coverage
> >> in the
> >> > RC.
> >> > >> Certainly for me as RM, I will gladly watch TV as the
> >> automated
> >> > tests run
> >> > >> because a failed RC means going back through many of
> the
> >> first 25
> >> > commands
> >> > >> again and wastes other people's time. Each RC is more
> >> emails to
> >> > read and
> >> > >> more time from the voters and testers.
> >> > >>
> >> > >> If there are other ways for the RM to get the same
> or
> >> better
> >> > code
> >> > >> coverage on the build.xml files before posting the RC,
> we can
> >> > discuss those
> >> > >> options.
> >> > >>
> >> > >> I am hopeful we can all agree on these simple
> principles:
> >> > Strive for
> >> > >> better code coverage and fewer failed RCs. Royale's
> main
> >> purpose
> >> > is to
> >> > >> save other people time. Let's do that in creating
> releases
> >> too.
> >> > >>
> >> > >> One issue that was brought up recently was whether
> it is
> >> a good
> >> > >> decision to have the RM test all of the build
> platforms we
> >> support.
> >> > >> Suppose we add some other build system support or more
> in the
> >> > future?
> >> > >> Again, the code coverage principle applies here, but
> also, I
> >> would
> >> > like us
> >> > >> to retain feature parity, and I also hope for as few
> RCs and
> >> votes
> >> > as
> >> > >> possible. So instead of having separate
> >> > votes/features/release-dates for
> >> > >> the Maven artifacts vs the Ant artifacts vs the
> >> SomeFutureBuildTech
> >> > >> artifacts, I think we should have one vote and keep
> them all
> >> in
> >> > sync. If
> >> > >> we do ever get around to monthly or bi-monthly
> releases, I
> >> think
> >> > separate
> >> > >> build platform releases would be too much work.
> >> > >>
> >> > >> But consider this thought I just had today: the RM
> >> doesn't
> >> > really
> >> > >> have to choose to do all 100 commands on a local
> machine or
> >> with Ant
> >> > >> scripts or do the first 40 via CI. The RM can
> actually pick
> >> and
> >> > choose
> >> > >> commands to run on the CI server. The CI Jenkins jobs
> are
> >> not a
> >> > >> separate/alternative release process, they are just
> another
> >> way of
> >> > >> executing the first 40 steps. Using CI jobs actually
> >> requires
> >> > additional
> >> > >> command-line cut-and-paste to push commits on the CI
> server
> >> and to
> >> > sign and
> >> > >> validate binaries locally, but that's the trade-off of
> not
> >> having to
> >> > >> configure your machine to successfully run all of the
> >> automated
> >> > tests and
> >> > >> build systems, and being able to run a command by
> filling in
> >> the
> >> > version
> >> > >> number and rc number and hitting the "ok" button
> instead of
> >> making
> >> > sure you
> >> > >> got the whole command typed in correctly.
> >> > >>
> >> > >> So, an RM can run the first 25 steps locally, then
> go
> >> the CI
> >> > server
> >> > >> and run what is now Jenkins Job
> "Royale_Release_Step_013"
> >> (no need
> >> > to run
> >> > >> the first 12) and it will run tasks 26 through 32, and
> if it
> >> is
> >> > successful,
> >> > >> then the RM has proven code coverage of the build.xml
> >> files. (If
> >> > the
> >> > >> resulting tar.gz and zips are not posted, then the RM
> should
> >> verify
> >> > that
> >> > >> they match the ones from Maven distribution). I would
> >> encourage
> >> > RMs to
> >> > >> also use the CI jobs that generate the emails to make
> sure
> >> the
> >> > subject and
> >> > >> content is correct and contains the usual instructions
> so we
> >> have
> >> > >> consistency. Maybe someday there will be CI jobs to
> do the
> >> last
> >> > 60+ steps
> >> > >> if that helps. We could add a Jenkins job that runs
> an Ant
> >> build
> >> > on RC
> >> > >> artifacts on dist.a.o as well.
> >> > >>
> >> > >> I would like you all to help maintain the list of
> 100
> >> steps and
> >> > other
> >> > >> documents related to the release process, and improve
> the CI
> >> jobs
> >> > and Ant
> >> > >> steps if it helps you be a more efficient RM. I am
> hopeful
> >> that
> >> > now that I
> >> > >> have hopefully explained our release process better,
> that we
> >> can
> >> > see that
> >> > >> these 100+ steps just have to be done in some way.
> The RM
> >> can
> >> > figure out
> >> > >> what way works best for them, but they must get
> through all
> >> of them.
> >> > >>
> >> > >> Thanks,
> >> > >> -Alex
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
> >> > >
> >> > >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
> >> >
> >> >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
> >> >
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4d74ceb504cb4452d60b08d7df7fab0e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223611735561785&sdata=%2BPYjrSry%2BEM%2F55uvnEy7WXV%2FGseDonpiDsfsonRddWc%3D&reserved=0
Re: Create new branch when creating a release (was Fwd: Royale Releases)
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I don't think maven recommends doing this in concrete. Although if that was
the case, we are making many changes to the real process that is really
recommended, so doing something more don't thing will a problem in our case.
El lun., 13 abr. 2020 a las 9:42, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Why should we have a different branch strategy than what Maven recommends?
>
> On 4/13/20, 12:38 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I think there's a misunderstanding about this. Now that you passed
> compiler
> and reach typedefs, you can see we have commits in both repositories in
> develop branch with version changes. So this morning, building from
> sources
> is making me build 0.9.8 of compiler and typedefs. But people not
> working
> in release should be agnostic of all that process, and we should still
> be
> able to build 0.9.7-SNAPSHOT and commit to develop.
>
> For that reason in this thread I was proposing to create branches from
> the
> point where RM want to release, so people working on develop can
> continue
> its work.
>
> Right now my way to work is to not update develop with latest commits
> that
> increase versions in compiler and typedefs
>
> Thanks
>
>
>
> El mié., 8 abr. 2020 a las 19:24, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > ok
> >
> > El mié., 8 abr. 2020 a las 19:05, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> When I get to step 14, a release branch will be cut. I'm still
> back on
> >> step 2.
> >>
> >> -Alex
> >>
> >> On 4/8/20, 12:06 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> Hi Alex,
> >>
> >> I think we didn't understand each other. In this thread I was
> asking
> >> to
> >> avoid the use of "develop" branch to do the release, instead
> use a new
> >> branch (let's say we name it "release-process-0.9.7" and the RM
> can do
> >> whatever he needs there. In that way, the rest of us are not
> affected.
> >>
> >> Right now in Royale-compiler we have 2 commits about releasing
> >> build-tools,
> >> that I want to avoid. Those in particular are not problematic,
> but
> >> will be
> >> the ones for compiler, typedefs and framework in case the
> release is
> >> not
> >> done quickly.
> >>
> >> The main problems in the way we do now:
> >> - If release need to be aborted, will have lots of
> >> "[maven-release-plugin]"
> >> commits done and reverted.
> >> - developers using the current snapshot will need to not update
> the
> >> commits
> >> with the new versions to continue building the snapshot that is
> used
> >> in the
> >> rest of repos.
> >>
> >> so steps 14,18 and 22 was not what I was referring to.
> >>
> >> Thanks
> >>
> >>
> >> El vie., 3 abr. 2020 a las 6:38, Alex Harui
> (<aharui@adobe.com.invalid
> >> >)
> >> escribió:
> >>
> >> > Steps 14, 18, and 22 in [1] dictate the use of branches.
> >> >
> >> > [1]
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=CmDCiZpPK3iy6ZkSaOP3GQv2KBDIIW6VX%2FSf7az46HM%3D&reserved=0
> >> >
> >> > -Alex
> >> >
> >> > On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > sending this again, since it was missed in the other
> thread,
> >> but is
> >> > something not related.
> >> >
> >> > ---------- Forwarded message ---------
> >> > De: Carlos Rovira <ca...@apache.org>
> >> > Date: jue., 2 abr. 2020 a las 14:32
> >> > Subject: Re: Royale Releases
> >> > To: Apache Royale Development <de...@royale.apache.org>
> >> >
> >> >
> >> > Hi,
> >> >
> >> > one thing I want to propose before other considerations:
> >> >
> >> > When starting work on a release, could we work on a new
> branch?
> >> >
> >> > so all commits go to that branch and when all is done then
> >> merge to
> >> > develop? I think that will generate less problems to
> people
> >> working in
> >> > develop branch since releases can be wrong or test can
> delay
> >> some days,
> >> > that means people can have versions updated while other
> parts
> >> of the
> >> > code
> >> > still require old versions, so that generate confusion.
> Doing
> >> all in a
> >> > new
> >> > branch and then merging after all votes passes, seems to
> me the
> >> best
> >> > way to
> >> > keep safe users working on develop.
> >> >
> >> > Thanks
> >> >
> >> >
> >> > El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
> >> > carlosrovira@apache.org>)
> >> > escribió:
> >> >
> >> > > Hi Alex,
> >> > >
> >> > > first, many thanks for the detailed email. I'll comment
> on
> >> this
> >> > later as I
> >> > > have more time.
> >> > >
> >> > > For now, to add up a recent example on what Chris
> commented:
> >> If you
> >> > all
> >> > > remember a week ago I was trying to use SVG Images in a
> blog
> >> example
> >> > that
> >> > > was published 2 days ago. Nobody tried SVG Images before
> >> building
> >> > with
> >> > > maven, I know that since maven was not properly
> configured
> >> and using
> >> > that
> >> > > component from Maven was failing with an RTE. Probably
> we
> >> have more
> >> > things
> >> > > not working the same way when build from Maven and Ant,
> and
> >> that's
> >> > > something that will need people using that code paths
> in test
> >> > applications
> >> > > (or in their own apps) to see if things works properly.
> >> > >
> >> > > I was recently introduced to "examples-integrationtest"
> by
> >> Chris,
> >> > that I
> >> > > plan to use soon as I can. I think is a great idea,
> since you
> >> get a
> >> > Firefox
> >> > > running test interface of the real use of some concrete
> >> royale code.
> >> > I
> >> > > think passed until now unnoticed by all of us, and
> seems a
> >> powerful
> >> > tool.
> >> > > There's already an example about FlexStore with some
> basic
> >> > assertions.
> >> > >
> >> > > Again, thanks, and will comment on the rest later
> >> > >
> >> > > Carlos
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> >> > > christofer.dutz@c-ware.de>) escribió:
> >> > >
> >> > >> Hi Alex,
> >> > >>
> >> > >> just a point you are bringing up: "Code coverage".
> >> > >>
> >> > >> I strongly dislike the idea of "asjs" effectively
> being the
> >> test
> >> > for the
> >> > >> compiler. The reasoning behind this is: yes you do get
> more
> >> code
> >> > covered,
> >> > >> but only the happy-path (ideally) and even if things go
> >> wrong, the
> >> > end
> >> > >> results aren't tested. Did add a module to asjs years
> ago
> >> > >> ("examples-integrationtest") that deployed the
> examples in a
> >> tomcat
> >> > server
> >> > >> then opens a Firefox browser and clicks through 2 of
> the
> >> examples
> >> > (I added
> >> > >> two dummy tests as an example, but seems no one
> touched this
> >> after
> >> > me). I
> >> > >> did this because I remember us working on asjs for
> weeks
> >> without
> >> > anyone
> >> > >> noticing the compiler wasn't producing runnable code
> ...
> >> same with
> >> > the
> >> > >> little unit-tests that are still run for every
> example, that
> >> simply
> >> > check
> >> > >> if an output is generated, because we had a prolonged
> period
> >> of
> >> > time where
> >> > >> we were all working on different parts, but for quite
> some
> >> time the
> >> > >> application compilation just didn't output anything
> and no
> >> one
> >> > noticed.
> >> > >>
> >> > >> So coverage is nothing without assertions (my opinion)
> ...
> >> ok ...
> >> > it's
> >> > >> slightly better than no coverage, but not much, in my
> >> opinion.
> >> > >>
> >> > >> I think in parallel to this release discussions I have
> seen
> >> numerous
> >> > >> threads about someone doing something that broke
> something
> >> for
> >> > someone
> >> > >> else. This could be addressed by increasing coverage by
> >> providing
> >> > explicit
> >> > >> tests.
> >> > >>
> >> > >> Coming back to the releases:
> >> > >> I have no objections, if you do a "release" locally and
> >> automate the
> >> > >> validation on the CI server (Which effectively would
> be your
> >> > proposal to do
> >> > >> the first 12 steps on local hardware and the 13th on
> the CI
> >> > server). I even
> >> > >> think that's a good idea ... There could be one step
> for
> >> building a
> >> > release
> >> > >> from a given "git tag" for every build system and
> generic
> >> means to
> >> > compare
> >> > >> tar.gz and zips produced by any build system with that
> of
> >> another
> >> > (ideally
> >> > >> with better output than just a plain "true/false").
> This
> >> would even
> >> > help to
> >> > >> iron out the last potentially existing bumps out of
> the Maven
> >> > distribution.
> >> > >>
> >> > >> Chris
> >> > >>
> >> > >>
> >> > >>
> >> > >> Am 02.04.20, 07:59 schrieb "Alex Harui"
> >> <ah...@adobe.com.INVALID>:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> This is my attempt to explain what goes into a
> release
> >> in hopes
> >> > that
> >> > >> we can understand and agree on what our release
> process is.
> >> It
> >> > became
> >> > >> apparent in my reading of the wiki page with the new
> Maven
> >> steps
> >> > and in
> >> > >> talking with Harbs today that there are still many
> >> > misunderstandings about
> >> > >> what we do to create a release. I don't generally like
> >> writing
> >> > >> instructions in English because it is easy to be
> ambiguous.
> >> All of
> >> > the
> >> > >> steps that we use to create releases had been captured
> in Ant
> >> > scripts in a
> >> > >> much more explicit way, IMO, but I took the time to
> write
> >> them down
> >> > in
> >> > >> English here:
> >> > >>
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=CmDCiZpPK3iy6ZkSaOP3GQv2KBDIIW6VX%2FSf7az46HM%3D&reserved=0
> >> > >>
> >> > >> I did this quickly by scanning the CI steps, the
> new
> >> Maven
> >> > steps and
> >> > >> the Ant scripts used in prior releases so there could
> >> certainly be
> >> > mistakes
> >> > >> and missed steps. If I did my math right, the RM for
> 0.9.7
> >> will
> >> > have to
> >> > >> complete over 100 tasks (essentially, typing a
> command-line
> >> 100
> >> > times).
> >> > >> Future RMs, when we don't have to release build-tools,
> will
> >> have
> >> > about 92
> >> > >> steps. And I did not include voter verification
> checks the
> >> RM
> >> > should run
> >> > >> before opening a vote (verifying that the artifacts
> download
> >> and
> >> > match
> >> > >> their checksums, etc). As an RM, I run a bunch of
> tests on
> >> the RC
> >> > before
> >> > >> sending out the vote. Maybe we should add those to
> the task
> >> list.
> >> > >>
> >> > >> I think there has been confusion about the use of
> Ant in
> >> the
> >> > release
> >> > >> process. Because I was the RM for the first set of
> >> FlexJS/Royale
> >> > releases,
> >> > >> and I'm a lazy person who hates typing at the command
> line, I
> >> > created Ant
> >> > >> scripts to execute these 100 steps. But I agree that
> it is
> >> not a
> >> > >> requirement that other RMs must use the Ant scripts
> for these
> >> > commands. If
> >> > >> you are the RM and like typing, go ahead.
> >> > >>
> >> > >> Then we found out that other people couldn't get
> through
> >> this
> >> > task
> >> > >> list. I think the 3 people who tried were having
> trouble
> >> with Maven
> >> > >> uploads and downloads. So what I did was put the
> first 40
> >> steps or
> >> > so into
> >> > >> Jenkins jobs. And by doing that, Piotr was able to
> produce
> >> our last
> >> > >> release. And that also saves on manually typing
> commands.
> >> But
> >> > again,
> >> > >> going forward, the RM gets to choose how they want to
> >> execute these
> >> > steps.
> >> > >>
> >> > >> If you scan the set of steps, you'll see that
> "ant" is
> >> only in
> >> > there
> >> > >> once. I believe the recent threads have been about
> this
> >> single
> >> > command out
> >> > >> of the 100+ commands. This is why this has been so
> >> frustrating to
> >> > me. I
> >> > >> believe there is a solid technical reason for that one
> >> command: it
> >> > proves
> >> > >> that the build.xml files in the source packages can
> build the
> >> > .tar.gz that
> >> > >> are useful to NPM and IDE users who use Ant and want
> to test
> >> a
> >> > change.
> >> > >>
> >> > >> I think of it as code-coverage. If we had
> code-coverage
> >> tools,
> >> > we
> >> > >> would ask that the RM complete as much of the automated
> >> > code-coverage
> >> > >> testing as possible before posting the release for a
> vote.
> >> That one
> >> > >> command increases our code coverage by running the
> build.xml
> >> > files. We
> >> > >> should be always working to increase automated code
> coverage
> >> in the
> >> > RC.
> >> > >> Certainly for me as RM, I will gladly watch TV as the
> >> automated
> >> > tests run
> >> > >> because a failed RC means going back through many of
> the
> >> first 25
> >> > commands
> >> > >> again and wastes other people's time. Each RC is more
> >> emails to
> >> > read and
> >> > >> more time from the voters and testers.
> >> > >>
> >> > >> If there are other ways for the RM to get the same
> or
> >> better
> >> > code
> >> > >> coverage on the build.xml files before posting the RC,
> we can
> >> > discuss those
> >> > >> options.
> >> > >>
> >> > >> I am hopeful we can all agree on these simple
> principles:
> >> > Strive for
> >> > >> better code coverage and fewer failed RCs. Royale's
> main
> >> purpose
> >> > is to
> >> > >> save other people time. Let's do that in creating
> releases
> >> too.
> >> > >>
> >> > >> One issue that was brought up recently was whether
> it is
> >> a good
> >> > >> decision to have the RM test all of the build
> platforms we
> >> support.
> >> > >> Suppose we add some other build system support or more
> in the
> >> > future?
> >> > >> Again, the code coverage principle applies here, but
> also, I
> >> would
> >> > like us
> >> > >> to retain feature parity, and I also hope for as few
> RCs and
> >> votes
> >> > as
> >> > >> possible. So instead of having separate
> >> > votes/features/release-dates for
> >> > >> the Maven artifacts vs the Ant artifacts vs the
> >> SomeFutureBuildTech
> >> > >> artifacts, I think we should have one vote and keep
> them all
> >> in
> >> > sync. If
> >> > >> we do ever get around to monthly or bi-monthly
> releases, I
> >> think
> >> > separate
> >> > >> build platform releases would be too much work.
> >> > >>
> >> > >> But consider this thought I just had today: the RM
> >> doesn't
> >> > really
> >> > >> have to choose to do all 100 commands on a local
> machine or
> >> with Ant
> >> > >> scripts or do the first 40 via CI. The RM can
> actually pick
> >> and
> >> > choose
> >> > >> commands to run on the CI server. The CI Jenkins jobs
> are
> >> not a
> >> > >> separate/alternative release process, they are just
> another
> >> way of
> >> > >> executing the first 40 steps. Using CI jobs actually
> >> requires
> >> > additional
> >> > >> command-line cut-and-paste to push commits on the CI
> server
> >> and to
> >> > sign and
> >> > >> validate binaries locally, but that's the trade-off of
> not
> >> having to
> >> > >> configure your machine to successfully run all of the
> >> automated
> >> > tests and
> >> > >> build systems, and being able to run a command by
> filling in
> >> the
> >> > version
> >> > >> number and rc number and hitting the "ok" button
> instead of
> >> making
> >> > sure you
> >> > >> got the whole command typed in correctly.
> >> > >>
> >> > >> So, an RM can run the first 25 steps locally, then
> go
> >> the CI
> >> > server
> >> > >> and run what is now Jenkins Job
> "Royale_Release_Step_013"
> >> (no need
> >> > to run
> >> > >> the first 12) and it will run tasks 26 through 32, and
> if it
> >> is
> >> > successful,
> >> > >> then the RM has proven code coverage of the build.xml
> >> files. (If
> >> > the
> >> > >> resulting tar.gz and zips are not posted, then the RM
> should
> >> verify
> >> > that
> >> > >> they match the ones from Maven distribution). I would
> >> encourage
> >> > RMs to
> >> > >> also use the CI jobs that generate the emails to make
> sure
> >> the
> >> > subject and
> >> > >> content is correct and contains the usual instructions
> so we
> >> have
> >> > >> consistency. Maybe someday there will be CI jobs to
> do the
> >> last
> >> > 60+ steps
> >> > >> if that helps. We could add a Jenkins job that runs
> an Ant
> >> build
> >> > on RC
> >> > >> artifacts on dist.a.o as well.
> >> > >>
> >> > >> I would like you all to help maintain the list of
> 100
> >> steps and
> >> > other
> >> > >> documents related to the release process, and improve
> the CI
> >> jobs
> >> > and Ant
> >> > >> steps if it helps you be a more efficient RM. I am
> hopeful
> >> that
> >> > now that I
> >> > >> have hopefully explained our release process better,
> that we
> >> can
> >> > see that
> >> > >> these 100+ steps just have to be done in some way.
> The RM
> >> can
> >> > figure out
> >> > >> what way works best for them, but they must get
> through all
> >> of them.
> >> > >>
> >> > >> Thanks,
> >> > >> -Alex
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=S4kQzxX%2BCErVWgJ4Bk0HxX6RgjHyJH%2B9r6Rf3LC%2B0Ew%3D&reserved=0
> >> > >
> >> > >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=S4kQzxX%2BCErVWgJ4Bk0HxX6RgjHyJH%2B9r6Rf3LC%2B0Ew%3D&reserved=0
> >> >
> >> >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
> >> >
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Create new branch when creating a release (was Fwd: Royale
Releases)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Why should we have a different branch strategy than what Maven recommends?
On 4/13/20, 12:38 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
I think there's a misunderstanding about this. Now that you passed compiler
and reach typedefs, you can see we have commits in both repositories in
develop branch with version changes. So this morning, building from sources
is making me build 0.9.8 of compiler and typedefs. But people not working
in release should be agnostic of all that process, and we should still be
able to build 0.9.7-SNAPSHOT and commit to develop.
For that reason in this thread I was proposing to create branches from the
point where RM want to release, so people working on develop can continue
its work.
Right now my way to work is to not update develop with latest commits that
increase versions in compiler and typedefs
Thanks
El mié., 8 abr. 2020 a las 19:24, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> ok
>
> El mié., 8 abr. 2020 a las 19:05, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> When I get to step 14, a release branch will be cut. I'm still back on
>> step 2.
>>
>> -Alex
>>
>> On 4/8/20, 12:06 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> I think we didn't understand each other. In this thread I was asking
>> to
>> avoid the use of "develop" branch to do the release, instead use a new
>> branch (let's say we name it "release-process-0.9.7" and the RM can do
>> whatever he needs there. In that way, the rest of us are not affected.
>>
>> Right now in Royale-compiler we have 2 commits about releasing
>> build-tools,
>> that I want to avoid. Those in particular are not problematic, but
>> will be
>> the ones for compiler, typedefs and framework in case the release is
>> not
>> done quickly.
>>
>> The main problems in the way we do now:
>> - If release need to be aborted, will have lots of
>> "[maven-release-plugin]"
>> commits done and reverted.
>> - developers using the current snapshot will need to not update the
>> commits
>> with the new versions to continue building the snapshot that is used
>> in the
>> rest of repos.
>>
>> so steps 14,18 and 22 was not what I was referring to.
>>
>> Thanks
>>
>>
>> El vie., 3 abr. 2020 a las 6:38, Alex Harui (<aharui@adobe.com.invalid
>> >)
>> escribió:
>>
>> > Steps 14, 18, and 22 in [1] dictate the use of branches.
>> >
>> > [1]
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=CmDCiZpPK3iy6ZkSaOP3GQv2KBDIIW6VX%2FSf7az46HM%3D&reserved=0
>> >
>> > -Alex
>> >
>> > On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > sending this again, since it was missed in the other thread,
>> but is
>> > something not related.
>> >
>> > ---------- Forwarded message ---------
>> > De: Carlos Rovira <ca...@apache.org>
>> > Date: jue., 2 abr. 2020 a las 14:32
>> > Subject: Re: Royale Releases
>> > To: Apache Royale Development <de...@royale.apache.org>
>> >
>> >
>> > Hi,
>> >
>> > one thing I want to propose before other considerations:
>> >
>> > When starting work on a release, could we work on a new branch?
>> >
>> > so all commits go to that branch and when all is done then
>> merge to
>> > develop? I think that will generate less problems to people
>> working in
>> > develop branch since releases can be wrong or test can delay
>> some days,
>> > that means people can have versions updated while other parts
>> of the
>> > code
>> > still require old versions, so that generate confusion. Doing
>> all in a
>> > new
>> > branch and then merging after all votes passes, seems to me the
>> best
>> > way to
>> > keep safe users working on develop.
>> >
>> > Thanks
>> >
>> >
>> > El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
>> > carlosrovira@apache.org>)
>> > escribió:
>> >
>> > > Hi Alex,
>> > >
>> > > first, many thanks for the detailed email. I'll comment on
>> this
>> > later as I
>> > > have more time.
>> > >
>> > > For now, to add up a recent example on what Chris commented:
>> If you
>> > all
>> > > remember a week ago I was trying to use SVG Images in a blog
>> example
>> > that
>> > > was published 2 days ago. Nobody tried SVG Images before
>> building
>> > with
>> > > maven, I know that since maven was not properly configured
>> and using
>> > that
>> > > component from Maven was failing with an RTE. Probably we
>> have more
>> > things
>> > > not working the same way when build from Maven and Ant, and
>> that's
>> > > something that will need people using that code paths in test
>> > applications
>> > > (or in their own apps) to see if things works properly.
>> > >
>> > > I was recently introduced to "examples-integrationtest" by
>> Chris,
>> > that I
>> > > plan to use soon as I can. I think is a great idea, since you
>> get a
>> > Firefox
>> > > running test interface of the real use of some concrete
>> royale code.
>> > I
>> > > think passed until now unnoticed by all of us, and seems a
>> powerful
>> > tool.
>> > > There's already an example about FlexStore with some basic
>> > assertions.
>> > >
>> > > Again, thanks, and will comment on the rest later
>> > >
>> > > Carlos
>> > >
>> > >
>> > >
>> > >
>> > > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> > > christofer.dutz@c-ware.de>) escribió:
>> > >
>> > >> Hi Alex,
>> > >>
>> > >> just a point you are bringing up: "Code coverage".
>> > >>
>> > >> I strongly dislike the idea of "asjs" effectively being the
>> test
>> > for the
>> > >> compiler. The reasoning behind this is: yes you do get more
>> code
>> > covered,
>> > >> but only the happy-path (ideally) and even if things go
>> wrong, the
>> > end
>> > >> results aren't tested. Did add a module to asjs years ago
>> > >> ("examples-integrationtest") that deployed the examples in a
>> tomcat
>> > server
>> > >> then opens a Firefox browser and clicks through 2 of the
>> examples
>> > (I added
>> > >> two dummy tests as an example, but seems no one touched this
>> after
>> > me). I
>> > >> did this because I remember us working on asjs for weeks
>> without
>> > anyone
>> > >> noticing the compiler wasn't producing runnable code ...
>> same with
>> > the
>> > >> little unit-tests that are still run for every example, that
>> simply
>> > check
>> > >> if an output is generated, because we had a prolonged period
>> of
>> > time where
>> > >> we were all working on different parts, but for quite some
>> time the
>> > >> application compilation just didn't output anything and no
>> one
>> > noticed.
>> > >>
>> > >> So coverage is nothing without assertions (my opinion) ...
>> ok ...
>> > it's
>> > >> slightly better than no coverage, but not much, in my
>> opinion.
>> > >>
>> > >> I think in parallel to this release discussions I have seen
>> numerous
>> > >> threads about someone doing something that broke something
>> for
>> > someone
>> > >> else. This could be addressed by increasing coverage by
>> providing
>> > explicit
>> > >> tests.
>> > >>
>> > >> Coming back to the releases:
>> > >> I have no objections, if you do a "release" locally and
>> automate the
>> > >> validation on the CI server (Which effectively would be your
>> > proposal to do
>> > >> the first 12 steps on local hardware and the 13th on the CI
>> > server). I even
>> > >> think that's a good idea ... There could be one step for
>> building a
>> > release
>> > >> from a given "git tag" for every build system and generic
>> means to
>> > compare
>> > >> tar.gz and zips produced by any build system with that of
>> another
>> > (ideally
>> > >> with better output than just a plain "true/false"). This
>> would even
>> > help to
>> > >> iron out the last potentially existing bumps out of the Maven
>> > distribution.
>> > >>
>> > >> Chris
>> > >>
>> > >>
>> > >>
>> > >> Am 02.04.20, 07:59 schrieb "Alex Harui"
>> <ah...@adobe.com.INVALID>:
>> > >>
>> > >> Hi,
>> > >>
>> > >> This is my attempt to explain what goes into a release
>> in hopes
>> > that
>> > >> we can understand and agree on what our release process is.
>> It
>> > became
>> > >> apparent in my reading of the wiki page with the new Maven
>> steps
>> > and in
>> > >> talking with Harbs today that there are still many
>> > misunderstandings about
>> > >> what we do to create a release. I don't generally like
>> writing
>> > >> instructions in English because it is easy to be ambiguous.
>> All of
>> > the
>> > >> steps that we use to create releases had been captured in Ant
>> > scripts in a
>> > >> much more explicit way, IMO, but I took the time to write
>> them down
>> > in
>> > >> English here:
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=CmDCiZpPK3iy6ZkSaOP3GQv2KBDIIW6VX%2FSf7az46HM%3D&reserved=0
>> > >>
>> > >> I did this quickly by scanning the CI steps, the new
>> Maven
>> > steps and
>> > >> the Ant scripts used in prior releases so there could
>> certainly be
>> > mistakes
>> > >> and missed steps. If I did my math right, the RM for 0.9.7
>> will
>> > have to
>> > >> complete over 100 tasks (essentially, typing a command-line
>> 100
>> > times).
>> > >> Future RMs, when we don't have to release build-tools, will
>> have
>> > about 92
>> > >> steps. And I did not include voter verification checks the
>> RM
>> > should run
>> > >> before opening a vote (verifying that the artifacts download
>> and
>> > match
>> > >> their checksums, etc). As an RM, I run a bunch of tests on
>> the RC
>> > before
>> > >> sending out the vote. Maybe we should add those to the task
>> list.
>> > >>
>> > >> I think there has been confusion about the use of Ant in
>> the
>> > release
>> > >> process. Because I was the RM for the first set of
>> FlexJS/Royale
>> > releases,
>> > >> and I'm a lazy person who hates typing at the command line, I
>> > created Ant
>> > >> scripts to execute these 100 steps. But I agree that it is
>> not a
>> > >> requirement that other RMs must use the Ant scripts for these
>> > commands. If
>> > >> you are the RM and like typing, go ahead.
>> > >>
>> > >> Then we found out that other people couldn't get through
>> this
>> > task
>> > >> list. I think the 3 people who tried were having trouble
>> with Maven
>> > >> uploads and downloads. So what I did was put the first 40
>> steps or
>> > so into
>> > >> Jenkins jobs. And by doing that, Piotr was able to produce
>> our last
>> > >> release. And that also saves on manually typing commands.
>> But
>> > again,
>> > >> going forward, the RM gets to choose how they want to
>> execute these
>> > steps.
>> > >>
>> > >> If you scan the set of steps, you'll see that "ant" is
>> only in
>> > there
>> > >> once. I believe the recent threads have been about this
>> single
>> > command out
>> > >> of the 100+ commands. This is why this has been so
>> frustrating to
>> > me. I
>> > >> believe there is a solid technical reason for that one
>> command: it
>> > proves
>> > >> that the build.xml files in the source packages can build the
>> > .tar.gz that
>> > >> are useful to NPM and IDE users who use Ant and want to test
>> a
>> > change.
>> > >>
>> > >> I think of it as code-coverage. If we had code-coverage
>> tools,
>> > we
>> > >> would ask that the RM complete as much of the automated
>> > code-coverage
>> > >> testing as possible before posting the release for a vote.
>> That one
>> > >> command increases our code coverage by running the build.xml
>> > files. We
>> > >> should be always working to increase automated code coverage
>> in the
>> > RC.
>> > >> Certainly for me as RM, I will gladly watch TV as the
>> automated
>> > tests run
>> > >> because a failed RC means going back through many of the
>> first 25
>> > commands
>> > >> again and wastes other people's time. Each RC is more
>> emails to
>> > read and
>> > >> more time from the voters and testers.
>> > >>
>> > >> If there are other ways for the RM to get the same or
>> better
>> > code
>> > >> coverage on the build.xml files before posting the RC, we can
>> > discuss those
>> > >> options.
>> > >>
>> > >> I am hopeful we can all agree on these simple principles:
>> > Strive for
>> > >> better code coverage and fewer failed RCs. Royale's main
>> purpose
>> > is to
>> > >> save other people time. Let's do that in creating releases
>> too.
>> > >>
>> > >> One issue that was brought up recently was whether it is
>> a good
>> > >> decision to have the RM test all of the build platforms we
>> support.
>> > >> Suppose we add some other build system support or more in the
>> > future?
>> > >> Again, the code coverage principle applies here, but also, I
>> would
>> > like us
>> > >> to retain feature parity, and I also hope for as few RCs and
>> votes
>> > as
>> > >> possible. So instead of having separate
>> > votes/features/release-dates for
>> > >> the Maven artifacts vs the Ant artifacts vs the
>> SomeFutureBuildTech
>> > >> artifacts, I think we should have one vote and keep them all
>> in
>> > sync. If
>> > >> we do ever get around to monthly or bi-monthly releases, I
>> think
>> > separate
>> > >> build platform releases would be too much work.
>> > >>
>> > >> But consider this thought I just had today: the RM
>> doesn't
>> > really
>> > >> have to choose to do all 100 commands on a local machine or
>> with Ant
>> > >> scripts or do the first 40 via CI. The RM can actually pick
>> and
>> > choose
>> > >> commands to run on the CI server. The CI Jenkins jobs are
>> not a
>> > >> separate/alternative release process, they are just another
>> way of
>> > >> executing the first 40 steps. Using CI jobs actually
>> requires
>> > additional
>> > >> command-line cut-and-paste to push commits on the CI server
>> and to
>> > sign and
>> > >> validate binaries locally, but that's the trade-off of not
>> having to
>> > >> configure your machine to successfully run all of the
>> automated
>> > tests and
>> > >> build systems, and being able to run a command by filling in
>> the
>> > version
>> > >> number and rc number and hitting the "ok" button instead of
>> making
>> > sure you
>> > >> got the whole command typed in correctly.
>> > >>
>> > >> So, an RM can run the first 25 steps locally, then go
>> the CI
>> > server
>> > >> and run what is now Jenkins Job "Royale_Release_Step_013"
>> (no need
>> > to run
>> > >> the first 12) and it will run tasks 26 through 32, and if it
>> is
>> > successful,
>> > >> then the RM has proven code coverage of the build.xml
>> files. (If
>> > the
>> > >> resulting tar.gz and zips are not posted, then the RM should
>> verify
>> > that
>> > >> they match the ones from Maven distribution). I would
>> encourage
>> > RMs to
>> > >> also use the CI jobs that generate the emails to make sure
>> the
>> > subject and
>> > >> content is correct and contains the usual instructions so we
>> have
>> > >> consistency. Maybe someday there will be CI jobs to do the
>> last
>> > 60+ steps
>> > >> if that helps. We could add a Jenkins job that runs an Ant
>> build
>> > on RC
>> > >> artifacts on dist.a.o as well.
>> > >>
>> > >> I would like you all to help maintain the list of 100
>> steps and
>> > other
>> > >> documents related to the release process, and improve the CI
>> jobs
>> > and Ant
>> > >> steps if it helps you be a more efficient RM. I am hopeful
>> that
>> > now that I
>> > >> have hopefully explained our release process better, that we
>> can
>> > see that
>> > >> these 100+ steps just have to be done in some way. The RM
>> can
>> > figure out
>> > >> what way works best for them, but they must get through all
>> of them.
>> > >>
>> > >> Thanks,
>> > >> -Alex
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=S4kQzxX%2BCErVWgJ4Bk0HxX6RgjHyJH%2B9r6Rf3LC%2B0Ew%3D&reserved=0
>> > >
>> > >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175881081&sdata=S4kQzxX%2BCErVWgJ4Bk0HxX6RgjHyJH%2B9r6Rf3LC%2B0Ew%3D&reserved=0
>> >
>> >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0cb310f82acf4982a6a708d7df7dacc0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637223603175891042&sdata=tywciR1X07lTvQfpVrxURMU%2F1INOY5Ez66OPbAcvWFc%3D&reserved=0
Re: Create new branch when creating a release (was Fwd: Royale Releases)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I think there's a misunderstanding about this. Now that you passed compiler
and reach typedefs, you can see we have commits in both repositories in
develop branch with version changes. So this morning, building from sources
is making me build 0.9.8 of compiler and typedefs. But people not working
in release should be agnostic of all that process, and we should still be
able to build 0.9.7-SNAPSHOT and commit to develop.
For that reason in this thread I was proposing to create branches from the
point where RM want to release, so people working on develop can continue
its work.
Right now my way to work is to not update develop with latest commits that
increase versions in compiler and typedefs
Thanks
El mié., 8 abr. 2020 a las 19:24, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> ok
>
> El mié., 8 abr. 2020 a las 19:05, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> When I get to step 14, a release branch will be cut. I'm still back on
>> step 2.
>>
>> -Alex
>>
>> On 4/8/20, 12:06 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> I think we didn't understand each other. In this thread I was asking
>> to
>> avoid the use of "develop" branch to do the release, instead use a new
>> branch (let's say we name it "release-process-0.9.7" and the RM can do
>> whatever he needs there. In that way, the rest of us are not affected.
>>
>> Right now in Royale-compiler we have 2 commits about releasing
>> build-tools,
>> that I want to avoid. Those in particular are not problematic, but
>> will be
>> the ones for compiler, typedefs and framework in case the release is
>> not
>> done quickly.
>>
>> The main problems in the way we do now:
>> - If release need to be aborted, will have lots of
>> "[maven-release-plugin]"
>> commits done and reverted.
>> - developers using the current snapshot will need to not update the
>> commits
>> with the new versions to continue building the snapshot that is used
>> in the
>> rest of repos.
>>
>> so steps 14,18 and 22 was not what I was referring to.
>>
>> Thanks
>>
>>
>> El vie., 3 abr. 2020 a las 6:38, Alex Harui (<aharui@adobe.com.invalid
>> >)
>> escribió:
>>
>> > Steps 14, 18, and 22 in [1] dictate the use of branches.
>> >
>> > [1]
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=hufpaYBkpnkEQxnqBz2isA0FVc8uCniHibUc1klo41M%3D&reserved=0
>> >
>> > -Alex
>> >
>> > On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > sending this again, since it was missed in the other thread,
>> but is
>> > something not related.
>> >
>> > ---------- Forwarded message ---------
>> > De: Carlos Rovira <ca...@apache.org>
>> > Date: jue., 2 abr. 2020 a las 14:32
>> > Subject: Re: Royale Releases
>> > To: Apache Royale Development <de...@royale.apache.org>
>> >
>> >
>> > Hi,
>> >
>> > one thing I want to propose before other considerations:
>> >
>> > When starting work on a release, could we work on a new branch?
>> >
>> > so all commits go to that branch and when all is done then
>> merge to
>> > develop? I think that will generate less problems to people
>> working in
>> > develop branch since releases can be wrong or test can delay
>> some days,
>> > that means people can have versions updated while other parts
>> of the
>> > code
>> > still require old versions, so that generate confusion. Doing
>> all in a
>> > new
>> > branch and then merging after all votes passes, seems to me the
>> best
>> > way to
>> > keep safe users working on develop.
>> >
>> > Thanks
>> >
>> >
>> > El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
>> > carlosrovira@apache.org>)
>> > escribió:
>> >
>> > > Hi Alex,
>> > >
>> > > first, many thanks for the detailed email. I'll comment on
>> this
>> > later as I
>> > > have more time.
>> > >
>> > > For now, to add up a recent example on what Chris commented:
>> If you
>> > all
>> > > remember a week ago I was trying to use SVG Images in a blog
>> example
>> > that
>> > > was published 2 days ago. Nobody tried SVG Images before
>> building
>> > with
>> > > maven, I know that since maven was not properly configured
>> and using
>> > that
>> > > component from Maven was failing with an RTE. Probably we
>> have more
>> > things
>> > > not working the same way when build from Maven and Ant, and
>> that's
>> > > something that will need people using that code paths in test
>> > applications
>> > > (or in their own apps) to see if things works properly.
>> > >
>> > > I was recently introduced to "examples-integrationtest" by
>> Chris,
>> > that I
>> > > plan to use soon as I can. I think is a great idea, since you
>> get a
>> > Firefox
>> > > running test interface of the real use of some concrete
>> royale code.
>> > I
>> > > think passed until now unnoticed by all of us, and seems a
>> powerful
>> > tool.
>> > > There's already an example about FlexStore with some basic
>> > assertions.
>> > >
>> > > Again, thanks, and will comment on the rest later
>> > >
>> > > Carlos
>> > >
>> > >
>> > >
>> > >
>> > > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
>> > > christofer.dutz@c-ware.de>) escribió:
>> > >
>> > >> Hi Alex,
>> > >>
>> > >> just a point you are bringing up: "Code coverage".
>> > >>
>> > >> I strongly dislike the idea of "asjs" effectively being the
>> test
>> > for the
>> > >> compiler. The reasoning behind this is: yes you do get more
>> code
>> > covered,
>> > >> but only the happy-path (ideally) and even if things go
>> wrong, the
>> > end
>> > >> results aren't tested. Did add a module to asjs years ago
>> > >> ("examples-integrationtest") that deployed the examples in a
>> tomcat
>> > server
>> > >> then opens a Firefox browser and clicks through 2 of the
>> examples
>> > (I added
>> > >> two dummy tests as an example, but seems no one touched this
>> after
>> > me). I
>> > >> did this because I remember us working on asjs for weeks
>> without
>> > anyone
>> > >> noticing the compiler wasn't producing runnable code ...
>> same with
>> > the
>> > >> little unit-tests that are still run for every example, that
>> simply
>> > check
>> > >> if an output is generated, because we had a prolonged period
>> of
>> > time where
>> > >> we were all working on different parts, but for quite some
>> time the
>> > >> application compilation just didn't output anything and no
>> one
>> > noticed.
>> > >>
>> > >> So coverage is nothing without assertions (my opinion) ...
>> ok ...
>> > it's
>> > >> slightly better than no coverage, but not much, in my
>> opinion.
>> > >>
>> > >> I think in parallel to this release discussions I have seen
>> numerous
>> > >> threads about someone doing something that broke something
>> for
>> > someone
>> > >> else. This could be addressed by increasing coverage by
>> providing
>> > explicit
>> > >> tests.
>> > >>
>> > >> Coming back to the releases:
>> > >> I have no objections, if you do a "release" locally and
>> automate the
>> > >> validation on the CI server (Which effectively would be your
>> > proposal to do
>> > >> the first 12 steps on local hardware and the 13th on the CI
>> > server). I even
>> > >> think that's a good idea ... There could be one step for
>> building a
>> > release
>> > >> from a given "git tag" for every build system and generic
>> means to
>> > compare
>> > >> tar.gz and zips produced by any build system with that of
>> another
>> > (ideally
>> > >> with better output than just a plain "true/false"). This
>> would even
>> > help to
>> > >> iron out the last potentially existing bumps out of the Maven
>> > distribution.
>> > >>
>> > >> Chris
>> > >>
>> > >>
>> > >>
>> > >> Am 02.04.20, 07:59 schrieb "Alex Harui"
>> <ah...@adobe.com.INVALID>:
>> > >>
>> > >> Hi,
>> > >>
>> > >> This is my attempt to explain what goes into a release
>> in hopes
>> > that
>> > >> we can understand and agree on what our release process is.
>> It
>> > became
>> > >> apparent in my reading of the wiki page with the new Maven
>> steps
>> > and in
>> > >> talking with Harbs today that there are still many
>> > misunderstandings about
>> > >> what we do to create a release. I don't generally like
>> writing
>> > >> instructions in English because it is easy to be ambiguous.
>> All of
>> > the
>> > >> steps that we use to create releases had been captured in Ant
>> > scripts in a
>> > >> much more explicit way, IMO, but I took the time to write
>> them down
>> > in
>> > >> English here:
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=hufpaYBkpnkEQxnqBz2isA0FVc8uCniHibUc1klo41M%3D&reserved=0
>> > >>
>> > >> I did this quickly by scanning the CI steps, the new
>> Maven
>> > steps and
>> > >> the Ant scripts used in prior releases so there could
>> certainly be
>> > mistakes
>> > >> and missed steps. If I did my math right, the RM for 0.9.7
>> will
>> > have to
>> > >> complete over 100 tasks (essentially, typing a command-line
>> 100
>> > times).
>> > >> Future RMs, when we don't have to release build-tools, will
>> have
>> > about 92
>> > >> steps. And I did not include voter verification checks the
>> RM
>> > should run
>> > >> before opening a vote (verifying that the artifacts download
>> and
>> > match
>> > >> their checksums, etc). As an RM, I run a bunch of tests on
>> the RC
>> > before
>> > >> sending out the vote. Maybe we should add those to the task
>> list.
>> > >>
>> > >> I think there has been confusion about the use of Ant in
>> the
>> > release
>> > >> process. Because I was the RM for the first set of
>> FlexJS/Royale
>> > releases,
>> > >> and I'm a lazy person who hates typing at the command line, I
>> > created Ant
>> > >> scripts to execute these 100 steps. But I agree that it is
>> not a
>> > >> requirement that other RMs must use the Ant scripts for these
>> > commands. If
>> > >> you are the RM and like typing, go ahead.
>> > >>
>> > >> Then we found out that other people couldn't get through
>> this
>> > task
>> > >> list. I think the 3 people who tried were having trouble
>> with Maven
>> > >> uploads and downloads. So what I did was put the first 40
>> steps or
>> > so into
>> > >> Jenkins jobs. And by doing that, Piotr was able to produce
>> our last
>> > >> release. And that also saves on manually typing commands.
>> But
>> > again,
>> > >> going forward, the RM gets to choose how they want to
>> execute these
>> > steps.
>> > >>
>> > >> If you scan the set of steps, you'll see that "ant" is
>> only in
>> > there
>> > >> once. I believe the recent threads have been about this
>> single
>> > command out
>> > >> of the 100+ commands. This is why this has been so
>> frustrating to
>> > me. I
>> > >> believe there is a solid technical reason for that one
>> command: it
>> > proves
>> > >> that the build.xml files in the source packages can build the
>> > .tar.gz that
>> > >> are useful to NPM and IDE users who use Ant and want to test
>> a
>> > change.
>> > >>
>> > >> I think of it as code-coverage. If we had code-coverage
>> tools,
>> > we
>> > >> would ask that the RM complete as much of the automated
>> > code-coverage
>> > >> testing as possible before posting the release for a vote.
>> That one
>> > >> command increases our code coverage by running the build.xml
>> > files. We
>> > >> should be always working to increase automated code coverage
>> in the
>> > RC.
>> > >> Certainly for me as RM, I will gladly watch TV as the
>> automated
>> > tests run
>> > >> because a failed RC means going back through many of the
>> first 25
>> > commands
>> > >> again and wastes other people's time. Each RC is more
>> emails to
>> > read and
>> > >> more time from the voters and testers.
>> > >>
>> > >> If there are other ways for the RM to get the same or
>> better
>> > code
>> > >> coverage on the build.xml files before posting the RC, we can
>> > discuss those
>> > >> options.
>> > >>
>> > >> I am hopeful we can all agree on these simple principles:
>> > Strive for
>> > >> better code coverage and fewer failed RCs. Royale's main
>> purpose
>> > is to
>> > >> save other people time. Let's do that in creating releases
>> too.
>> > >>
>> > >> One issue that was brought up recently was whether it is
>> a good
>> > >> decision to have the RM test all of the build platforms we
>> support.
>> > >> Suppose we add some other build system support or more in the
>> > future?
>> > >> Again, the code coverage principle applies here, but also, I
>> would
>> > like us
>> > >> to retain feature parity, and I also hope for as few RCs and
>> votes
>> > as
>> > >> possible. So instead of having separate
>> > votes/features/release-dates for
>> > >> the Maven artifacts vs the Ant artifacts vs the
>> SomeFutureBuildTech
>> > >> artifacts, I think we should have one vote and keep them all
>> in
>> > sync. If
>> > >> we do ever get around to monthly or bi-monthly releases, I
>> think
>> > separate
>> > >> build platform releases would be too much work.
>> > >>
>> > >> But consider this thought I just had today: the RM
>> doesn't
>> > really
>> > >> have to choose to do all 100 commands on a local machine or
>> with Ant
>> > >> scripts or do the first 40 via CI. The RM can actually pick
>> and
>> > choose
>> > >> commands to run on the CI server. The CI Jenkins jobs are
>> not a
>> > >> separate/alternative release process, they are just another
>> way of
>> > >> executing the first 40 steps. Using CI jobs actually
>> requires
>> > additional
>> > >> command-line cut-and-paste to push commits on the CI server
>> and to
>> > sign and
>> > >> validate binaries locally, but that's the trade-off of not
>> having to
>> > >> configure your machine to successfully run all of the
>> automated
>> > tests and
>> > >> build systems, and being able to run a command by filling in
>> the
>> > version
>> > >> number and rc number and hitting the "ok" button instead of
>> making
>> > sure you
>> > >> got the whole command typed in correctly.
>> > >>
>> > >> So, an RM can run the first 25 steps locally, then go
>> the CI
>> > server
>> > >> and run what is now Jenkins Job "Royale_Release_Step_013"
>> (no need
>> > to run
>> > >> the first 12) and it will run tasks 26 through 32, and if it
>> is
>> > successful,
>> > >> then the RM has proven code coverage of the build.xml
>> files. (If
>> > the
>> > >> resulting tar.gz and zips are not posted, then the RM should
>> verify
>> > that
>> > >> they match the ones from Maven distribution). I would
>> encourage
>> > RMs to
>> > >> also use the CI jobs that generate the emails to make sure
>> the
>> > subject and
>> > >> content is correct and contains the usual instructions so we
>> have
>> > >> consistency. Maybe someday there will be CI jobs to do the
>> last
>> > 60+ steps
>> > >> if that helps. We could add a Jenkins job that runs an Ant
>> build
>> > on RC
>> > >> artifacts on dist.a.o as well.
>> > >>
>> > >> I would like you all to help maintain the list of 100
>> steps and
>> > other
>> > >> documents related to the release process, and improve the CI
>> jobs
>> > and Ant
>> > >> steps if it helps you be a more efficient RM. I am hopeful
>> that
>> > now that I
>> > >> have hopefully explained our release process better, that we
>> can
>> > see that
>> > >> these 100+ steps just have to be done in some way. The RM
>> can
>> > figure out
>> > >> what way works best for them, but they must get through all
>> of them.
>> > >>
>> > >> Thanks,
>> > >> -Alex
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=4d0pf2RP7oEPlHrIqzjojFnx3w%2F4P2r9%2FnUMqXwZDJM%3D&reserved=0
>> > >
>> > >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
>> >
>> >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Create new branch when creating a release (was Fwd: Royale Releases)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
ok
El mié., 8 abr. 2020 a las 19:05, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> When I get to step 14, a release branch will be cut. I'm still back on
> step 2.
>
> -Alex
>
> On 4/8/20, 12:06 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I think we didn't understand each other. In this thread I was asking to
> avoid the use of "develop" branch to do the release, instead use a new
> branch (let's say we name it "release-process-0.9.7" and the RM can do
> whatever he needs there. In that way, the rest of us are not affected.
>
> Right now in Royale-compiler we have 2 commits about releasing
> build-tools,
> that I want to avoid. Those in particular are not problematic, but
> will be
> the ones for compiler, typedefs and framework in case the release is
> not
> done quickly.
>
> The main problems in the way we do now:
> - If release need to be aborted, will have lots of
> "[maven-release-plugin]"
> commits done and reverted.
> - developers using the current snapshot will need to not update the
> commits
> with the new versions to continue building the snapshot that is used
> in the
> rest of repos.
>
> so steps 14,18 and 22 was not what I was referring to.
>
> Thanks
>
>
> El vie., 3 abr. 2020 a las 6:38, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > Steps 14, 18, and 22 in [1] dictate the use of branches.
> >
> > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=hufpaYBkpnkEQxnqBz2isA0FVc8uCniHibUc1klo41M%3D&reserved=0
> >
> > -Alex
> >
> > On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi,
> >
> > sending this again, since it was missed in the other thread, but
> is
> > something not related.
> >
> > ---------- Forwarded message ---------
> > De: Carlos Rovira <ca...@apache.org>
> > Date: jue., 2 abr. 2020 a las 14:32
> > Subject: Re: Royale Releases
> > To: Apache Royale Development <de...@royale.apache.org>
> >
> >
> > Hi,
> >
> > one thing I want to propose before other considerations:
> >
> > When starting work on a release, could we work on a new branch?
> >
> > so all commits go to that branch and when all is done then merge
> to
> > develop? I think that will generate less problems to people
> working in
> > develop branch since releases can be wrong or test can delay
> some days,
> > that means people can have versions updated while other parts of
> the
> > code
> > still require old versions, so that generate confusion. Doing
> all in a
> > new
> > branch and then merging after all votes passes, seems to me the
> best
> > way to
> > keep safe users working on develop.
> >
> > Thanks
> >
> >
> > El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
> > carlosrovira@apache.org>)
> > escribió:
> >
> > > Hi Alex,
> > >
> > > first, many thanks for the detailed email. I'll comment on this
> > later as I
> > > have more time.
> > >
> > > For now, to add up a recent example on what Chris commented:
> If you
> > all
> > > remember a week ago I was trying to use SVG Images in a blog
> example
> > that
> > > was published 2 days ago. Nobody tried SVG Images before
> building
> > with
> > > maven, I know that since maven was not properly configured and
> using
> > that
> > > component from Maven was failing with an RTE. Probably we have
> more
> > things
> > > not working the same way when build from Maven and Ant, and
> that's
> > > something that will need people using that code paths in test
> > applications
> > > (or in their own apps) to see if things works properly.
> > >
> > > I was recently introduced to "examples-integrationtest" by
> Chris,
> > that I
> > > plan to use soon as I can. I think is a great idea, since you
> get a
> > Firefox
> > > running test interface of the real use of some concrete royale
> code.
> > I
> > > think passed until now unnoticed by all of us, and seems a
> powerful
> > tool.
> > > There's already an example about FlexStore with some basic
> > assertions.
> > >
> > > Again, thanks, and will comment on the rest later
> > >
> > > Carlos
> > >
> > >
> > >
> > >
> > > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > > christofer.dutz@c-ware.de>) escribió:
> > >
> > >> Hi Alex,
> > >>
> > >> just a point you are bringing up: "Code coverage".
> > >>
> > >> I strongly dislike the idea of "asjs" effectively being the
> test
> > for the
> > >> compiler. The reasoning behind this is: yes you do get more
> code
> > covered,
> > >> but only the happy-path (ideally) and even if things go
> wrong, the
> > end
> > >> results aren't tested. Did add a module to asjs years ago
> > >> ("examples-integrationtest") that deployed the examples in a
> tomcat
> > server
> > >> then opens a Firefox browser and clicks through 2 of the
> examples
> > (I added
> > >> two dummy tests as an example, but seems no one touched this
> after
> > me). I
> > >> did this because I remember us working on asjs for weeks
> without
> > anyone
> > >> noticing the compiler wasn't producing runnable code ... same
> with
> > the
> > >> little unit-tests that are still run for every example, that
> simply
> > check
> > >> if an output is generated, because we had a prolonged period
> of
> > time where
> > >> we were all working on different parts, but for quite some
> time the
> > >> application compilation just didn't output anything and no one
> > noticed.
> > >>
> > >> So coverage is nothing without assertions (my opinion) ... ok
> ...
> > it's
> > >> slightly better than no coverage, but not much, in my opinion.
> > >>
> > >> I think in parallel to this release discussions I have seen
> numerous
> > >> threads about someone doing something that broke something for
> > someone
> > >> else. This could be addressed by increasing coverage by
> providing
> > explicit
> > >> tests.
> > >>
> > >> Coming back to the releases:
> > >> I have no objections, if you do a "release" locally and
> automate the
> > >> validation on the CI server (Which effectively would be your
> > proposal to do
> > >> the first 12 steps on local hardware and the 13th on the CI
> > server). I even
> > >> think that's a good idea ... There could be one step for
> building a
> > release
> > >> from a given "git tag" for every build system and generic
> means to
> > compare
> > >> tar.gz and zips produced by any build system with that of
> another
> > (ideally
> > >> with better output than just a plain "true/false"). This
> would even
> > help to
> > >> iron out the last potentially existing bumps out of the Maven
> > distribution.
> > >>
> > >> Chris
> > >>
> > >>
> > >>
> > >> Am 02.04.20, 07:59 schrieb "Alex Harui"
> <ah...@adobe.com.INVALID>:
> > >>
> > >> Hi,
> > >>
> > >> This is my attempt to explain what goes into a release in
> hopes
> > that
> > >> we can understand and agree on what our release process is.
> It
> > became
> > >> apparent in my reading of the wiki page with the new Maven
> steps
> > and in
> > >> talking with Harbs today that there are still many
> > misunderstandings about
> > >> what we do to create a release. I don't generally like
> writing
> > >> instructions in English because it is easy to be ambiguous.
> All of
> > the
> > >> steps that we use to create releases had been captured in Ant
> > scripts in a
> > >> much more explicit way, IMO, but I took the time to write
> them down
> > in
> > >> English here:
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=hufpaYBkpnkEQxnqBz2isA0FVc8uCniHibUc1klo41M%3D&reserved=0
> > >>
> > >> I did this quickly by scanning the CI steps, the new Maven
> > steps and
> > >> the Ant scripts used in prior releases so there could
> certainly be
> > mistakes
> > >> and missed steps. If I did my math right, the RM for 0.9.7
> will
> > have to
> > >> complete over 100 tasks (essentially, typing a command-line
> 100
> > times).
> > >> Future RMs, when we don't have to release build-tools, will
> have
> > about 92
> > >> steps. And I did not include voter verification checks the RM
> > should run
> > >> before opening a vote (verifying that the artifacts download
> and
> > match
> > >> their checksums, etc). As an RM, I run a bunch of tests on
> the RC
> > before
> > >> sending out the vote. Maybe we should add those to the task
> list.
> > >>
> > >> I think there has been confusion about the use of Ant in
> the
> > release
> > >> process. Because I was the RM for the first set of
> FlexJS/Royale
> > releases,
> > >> and I'm a lazy person who hates typing at the command line, I
> > created Ant
> > >> scripts to execute these 100 steps. But I agree that it is
> not a
> > >> requirement that other RMs must use the Ant scripts for these
> > commands. If
> > >> you are the RM and like typing, go ahead.
> > >>
> > >> Then we found out that other people couldn't get through
> this
> > task
> > >> list. I think the 3 people who tried were having trouble
> with Maven
> > >> uploads and downloads. So what I did was put the first 40
> steps or
> > so into
> > >> Jenkins jobs. And by doing that, Piotr was able to produce
> our last
> > >> release. And that also saves on manually typing commands.
> But
> > again,
> > >> going forward, the RM gets to choose how they want to execute
> these
> > steps.
> > >>
> > >> If you scan the set of steps, you'll see that "ant" is
> only in
> > there
> > >> once. I believe the recent threads have been about this
> single
> > command out
> > >> of the 100+ commands. This is why this has been so
> frustrating to
> > me. I
> > >> believe there is a solid technical reason for that one
> command: it
> > proves
> > >> that the build.xml files in the source packages can build the
> > .tar.gz that
> > >> are useful to NPM and IDE users who use Ant and want to test a
> > change.
> > >>
> > >> I think of it as code-coverage. If we had code-coverage
> tools,
> > we
> > >> would ask that the RM complete as much of the automated
> > code-coverage
> > >> testing as possible before posting the release for a vote.
> That one
> > >> command increases our code coverage by running the build.xml
> > files. We
> > >> should be always working to increase automated code coverage
> in the
> > RC.
> > >> Certainly for me as RM, I will gladly watch TV as the
> automated
> > tests run
> > >> because a failed RC means going back through many of the
> first 25
> > commands
> > >> again and wastes other people's time. Each RC is more emails
> to
> > read and
> > >> more time from the voters and testers.
> > >>
> > >> If there are other ways for the RM to get the same or
> better
> > code
> > >> coverage on the build.xml files before posting the RC, we can
> > discuss those
> > >> options.
> > >>
> > >> I am hopeful we can all agree on these simple principles:
> > Strive for
> > >> better code coverage and fewer failed RCs. Royale's main
> purpose
> > is to
> > >> save other people time. Let's do that in creating releases
> too.
> > >>
> > >> One issue that was brought up recently was whether it is
> a good
> > >> decision to have the RM test all of the build platforms we
> support.
> > >> Suppose we add some other build system support or more in the
> > future?
> > >> Again, the code coverage principle applies here, but also, I
> would
> > like us
> > >> to retain feature parity, and I also hope for as few RCs and
> votes
> > as
> > >> possible. So instead of having separate
> > votes/features/release-dates for
> > >> the Maven artifacts vs the Ant artifacts vs the
> SomeFutureBuildTech
> > >> artifacts, I think we should have one vote and keep them all
> in
> > sync. If
> > >> we do ever get around to monthly or bi-monthly releases, I
> think
> > separate
> > >> build platform releases would be too much work.
> > >>
> > >> But consider this thought I just had today: the RM
> doesn't
> > really
> > >> have to choose to do all 100 commands on a local machine or
> with Ant
> > >> scripts or do the first 40 via CI. The RM can actually pick
> and
> > choose
> > >> commands to run on the CI server. The CI Jenkins jobs are
> not a
> > >> separate/alternative release process, they are just another
> way of
> > >> executing the first 40 steps. Using CI jobs actually requires
> > additional
> > >> command-line cut-and-paste to push commits on the CI server
> and to
> > sign and
> > >> validate binaries locally, but that's the trade-off of not
> having to
> > >> configure your machine to successfully run all of the
> automated
> > tests and
> > >> build systems, and being able to run a command by filling in
> the
> > version
> > >> number and rc number and hitting the "ok" button instead of
> making
> > sure you
> > >> got the whole command typed in correctly.
> > >>
> > >> So, an RM can run the first 25 steps locally, then go the
> CI
> > server
> > >> and run what is now Jenkins Job "Royale_Release_Step_013" (no
> need
> > to run
> > >> the first 12) and it will run tasks 26 through 32, and if it
> is
> > successful,
> > >> then the RM has proven code coverage of the build.xml files.
> (If
> > the
> > >> resulting tar.gz and zips are not posted, then the RM should
> verify
> > that
> > >> they match the ones from Maven distribution). I would
> encourage
> > RMs to
> > >> also use the CI jobs that generate the emails to make sure the
> > subject and
> > >> content is correct and contains the usual instructions so we
> have
> > >> consistency. Maybe someday there will be CI jobs to do the
> last
> > 60+ steps
> > >> if that helps. We could add a Jenkins job that runs an Ant
> build
> > on RC
> > >> artifacts on dist.a.o as well.
> > >>
> > >> I would like you all to help maintain the list of 100
> steps and
> > other
> > >> documents related to the release process, and improve the CI
> jobs
> > and Ant
> > >> steps if it helps you be a more efficient RM. I am hopeful
> that
> > now that I
> > >> have hopefully explained our release process better, that we
> can
> > see that
> > >> these 100+ steps just have to be done in some way. The RM can
> > figure out
> > >> what way works best for them, but they must get through all
> of them.
> > >>
> > >> Thanks,
> > >> -Alex
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=4d0pf2RP7oEPlHrIqzjojFnx3w%2F4P2r9%2FnUMqXwZDJM%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
> >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Create new branch when creating a release (was Fwd: Royale
Releases)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
When I get to step 14, a release branch will be cut. I'm still back on step 2.
-Alex
On 4/8/20, 12:06 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
I think we didn't understand each other. In this thread I was asking to
avoid the use of "develop" branch to do the release, instead use a new
branch (let's say we name it "release-process-0.9.7" and the RM can do
whatever he needs there. In that way, the rest of us are not affected.
Right now in Royale-compiler we have 2 commits about releasing build-tools,
that I want to avoid. Those in particular are not problematic, but will be
the ones for compiler, typedefs and framework in case the release is not
done quickly.
The main problems in the way we do now:
- If release need to be aborted, will have lots of "[maven-release-plugin]"
commits done and reverted.
- developers using the current snapshot will need to not update the commits
with the new versions to continue building the snapshot that is used in the
rest of repos.
so steps 14,18 and 22 was not what I was referring to.
Thanks
El vie., 3 abr. 2020 a las 6:38, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Steps 14, 18, and 22 in [1] dictate the use of branches.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=hufpaYBkpnkEQxnqBz2isA0FVc8uCniHibUc1klo41M%3D&reserved=0
>
> -Alex
>
> On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> sending this again, since it was missed in the other thread, but is
> something not related.
>
> ---------- Forwarded message ---------
> De: Carlos Rovira <ca...@apache.org>
> Date: jue., 2 abr. 2020 a las 14:32
> Subject: Re: Royale Releases
> To: Apache Royale Development <de...@royale.apache.org>
>
>
> Hi,
>
> one thing I want to propose before other considerations:
>
> When starting work on a release, could we work on a new branch?
>
> so all commits go to that branch and when all is done then merge to
> develop? I think that will generate less problems to people working in
> develop branch since releases can be wrong or test can delay some days,
> that means people can have versions updated while other parts of the
> code
> still require old versions, so that generate confusion. Doing all in a
> new
> branch and then merging after all votes passes, seems to me the best
> way to
> keep safe users working on develop.
>
> Thanks
>
>
> El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > first, many thanks for the detailed email. I'll comment on this
> later as I
> > have more time.
> >
> > For now, to add up a recent example on what Chris commented: If you
> all
> > remember a week ago I was trying to use SVG Images in a blog example
> that
> > was published 2 days ago. Nobody tried SVG Images before building
> with
> > maven, I know that since maven was not properly configured and using
> that
> > component from Maven was failing with an RTE. Probably we have more
> things
> > not working the same way when build from Maven and Ant, and that's
> > something that will need people using that code paths in test
> applications
> > (or in their own apps) to see if things works properly.
> >
> > I was recently introduced to "examples-integrationtest" by Chris,
> that I
> > plan to use soon as I can. I think is a great idea, since you get a
> Firefox
> > running test interface of the real use of some concrete royale code.
> I
> > think passed until now unnoticed by all of us, and seems a powerful
> tool.
> > There's already an example about FlexStore with some basic
> assertions.
> >
> > Again, thanks, and will comment on the rest later
> >
> > Carlos
> >
> >
> >
> >
> > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > christofer.dutz@c-ware.de>) escribió:
> >
> >> Hi Alex,
> >>
> >> just a point you are bringing up: "Code coverage".
> >>
> >> I strongly dislike the idea of "asjs" effectively being the test
> for the
> >> compiler. The reasoning behind this is: yes you do get more code
> covered,
> >> but only the happy-path (ideally) and even if things go wrong, the
> end
> >> results aren't tested. Did add a module to asjs years ago
> >> ("examples-integrationtest") that deployed the examples in a tomcat
> server
> >> then opens a Firefox browser and clicks through 2 of the examples
> (I added
> >> two dummy tests as an example, but seems no one touched this after
> me). I
> >> did this because I remember us working on asjs for weeks without
> anyone
> >> noticing the compiler wasn't producing runnable code ... same with
> the
> >> little unit-tests that are still run for every example, that simply
> check
> >> if an output is generated, because we had a prolonged period of
> time where
> >> we were all working on different parts, but for quite some time the
> >> application compilation just didn't output anything and no one
> noticed.
> >>
> >> So coverage is nothing without assertions (my opinion) ... ok ...
> it's
> >> slightly better than no coverage, but not much, in my opinion.
> >>
> >> I think in parallel to this release discussions I have seen numerous
> >> threads about someone doing something that broke something for
> someone
> >> else. This could be addressed by increasing coverage by providing
> explicit
> >> tests.
> >>
> >> Coming back to the releases:
> >> I have no objections, if you do a "release" locally and automate the
> >> validation on the CI server (Which effectively would be your
> proposal to do
> >> the first 12 steps on local hardware and the 13th on the CI
> server). I even
> >> think that's a good idea ... There could be one step for building a
> release
> >> from a given "git tag" for every build system and generic means to
> compare
> >> tar.gz and zips produced by any build system with that of another
> (ideally
> >> with better output than just a plain "true/false"). This would even
> help to
> >> iron out the last potentially existing bumps out of the Maven
> distribution.
> >>
> >> Chris
> >>
> >>
> >>
> >> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>
> >> Hi,
> >>
> >> This is my attempt to explain what goes into a release in hopes
> that
> >> we can understand and agree on what our release process is. It
> became
> >> apparent in my reading of the wiki page with the new Maven steps
> and in
> >> talking with Harbs today that there are still many
> misunderstandings about
> >> what we do to create a release. I don't generally like writing
> >> instructions in English because it is easy to be ambiguous. All of
> the
> >> steps that we use to create releases had been captured in Ant
> scripts in a
> >> much more explicit way, IMO, but I took the time to write them down
> in
> >> English here:
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=hufpaYBkpnkEQxnqBz2isA0FVc8uCniHibUc1klo41M%3D&reserved=0
> >>
> >> I did this quickly by scanning the CI steps, the new Maven
> steps and
> >> the Ant scripts used in prior releases so there could certainly be
> mistakes
> >> and missed steps. If I did my math right, the RM for 0.9.7 will
> have to
> >> complete over 100 tasks (essentially, typing a command-line 100
> times).
> >> Future RMs, when we don't have to release build-tools, will have
> about 92
> >> steps. And I did not include voter verification checks the RM
> should run
> >> before opening a vote (verifying that the artifacts download and
> match
> >> their checksums, etc). As an RM, I run a bunch of tests on the RC
> before
> >> sending out the vote. Maybe we should add those to the task list.
> >>
> >> I think there has been confusion about the use of Ant in the
> release
> >> process. Because I was the RM for the first set of FlexJS/Royale
> releases,
> >> and I'm a lazy person who hates typing at the command line, I
> created Ant
> >> scripts to execute these 100 steps. But I agree that it is not a
> >> requirement that other RMs must use the Ant scripts for these
> commands. If
> >> you are the RM and like typing, go ahead.
> >>
> >> Then we found out that other people couldn't get through this
> task
> >> list. I think the 3 people who tried were having trouble with Maven
> >> uploads and downloads. So what I did was put the first 40 steps or
> so into
> >> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >> release. And that also saves on manually typing commands. But
> again,
> >> going forward, the RM gets to choose how they want to execute these
> steps.
> >>
> >> If you scan the set of steps, you'll see that "ant" is only in
> there
> >> once. I believe the recent threads have been about this single
> command out
> >> of the 100+ commands. This is why this has been so frustrating to
> me. I
> >> believe there is a solid technical reason for that one command: it
> proves
> >> that the build.xml files in the source packages can build the
> .tar.gz that
> >> are useful to NPM and IDE users who use Ant and want to test a
> change.
> >>
> >> I think of it as code-coverage. If we had code-coverage tools,
> we
> >> would ask that the RM complete as much of the automated
> code-coverage
> >> testing as possible before posting the release for a vote. That one
> >> command increases our code coverage by running the build.xml
> files. We
> >> should be always working to increase automated code coverage in the
> RC.
> >> Certainly for me as RM, I will gladly watch TV as the automated
> tests run
> >> because a failed RC means going back through many of the first 25
> commands
> >> again and wastes other people's time. Each RC is more emails to
> read and
> >> more time from the voters and testers.
> >>
> >> If there are other ways for the RM to get the same or better
> code
> >> coverage on the build.xml files before posting the RC, we can
> discuss those
> >> options.
> >>
> >> I am hopeful we can all agree on these simple principles:
> Strive for
> >> better code coverage and fewer failed RCs. Royale's main purpose
> is to
> >> save other people time. Let's do that in creating releases too.
> >>
> >> One issue that was brought up recently was whether it is a good
> >> decision to have the RM test all of the build platforms we support.
> >> Suppose we add some other build system support or more in the
> future?
> >> Again, the code coverage principle applies here, but also, I would
> like us
> >> to retain feature parity, and I also hope for as few RCs and votes
> as
> >> possible. So instead of having separate
> votes/features/release-dates for
> >> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >> artifacts, I think we should have one vote and keep them all in
> sync. If
> >> we do ever get around to monthly or bi-monthly releases, I think
> separate
> >> build platform releases would be too much work.
> >>
> >> But consider this thought I just had today: the RM doesn't
> really
> >> have to choose to do all 100 commands on a local machine or with Ant
> >> scripts or do the first 40 via CI. The RM can actually pick and
> choose
> >> commands to run on the CI server. The CI Jenkins jobs are not a
> >> separate/alternative release process, they are just another way of
> >> executing the first 40 steps. Using CI jobs actually requires
> additional
> >> command-line cut-and-paste to push commits on the CI server and to
> sign and
> >> validate binaries locally, but that's the trade-off of not having to
> >> configure your machine to successfully run all of the automated
> tests and
> >> build systems, and being able to run a command by filling in the
> version
> >> number and rc number and hitting the "ok" button instead of making
> sure you
> >> got the whole command typed in correctly.
> >>
> >> So, an RM can run the first 25 steps locally, then go the CI
> server
> >> and run what is now Jenkins Job "Royale_Release_Step_013" (no need
> to run
> >> the first 12) and it will run tasks 26 through 32, and if it is
> successful,
> >> then the RM has proven code coverage of the build.xml files. (If
> the
> >> resulting tar.gz and zips are not posted, then the RM should verify
> that
> >> they match the ones from Maven distribution). I would encourage
> RMs to
> >> also use the CI jobs that generate the emails to make sure the
> subject and
> >> content is correct and contains the usual instructions so we have
> >> consistency. Maybe someday there will be CI jobs to do the last
> 60+ steps
> >> if that helps. We could add a Jenkins job that runs an Ant build
> on RC
> >> artifacts on dist.a.o as well.
> >>
> >> I would like you all to help maintain the list of 100 steps and
> other
> >> documents related to the release process, and improve the CI jobs
> and Ant
> >> steps if it helps you be a more efficient RM. I am hopeful that
> now that I
> >> have hopefully explained our release process better, that we can
> see that
> >> these 100+ steps just have to be done in some way. The RM can
> figure out
> >> what way works best for them, but they must get through all of them.
> >>
> >> Thanks,
> >> -Alex
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170137667&sdata=4d0pf2RP7oEPlHrIqzjojFnx3w%2F4P2r9%2FnUMqXwZDJM%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
>
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce3f8cd14da574441d9bd08d7db8b6a31%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637219264170147659&sdata=%2FRKEtzh2Hc92m%2B6TDoAVuTmlZ%2BlNsYHHgP%2Bp%2Bh3NaGI%3D&reserved=0
Re: Create new branch when creating a release (was Fwd: Royale Releases)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I think we didn't understand each other. In this thread I was asking to
avoid the use of "develop" branch to do the release, instead use a new
branch (let's say we name it "release-process-0.9.7" and the RM can do
whatever he needs there. In that way, the rest of us are not affected.
Right now in Royale-compiler we have 2 commits about releasing build-tools,
that I want to avoid. Those in particular are not problematic, but will be
the ones for compiler, typedefs and framework in case the release is not
done quickly.
The main problems in the way we do now:
- If release need to be aborted, will have lots of "[maven-release-plugin]"
commits done and reverted.
- developers using the current snapshot will need to not update the commits
with the new versions to continue building the snapshot that is used in the
rest of repos.
so steps 14,18 and 22 was not what I was referring to.
Thanks
El vie., 3 abr. 2020 a las 6:38, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Steps 14, 18, and 22 in [1] dictate the use of branches.
>
> [1]
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>
> -Alex
>
> On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> sending this again, since it was missed in the other thread, but is
> something not related.
>
> ---------- Forwarded message ---------
> De: Carlos Rovira <ca...@apache.org>
> Date: jue., 2 abr. 2020 a las 14:32
> Subject: Re: Royale Releases
> To: Apache Royale Development <de...@royale.apache.org>
>
>
> Hi,
>
> one thing I want to propose before other considerations:
>
> When starting work on a release, could we work on a new branch?
>
> so all commits go to that branch and when all is done then merge to
> develop? I think that will generate less problems to people working in
> develop branch since releases can be wrong or test can delay some days,
> that means people can have versions updated while other parts of the
> code
> still require old versions, so that generate confusion. Doing all in a
> new
> branch and then merging after all votes passes, seems to me the best
> way to
> keep safe users working on develop.
>
> Thanks
>
>
> El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > first, many thanks for the detailed email. I'll comment on this
> later as I
> > have more time.
> >
> > For now, to add up a recent example on what Chris commented: If you
> all
> > remember a week ago I was trying to use SVG Images in a blog example
> that
> > was published 2 days ago. Nobody tried SVG Images before building
> with
> > maven, I know that since maven was not properly configured and using
> that
> > component from Maven was failing with an RTE. Probably we have more
> things
> > not working the same way when build from Maven and Ant, and that's
> > something that will need people using that code paths in test
> applications
> > (or in their own apps) to see if things works properly.
> >
> > I was recently introduced to "examples-integrationtest" by Chris,
> that I
> > plan to use soon as I can. I think is a great idea, since you get a
> Firefox
> > running test interface of the real use of some concrete royale code.
> I
> > think passed until now unnoticed by all of us, and seems a powerful
> tool.
> > There's already an example about FlexStore with some basic
> assertions.
> >
> > Again, thanks, and will comment on the rest later
> >
> > Carlos
> >
> >
> >
> >
> > El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> > christofer.dutz@c-ware.de>) escribió:
> >
> >> Hi Alex,
> >>
> >> just a point you are bringing up: "Code coverage".
> >>
> >> I strongly dislike the idea of "asjs" effectively being the test
> for the
> >> compiler. The reasoning behind this is: yes you do get more code
> covered,
> >> but only the happy-path (ideally) and even if things go wrong, the
> end
> >> results aren't tested. Did add a module to asjs years ago
> >> ("examples-integrationtest") that deployed the examples in a tomcat
> server
> >> then opens a Firefox browser and clicks through 2 of the examples
> (I added
> >> two dummy tests as an example, but seems no one touched this after
> me). I
> >> did this because I remember us working on asjs for weeks without
> anyone
> >> noticing the compiler wasn't producing runnable code ... same with
> the
> >> little unit-tests that are still run for every example, that simply
> check
> >> if an output is generated, because we had a prolonged period of
> time where
> >> we were all working on different parts, but for quite some time the
> >> application compilation just didn't output anything and no one
> noticed.
> >>
> >> So coverage is nothing without assertions (my opinion) ... ok ...
> it's
> >> slightly better than no coverage, but not much, in my opinion.
> >>
> >> I think in parallel to this release discussions I have seen numerous
> >> threads about someone doing something that broke something for
> someone
> >> else. This could be addressed by increasing coverage by providing
> explicit
> >> tests.
> >>
> >> Coming back to the releases:
> >> I have no objections, if you do a "release" locally and automate the
> >> validation on the CI server (Which effectively would be your
> proposal to do
> >> the first 12 steps on local hardware and the 13th on the CI
> server). I even
> >> think that's a good idea ... There could be one step for building a
> release
> >> from a given "git tag" for every build system and generic means to
> compare
> >> tar.gz and zips produced by any build system with that of another
> (ideally
> >> with better output than just a plain "true/false"). This would even
> help to
> >> iron out the last potentially existing bumps out of the Maven
> distribution.
> >>
> >> Chris
> >>
> >>
> >>
> >> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
> >>
> >> Hi,
> >>
> >> This is my attempt to explain what goes into a release in hopes
> that
> >> we can understand and agree on what our release process is. It
> became
> >> apparent in my reading of the wiki page with the new Maven steps
> and in
> >> talking with Harbs today that there are still many
> misunderstandings about
> >> what we do to create a release. I don't generally like writing
> >> instructions in English because it is easy to be ambiguous. All of
> the
> >> steps that we use to create releases had been captured in Ant
> scripts in a
> >> much more explicit way, IMO, but I took the time to write them down
> in
> >> English here:
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250159192&sdata=BEjSQ5xKo%2BvcTf3O%2FIBAJ7XEZIMWOdYrMLicDn2PxbU%3D&reserved=0
> >>
> >> I did this quickly by scanning the CI steps, the new Maven
> steps and
> >> the Ant scripts used in prior releases so there could certainly be
> mistakes
> >> and missed steps. If I did my math right, the RM for 0.9.7 will
> have to
> >> complete over 100 tasks (essentially, typing a command-line 100
> times).
> >> Future RMs, when we don't have to release build-tools, will have
> about 92
> >> steps. And I did not include voter verification checks the RM
> should run
> >> before opening a vote (verifying that the artifacts download and
> match
> >> their checksums, etc). As an RM, I run a bunch of tests on the RC
> before
> >> sending out the vote. Maybe we should add those to the task list.
> >>
> >> I think there has been confusion about the use of Ant in the
> release
> >> process. Because I was the RM for the first set of FlexJS/Royale
> releases,
> >> and I'm a lazy person who hates typing at the command line, I
> created Ant
> >> scripts to execute these 100 steps. But I agree that it is not a
> >> requirement that other RMs must use the Ant scripts for these
> commands. If
> >> you are the RM and like typing, go ahead.
> >>
> >> Then we found out that other people couldn't get through this
> task
> >> list. I think the 3 people who tried were having trouble with Maven
> >> uploads and downloads. So what I did was put the first 40 steps or
> so into
> >> Jenkins jobs. And by doing that, Piotr was able to produce our last
> >> release. And that also saves on manually typing commands. But
> again,
> >> going forward, the RM gets to choose how they want to execute these
> steps.
> >>
> >> If you scan the set of steps, you'll see that "ant" is only in
> there
> >> once. I believe the recent threads have been about this single
> command out
> >> of the 100+ commands. This is why this has been so frustrating to
> me. I
> >> believe there is a solid technical reason for that one command: it
> proves
> >> that the build.xml files in the source packages can build the
> .tar.gz that
> >> are useful to NPM and IDE users who use Ant and want to test a
> change.
> >>
> >> I think of it as code-coverage. If we had code-coverage tools,
> we
> >> would ask that the RM complete as much of the automated
> code-coverage
> >> testing as possible before posting the release for a vote. That one
> >> command increases our code coverage by running the build.xml
> files. We
> >> should be always working to increase automated code coverage in the
> RC.
> >> Certainly for me as RM, I will gladly watch TV as the automated
> tests run
> >> because a failed RC means going back through many of the first 25
> commands
> >> again and wastes other people's time. Each RC is more emails to
> read and
> >> more time from the voters and testers.
> >>
> >> If there are other ways for the RM to get the same or better
> code
> >> coverage on the build.xml files before posting the RC, we can
> discuss those
> >> options.
> >>
> >> I am hopeful we can all agree on these simple principles:
> Strive for
> >> better code coverage and fewer failed RCs. Royale's main purpose
> is to
> >> save other people time. Let's do that in creating releases too.
> >>
> >> One issue that was brought up recently was whether it is a good
> >> decision to have the RM test all of the build platforms we support.
> >> Suppose we add some other build system support or more in the
> future?
> >> Again, the code coverage principle applies here, but also, I would
> like us
> >> to retain feature parity, and I also hope for as few RCs and votes
> as
> >> possible. So instead of having separate
> votes/features/release-dates for
> >> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> >> artifacts, I think we should have one vote and keep them all in
> sync. If
> >> we do ever get around to monthly or bi-monthly releases, I think
> separate
> >> build platform releases would be too much work.
> >>
> >> But consider this thought I just had today: the RM doesn't
> really
> >> have to choose to do all 100 commands on a local machine or with Ant
> >> scripts or do the first 40 via CI. The RM can actually pick and
> choose
> >> commands to run on the CI server. The CI Jenkins jobs are not a
> >> separate/alternative release process, they are just another way of
> >> executing the first 40 steps. Using CI jobs actually requires
> additional
> >> command-line cut-and-paste to push commits on the CI server and to
> sign and
> >> validate binaries locally, but that's the trade-off of not having to
> >> configure your machine to successfully run all of the automated
> tests and
> >> build systems, and being able to run a command by filling in the
> version
> >> number and rc number and hitting the "ok" button instead of making
> sure you
> >> got the whole command typed in correctly.
> >>
> >> So, an RM can run the first 25 steps locally, then go the CI
> server
> >> and run what is now Jenkins Job "Royale_Release_Step_013" (no need
> to run
> >> the first 12) and it will run tasks 26 through 32, and if it is
> successful,
> >> then the RM has proven code coverage of the build.xml files. (If
> the
> >> resulting tar.gz and zips are not posted, then the RM should verify
> that
> >> they match the ones from Maven distribution). I would encourage
> RMs to
> >> also use the CI jobs that generate the emails to make sure the
> subject and
> >> content is correct and contains the usual instructions so we have
> >> consistency. Maybe someday there will be CI jobs to do the last
> 60+ steps
> >> if that helps. We could add a Jenkins job that runs an Ant build
> on RC
> >> artifacts on dist.a.o as well.
> >>
> >> I would like you all to help maintain the list of 100 steps and
> other
> >> documents related to the release process, and improve the CI jobs
> and Ant
> >> steps if it helps you be a more efficient RM. I am hopeful that
> now that I
> >> have hopefully explained our release process better, that we can
> see that
> >> these 100+ steps just have to be done in some way. The RM can
> figure out
> >> what way works best for them, but they must get through all of them.
> >>
> >> Thanks,
> >> -Alex
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250159192&sdata=e%2B2NJyGFXrMiKzgkgs06SggNlHxEL4r30XBA%2FSOIjOw%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250169187&sdata=h08zZPbsbmB4ErObyvlu6eWXWSUSkBPbcETWx5ofmew%3D&reserved=0
>
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250169187&sdata=h08zZPbsbmB4ErObyvlu6eWXWSUSkBPbcETWx5ofmew%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Create new branch when creating a release (was Fwd: Royale
Releases)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Steps 14, 18, and 22 in [1] dictate the use of branches.
[1] https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
-Alex
On 4/2/20, 4:53 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi,
sending this again, since it was missed in the other thread, but is
something not related.
---------- Forwarded message ---------
De: Carlos Rovira <ca...@apache.org>
Date: jue., 2 abr. 2020 a las 14:32
Subject: Re: Royale Releases
To: Apache Royale Development <de...@royale.apache.org>
Hi,
one thing I want to propose before other considerations:
When starting work on a release, could we work on a new branch?
so all commits go to that branch and when all is done then merge to
develop? I think that will generate less problems to people working in
develop branch since releases can be wrong or test can delay some days,
that means people can have versions updated while other parts of the code
still require old versions, so that generate confusion. Doing all in a new
branch and then merging after all votes passes, seems to me the best way to
keep safe users working on develop.
Thanks
El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> first, many thanks for the detailed email. I'll comment on this later as I
> have more time.
>
> For now, to add up a recent example on what Chris commented: If you all
> remember a week ago I was trying to use SVG Images in a blog example that
> was published 2 days ago. Nobody tried SVG Images before building with
> maven, I know that since maven was not properly configured and using that
> component from Maven was failing with an RTE. Probably we have more things
> not working the same way when build from Maven and Ant, and that's
> something that will need people using that code paths in test applications
> (or in their own apps) to see if things works properly.
>
> I was recently introduced to "examples-integrationtest" by Chris, that I
> plan to use soon as I can. I think is a great idea, since you get a Firefox
> running test interface of the real use of some concrete royale code. I
> think passed until now unnoticed by all of us, and seems a powerful tool.
> There's already an example about FlexStore with some basic assertions.
>
> Again, thanks, and will comment on the rest later
>
> Carlos
>
>
>
>
> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> christofer.dutz@c-ware.de>) escribió:
>
>> Hi Alex,
>>
>> just a point you are bringing up: "Code coverage".
>>
>> I strongly dislike the idea of "asjs" effectively being the test for the
>> compiler. The reasoning behind this is: yes you do get more code covered,
>> but only the happy-path (ideally) and even if things go wrong, the end
>> results aren't tested. Did add a module to asjs years ago
>> ("examples-integrationtest") that deployed the examples in a tomcat server
>> then opens a Firefox browser and clicks through 2 of the examples (I added
>> two dummy tests as an example, but seems no one touched this after me). I
>> did this because I remember us working on asjs for weeks without anyone
>> noticing the compiler wasn't producing runnable code ... same with the
>> little unit-tests that are still run for every example, that simply check
>> if an output is generated, because we had a prolonged period of time where
>> we were all working on different parts, but for quite some time the
>> application compilation just didn't output anything and no one noticed.
>>
>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>> slightly better than no coverage, but not much, in my opinion.
>>
>> I think in parallel to this release discussions I have seen numerous
>> threads about someone doing something that broke something for someone
>> else. This could be addressed by increasing coverage by providing explicit
>> tests.
>>
>> Coming back to the releases:
>> I have no objections, if you do a "release" locally and automate the
>> validation on the CI server (Which effectively would be your proposal to do
>> the first 12 steps on local hardware and the 13th on the CI server). I even
>> think that's a good idea ... There could be one step for building a release
>> from a given "git tag" for every build system and generic means to compare
>> tar.gz and zips produced by any build system with that of another (ideally
>> with better output than just a plain "true/false"). This would even help to
>> iron out the last potentially existing bumps out of the Maven distribution.
>>
>> Chris
>>
>>
>>
>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>
>> Hi,
>>
>> This is my attempt to explain what goes into a release in hopes that
>> we can understand and agree on what our release process is. It became
>> apparent in my reading of the wiki page with the new Maven steps and in
>> talking with Harbs today that there are still many misunderstandings about
>> what we do to create a release. I don't generally like writing
>> instructions in English because it is easy to be ambiguous. All of the
>> steps that we use to create releases had been captured in Ant scripts in a
>> much more explicit way, IMO, but I took the time to write them down in
>> English here:
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250159192&sdata=BEjSQ5xKo%2BvcTf3O%2FIBAJ7XEZIMWOdYrMLicDn2PxbU%3D&reserved=0
>>
>> I did this quickly by scanning the CI steps, the new Maven steps and
>> the Ant scripts used in prior releases so there could certainly be mistakes
>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>> complete over 100 tasks (essentially, typing a command-line 100 times).
>> Future RMs, when we don't have to release build-tools, will have about 92
>> steps. And I did not include voter verification checks the RM should run
>> before opening a vote (verifying that the artifacts download and match
>> their checksums, etc). As an RM, I run a bunch of tests on the RC before
>> sending out the vote. Maybe we should add those to the task list.
>>
>> I think there has been confusion about the use of Ant in the release
>> process. Because I was the RM for the first set of FlexJS/Royale releases,
>> and I'm a lazy person who hates typing at the command line, I created Ant
>> scripts to execute these 100 steps. But I agree that it is not a
>> requirement that other RMs must use the Ant scripts for these commands. If
>> you are the RM and like typing, go ahead.
>>
>> Then we found out that other people couldn't get through this task
>> list. I think the 3 people who tried were having trouble with Maven
>> uploads and downloads. So what I did was put the first 40 steps or so into
>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>> release. And that also saves on manually typing commands. But again,
>> going forward, the RM gets to choose how they want to execute these steps.
>>
>> If you scan the set of steps, you'll see that "ant" is only in there
>> once. I believe the recent threads have been about this single command out
>> of the 100+ commands. This is why this has been so frustrating to me. I
>> believe there is a solid technical reason for that one command: it proves
>> that the build.xml files in the source packages can build the .tar.gz that
>> are useful to NPM and IDE users who use Ant and want to test a change.
>>
>> I think of it as code-coverage. If we had code-coverage tools, we
>> would ask that the RM complete as much of the automated code-coverage
>> testing as possible before posting the release for a vote. That one
>> command increases our code coverage by running the build.xml files. We
>> should be always working to increase automated code coverage in the RC.
>> Certainly for me as RM, I will gladly watch TV as the automated tests run
>> because a failed RC means going back through many of the first 25 commands
>> again and wastes other people's time. Each RC is more emails to read and
>> more time from the voters and testers.
>>
>> If there are other ways for the RM to get the same or better code
>> coverage on the build.xml files before posting the RC, we can discuss those
>> options.
>>
>> I am hopeful we can all agree on these simple principles: Strive for
>> better code coverage and fewer failed RCs. Royale's main purpose is to
>> save other people time. Let's do that in creating releases too.
>>
>> One issue that was brought up recently was whether it is a good
>> decision to have the RM test all of the build platforms we support.
>> Suppose we add some other build system support or more in the future?
>> Again, the code coverage principle applies here, but also, I would like us
>> to retain feature parity, and I also hope for as few RCs and votes as
>> possible. So instead of having separate votes/features/release-dates for
>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>> artifacts, I think we should have one vote and keep them all in sync. If
>> we do ever get around to monthly or bi-monthly releases, I think separate
>> build platform releases would be too much work.
>>
>> But consider this thought I just had today: the RM doesn't really
>> have to choose to do all 100 commands on a local machine or with Ant
>> scripts or do the first 40 via CI. The RM can actually pick and choose
>> commands to run on the CI server. The CI Jenkins jobs are not a
>> separate/alternative release process, they are just another way of
>> executing the first 40 steps. Using CI jobs actually requires additional
>> command-line cut-and-paste to push commits on the CI server and to sign and
>> validate binaries locally, but that's the trade-off of not having to
>> configure your machine to successfully run all of the automated tests and
>> build systems, and being able to run a command by filling in the version
>> number and rc number and hitting the "ok" button instead of making sure you
>> got the whole command typed in correctly.
>>
>> So, an RM can run the first 25 steps locally, then go the CI server
>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run
>> the first 12) and it will run tasks 26 through 32, and if it is successful,
>> then the RM has proven code coverage of the build.xml files. (If the
>> resulting tar.gz and zips are not posted, then the RM should verify that
>> they match the ones from Maven distribution). I would encourage RMs to
>> also use the CI jobs that generate the emails to make sure the subject and
>> content is correct and contains the usual instructions so we have
>> consistency. Maybe someday there will be CI jobs to do the last 60+ steps
>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>> artifacts on dist.a.o as well.
>>
>> I would like you all to help maintain the list of 100 steps and other
>> documents related to the release process, and improve the CI jobs and Ant
>> steps if it helps you be a more efficient RM. I am hopeful that now that I
>> have hopefully explained our release process better, that we can see that
>> these 100+ steps just have to be done in some way. The RM can figure out
>> what way works best for them, but they must get through all of them.
>>
>> Thanks,
>> -Alex
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250159192&sdata=e%2B2NJyGFXrMiKzgkgs06SggNlHxEL4r30XBA%2FSOIjOw%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250169187&sdata=h08zZPbsbmB4ErObyvlu6eWXWSUSkBPbcETWx5ofmew%3D&reserved=0
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C68273de0c3724d5786e208d7d75f2b55%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214681250169187&sdata=h08zZPbsbmB4ErObyvlu6eWXWSUSkBPbcETWx5ofmew%3D&reserved=0
Create new branch when creating a release (was Fwd: Royale Releases)
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
sending this again, since it was missed in the other thread, but is
something not related.
---------- Forwarded message ---------
De: Carlos Rovira <ca...@apache.org>
Date: jue., 2 abr. 2020 a las 14:32
Subject: Re: Royale Releases
To: Apache Royale Development <de...@royale.apache.org>
Hi,
one thing I want to propose before other considerations:
When starting work on a release, could we work on a new branch?
so all commits go to that branch and when all is done then merge to
develop? I think that will generate less problems to people working in
develop branch since releases can be wrong or test can delay some days,
that means people can have versions updated while other parts of the code
still require old versions, so that generate confusion. Doing all in a new
branch and then merging after all votes passes, seems to me the best way to
keep safe users working on develop.
Thanks
El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> first, many thanks for the detailed email. I'll comment on this later as I
> have more time.
>
> For now, to add up a recent example on what Chris commented: If you all
> remember a week ago I was trying to use SVG Images in a blog example that
> was published 2 days ago. Nobody tried SVG Images before building with
> maven, I know that since maven was not properly configured and using that
> component from Maven was failing with an RTE. Probably we have more things
> not working the same way when build from Maven and Ant, and that's
> something that will need people using that code paths in test applications
> (or in their own apps) to see if things works properly.
>
> I was recently introduced to "examples-integrationtest" by Chris, that I
> plan to use soon as I can. I think is a great idea, since you get a Firefox
> running test interface of the real use of some concrete royale code. I
> think passed until now unnoticed by all of us, and seems a powerful tool.
> There's already an example about FlexStore with some basic assertions.
>
> Again, thanks, and will comment on the rest later
>
> Carlos
>
>
>
>
> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> christofer.dutz@c-ware.de>) escribió:
>
>> Hi Alex,
>>
>> just a point you are bringing up: "Code coverage".
>>
>> I strongly dislike the idea of "asjs" effectively being the test for the
>> compiler. The reasoning behind this is: yes you do get more code covered,
>> but only the happy-path (ideally) and even if things go wrong, the end
>> results aren't tested. Did add a module to asjs years ago
>> ("examples-integrationtest") that deployed the examples in a tomcat server
>> then opens a Firefox browser and clicks through 2 of the examples (I added
>> two dummy tests as an example, but seems no one touched this after me). I
>> did this because I remember us working on asjs for weeks without anyone
>> noticing the compiler wasn't producing runnable code ... same with the
>> little unit-tests that are still run for every example, that simply check
>> if an output is generated, because we had a prolonged period of time where
>> we were all working on different parts, but for quite some time the
>> application compilation just didn't output anything and no one noticed.
>>
>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>> slightly better than no coverage, but not much, in my opinion.
>>
>> I think in parallel to this release discussions I have seen numerous
>> threads about someone doing something that broke something for someone
>> else. This could be addressed by increasing coverage by providing explicit
>> tests.
>>
>> Coming back to the releases:
>> I have no objections, if you do a "release" locally and automate the
>> validation on the CI server (Which effectively would be your proposal to do
>> the first 12 steps on local hardware and the 13th on the CI server). I even
>> think that's a good idea ... There could be one step for building a release
>> from a given "git tag" for every build system and generic means to compare
>> tar.gz and zips produced by any build system with that of another (ideally
>> with better output than just a plain "true/false"). This would even help to
>> iron out the last potentially existing bumps out of the Maven distribution.
>>
>> Chris
>>
>>
>>
>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>
>> Hi,
>>
>> This is my attempt to explain what goes into a release in hopes that
>> we can understand and agree on what our release process is. It became
>> apparent in my reading of the wiki page with the new Maven steps and in
>> talking with Harbs today that there are still many misunderstandings about
>> what we do to create a release. I don't generally like writing
>> instructions in English because it is easy to be ambiguous. All of the
>> steps that we use to create releases had been captured in Ant scripts in a
>> much more explicit way, IMO, but I took the time to write them down in
>> English here:
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>
>> I did this quickly by scanning the CI steps, the new Maven steps and
>> the Ant scripts used in prior releases so there could certainly be mistakes
>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>> complete over 100 tasks (essentially, typing a command-line 100 times).
>> Future RMs, when we don't have to release build-tools, will have about 92
>> steps. And I did not include voter verification checks the RM should run
>> before opening a vote (verifying that the artifacts download and match
>> their checksums, etc). As an RM, I run a bunch of tests on the RC before
>> sending out the vote. Maybe we should add those to the task list.
>>
>> I think there has been confusion about the use of Ant in the release
>> process. Because I was the RM for the first set of FlexJS/Royale releases,
>> and I'm a lazy person who hates typing at the command line, I created Ant
>> scripts to execute these 100 steps. But I agree that it is not a
>> requirement that other RMs must use the Ant scripts for these commands. If
>> you are the RM and like typing, go ahead.
>>
>> Then we found out that other people couldn't get through this task
>> list. I think the 3 people who tried were having trouble with Maven
>> uploads and downloads. So what I did was put the first 40 steps or so into
>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>> release. And that also saves on manually typing commands. But again,
>> going forward, the RM gets to choose how they want to execute these steps.
>>
>> If you scan the set of steps, you'll see that "ant" is only in there
>> once. I believe the recent threads have been about this single command out
>> of the 100+ commands. This is why this has been so frustrating to me. I
>> believe there is a solid technical reason for that one command: it proves
>> that the build.xml files in the source packages can build the .tar.gz that
>> are useful to NPM and IDE users who use Ant and want to test a change.
>>
>> I think of it as code-coverage. If we had code-coverage tools, we
>> would ask that the RM complete as much of the automated code-coverage
>> testing as possible before posting the release for a vote. That one
>> command increases our code coverage by running the build.xml files. We
>> should be always working to increase automated code coverage in the RC.
>> Certainly for me as RM, I will gladly watch TV as the automated tests run
>> because a failed RC means going back through many of the first 25 commands
>> again and wastes other people's time. Each RC is more emails to read and
>> more time from the voters and testers.
>>
>> If there are other ways for the RM to get the same or better code
>> coverage on the build.xml files before posting the RC, we can discuss those
>> options.
>>
>> I am hopeful we can all agree on these simple principles: Strive for
>> better code coverage and fewer failed RCs. Royale's main purpose is to
>> save other people time. Let's do that in creating releases too.
>>
>> One issue that was brought up recently was whether it is a good
>> decision to have the RM test all of the build platforms we support.
>> Suppose we add some other build system support or more in the future?
>> Again, the code coverage principle applies here, but also, I would like us
>> to retain feature parity, and I also hope for as few RCs and votes as
>> possible. So instead of having separate votes/features/release-dates for
>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>> artifacts, I think we should have one vote and keep them all in sync. If
>> we do ever get around to monthly or bi-monthly releases, I think separate
>> build platform releases would be too much work.
>>
>> But consider this thought I just had today: the RM doesn't really
>> have to choose to do all 100 commands on a local machine or with Ant
>> scripts or do the first 40 via CI. The RM can actually pick and choose
>> commands to run on the CI server. The CI Jenkins jobs are not a
>> separate/alternative release process, they are just another way of
>> executing the first 40 steps. Using CI jobs actually requires additional
>> command-line cut-and-paste to push commits on the CI server and to sign and
>> validate binaries locally, but that's the trade-off of not having to
>> configure your machine to successfully run all of the automated tests and
>> build systems, and being able to run a command by filling in the version
>> number and rc number and hitting the "ok" button instead of making sure you
>> got the whole command typed in correctly.
>>
>> So, an RM can run the first 25 steps locally, then go the CI server
>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run
>> the first 12) and it will run tasks 26 through 32, and if it is successful,
>> then the RM has proven code coverage of the build.xml files. (If the
>> resulting tar.gz and zips are not posted, then the RM should verify that
>> they match the ones from Maven distribution). I would encourage RMs to
>> also use the CI jobs that generate the emails to make sure the subject and
>> content is correct and contains the usual instructions so we have
>> consistency. Maybe someday there will be CI jobs to do the last 60+ steps
>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>> artifacts on dist.a.o as well.
>>
>> I would like you all to help maintain the list of 100 steps and other
>> documents related to the release process, and improve the CI jobs and Ant
>> steps if it helps you be a more efficient RM. I am hopeful that now that I
>> have hopefully explained our release process better, that we can see that
>> these 100+ steps just have to be done in some way. The RM can figure out
>> what way works best for them, but they must get through all of them.
>>
>> Thanks,
>> -Alex
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
one thing I want to propose before other considerations:
When starting work on a release, could we work on a new branch?
so all commits go to that branch and when all is done then merge to
develop? I think that will generate less problems to people working in
develop branch since releases can be wrong or test can delay some days,
that means people can have versions updated while other parts of the code
still require old versions, so that generate confusion. Doing all in a new
branch and then merging after all votes passes, seems to me the best way to
keep safe users working on develop.
Thanks
El jue., 2 abr. 2020 a las 9:46, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> first, many thanks for the detailed email. I'll comment on this later as I
> have more time.
>
> For now, to add up a recent example on what Chris commented: If you all
> remember a week ago I was trying to use SVG Images in a blog example that
> was published 2 days ago. Nobody tried SVG Images before building with
> maven, I know that since maven was not properly configured and using that
> component from Maven was failing with an RTE. Probably we have more things
> not working the same way when build from Maven and Ant, and that's
> something that will need people using that code paths in test applications
> (or in their own apps) to see if things works properly.
>
> I was recently introduced to "examples-integrationtest" by Chris, that I
> plan to use soon as I can. I think is a great idea, since you get a Firefox
> running test interface of the real use of some concrete royale code. I
> think passed until now unnoticed by all of us, and seems a powerful tool.
> There's already an example about FlexStore with some basic assertions.
>
> Again, thanks, and will comment on the rest later
>
> Carlos
>
>
>
>
> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<
> christofer.dutz@c-ware.de>) escribió:
>
>> Hi Alex,
>>
>> just a point you are bringing up: "Code coverage".
>>
>> I strongly dislike the idea of "asjs" effectively being the test for the
>> compiler. The reasoning behind this is: yes you do get more code covered,
>> but only the happy-path (ideally) and even if things go wrong, the end
>> results aren't tested. Did add a module to asjs years ago
>> ("examples-integrationtest") that deployed the examples in a tomcat server
>> then opens a Firefox browser and clicks through 2 of the examples (I added
>> two dummy tests as an example, but seems no one touched this after me). I
>> did this because I remember us working on asjs for weeks without anyone
>> noticing the compiler wasn't producing runnable code ... same with the
>> little unit-tests that are still run for every example, that simply check
>> if an output is generated, because we had a prolonged period of time where
>> we were all working on different parts, but for quite some time the
>> application compilation just didn't output anything and no one noticed.
>>
>> So coverage is nothing without assertions (my opinion) ... ok ... it's
>> slightly better than no coverage, but not much, in my opinion.
>>
>> I think in parallel to this release discussions I have seen numerous
>> threads about someone doing something that broke something for someone
>> else. This could be addressed by increasing coverage by providing explicit
>> tests.
>>
>> Coming back to the releases:
>> I have no objections, if you do a "release" locally and automate the
>> validation on the CI server (Which effectively would be your proposal to do
>> the first 12 steps on local hardware and the 13th on the CI server). I even
>> think that's a good idea ... There could be one step for building a release
>> from a given "git tag" for every build system and generic means to compare
>> tar.gz and zips produced by any build system with that of another (ideally
>> with better output than just a plain "true/false"). This would even help to
>> iron out the last potentially existing bumps out of the Maven distribution.
>>
>> Chris
>>
>>
>>
>> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>>
>> Hi,
>>
>> This is my attempt to explain what goes into a release in hopes that
>> we can understand and agree on what our release process is. It became
>> apparent in my reading of the wiki page with the new Maven steps and in
>> talking with Harbs today that there are still many misunderstandings about
>> what we do to create a release. I don't generally like writing
>> instructions in English because it is easy to be ambiguous. All of the
>> steps that we use to create releases had been captured in Ant scripts in a
>> much more explicit way, IMO, but I took the time to write them down in
>> English here:
>> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>>
>> I did this quickly by scanning the CI steps, the new Maven steps and
>> the Ant scripts used in prior releases so there could certainly be mistakes
>> and missed steps. If I did my math right, the RM for 0.9.7 will have to
>> complete over 100 tasks (essentially, typing a command-line 100 times).
>> Future RMs, when we don't have to release build-tools, will have about 92
>> steps. And I did not include voter verification checks the RM should run
>> before opening a vote (verifying that the artifacts download and match
>> their checksums, etc). As an RM, I run a bunch of tests on the RC before
>> sending out the vote. Maybe we should add those to the task list.
>>
>> I think there has been confusion about the use of Ant in the release
>> process. Because I was the RM for the first set of FlexJS/Royale releases,
>> and I'm a lazy person who hates typing at the command line, I created Ant
>> scripts to execute these 100 steps. But I agree that it is not a
>> requirement that other RMs must use the Ant scripts for these commands. If
>> you are the RM and like typing, go ahead.
>>
>> Then we found out that other people couldn't get through this task
>> list. I think the 3 people who tried were having trouble with Maven
>> uploads and downloads. So what I did was put the first 40 steps or so into
>> Jenkins jobs. And by doing that, Piotr was able to produce our last
>> release. And that also saves on manually typing commands. But again,
>> going forward, the RM gets to choose how they want to execute these steps.
>>
>> If you scan the set of steps, you'll see that "ant" is only in there
>> once. I believe the recent threads have been about this single command out
>> of the 100+ commands. This is why this has been so frustrating to me. I
>> believe there is a solid technical reason for that one command: it proves
>> that the build.xml files in the source packages can build the .tar.gz that
>> are useful to NPM and IDE users who use Ant and want to test a change.
>>
>> I think of it as code-coverage. If we had code-coverage tools, we
>> would ask that the RM complete as much of the automated code-coverage
>> testing as possible before posting the release for a vote. That one
>> command increases our code coverage by running the build.xml files. We
>> should be always working to increase automated code coverage in the RC.
>> Certainly for me as RM, I will gladly watch TV as the automated tests run
>> because a failed RC means going back through many of the first 25 commands
>> again and wastes other people's time. Each RC is more emails to read and
>> more time from the voters and testers.
>>
>> If there are other ways for the RM to get the same or better code
>> coverage on the build.xml files before posting the RC, we can discuss those
>> options.
>>
>> I am hopeful we can all agree on these simple principles: Strive for
>> better code coverage and fewer failed RCs. Royale's main purpose is to
>> save other people time. Let's do that in creating releases too.
>>
>> One issue that was brought up recently was whether it is a good
>> decision to have the RM test all of the build platforms we support.
>> Suppose we add some other build system support or more in the future?
>> Again, the code coverage principle applies here, but also, I would like us
>> to retain feature parity, and I also hope for as few RCs and votes as
>> possible. So instead of having separate votes/features/release-dates for
>> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
>> artifacts, I think we should have one vote and keep them all in sync. If
>> we do ever get around to monthly or bi-monthly releases, I think separate
>> build platform releases would be too much work.
>>
>> But consider this thought I just had today: the RM doesn't really
>> have to choose to do all 100 commands on a local machine or with Ant
>> scripts or do the first 40 via CI. The RM can actually pick and choose
>> commands to run on the CI server. The CI Jenkins jobs are not a
>> separate/alternative release process, they are just another way of
>> executing the first 40 steps. Using CI jobs actually requires additional
>> command-line cut-and-paste to push commits on the CI server and to sign and
>> validate binaries locally, but that's the trade-off of not having to
>> configure your machine to successfully run all of the automated tests and
>> build systems, and being able to run a command by filling in the version
>> number and rc number and hitting the "ok" button instead of making sure you
>> got the whole command typed in correctly.
>>
>> So, an RM can run the first 25 steps locally, then go the CI server
>> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run
>> the first 12) and it will run tasks 26 through 32, and if it is successful,
>> then the RM has proven code coverage of the build.xml files. (If the
>> resulting tar.gz and zips are not posted, then the RM should verify that
>> they match the ones from Maven distribution). I would encourage RMs to
>> also use the CI jobs that generate the emails to make sure the subject and
>> content is correct and contains the usual instructions so we have
>> consistency. Maybe someday there will be CI jobs to do the last 60+ steps
>> if that helps. We could add a Jenkins job that runs an Ant build on RC
>> artifacts on dist.a.o as well.
>>
>> I would like you all to help maintain the list of 100 steps and other
>> documents related to the release process, and improve the CI jobs and Ant
>> steps if it helps you be a more efficient RM. I am hopeful that now that I
>> have hopefully explained our release process better, that we can see that
>> these 100+ steps just have to be done in some way. The RM can figure out
>> what way works best for them, but they must get through all of them.
>>
>> Thanks,
>> -Alex
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
first, many thanks for the detailed email. I'll comment on this later as I
have more time.
For now, to add up a recent example on what Chris commented: If you all
remember a week ago I was trying to use SVG Images in a blog example that
was published 2 days ago. Nobody tried SVG Images before building with
maven, I know that since maven was not properly configured and using that
component from Maven was failing with an RTE. Probably we have more things
not working the same way when build from Maven and Ant, and that's
something that will need people using that code paths in test applications
(or in their own apps) to see if things works properly.
I was recently introduced to "examples-integrationtest" by Chris, that I
plan to use soon as I can. I think is a great idea, since you get a Firefox
running test interface of the real use of some concrete royale code. I
think passed until now unnoticed by all of us, and seems a powerful tool.
There's already an example about FlexStore with some basic assertions.
Again, thanks, and will comment on the rest later
Carlos
El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (<ch...@c-ware.de>)
escribió:
> Hi Alex,
>
> just a point you are bringing up: "Code coverage".
>
> I strongly dislike the idea of "asjs" effectively being the test for the
> compiler. The reasoning behind this is: yes you do get more code covered,
> but only the happy-path (ideally) and even if things go wrong, the end
> results aren't tested. Did add a module to asjs years ago
> ("examples-integrationtest") that deployed the examples in a tomcat server
> then opens a Firefox browser and clicks through 2 of the examples (I added
> two dummy tests as an example, but seems no one touched this after me). I
> did this because I remember us working on asjs for weeks without anyone
> noticing the compiler wasn't producing runnable code ... same with the
> little unit-tests that are still run for every example, that simply check
> if an output is generated, because we had a prolonged period of time where
> we were all working on different parts, but for quite some time the
> application compilation just didn't output anything and no one noticed.
>
> So coverage is nothing without assertions (my opinion) ... ok ... it's
> slightly better than no coverage, but not much, in my opinion.
>
> I think in parallel to this release discussions I have seen numerous
> threads about someone doing something that broke something for someone
> else. This could be addressed by increasing coverage by providing explicit
> tests.
>
> Coming back to the releases:
> I have no objections, if you do a "release" locally and automate the
> validation on the CI server (Which effectively would be your proposal to do
> the first 12 steps on local hardware and the 13th on the CI server). I even
> think that's a good idea ... There could be one step for building a release
> from a given "git tag" for every build system and generic means to compare
> tar.gz and zips produced by any build system with that of another (ideally
> with better output than just a plain "true/false"). This would even help to
> iron out the last potentially existing bumps out of the Maven distribution.
>
> Chris
>
>
>
> Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>
> Hi,
>
> This is my attempt to explain what goes into a release in hopes that
> we can understand and agree on what our release process is. It became
> apparent in my reading of the wiki page with the new Maven steps and in
> talking with Harbs today that there are still many misunderstandings about
> what we do to create a release. I don't generally like writing
> instructions in English because it is easy to be ambiguous. All of the
> steps that we use to create releases had been captured in Ant scripts in a
> much more explicit way, IMO, but I took the time to write them down in
> English here:
> https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
>
> I did this quickly by scanning the CI steps, the new Maven steps and
> the Ant scripts used in prior releases so there could certainly be mistakes
> and missed steps. If I did my math right, the RM for 0.9.7 will have to
> complete over 100 tasks (essentially, typing a command-line 100 times).
> Future RMs, when we don't have to release build-tools, will have about 92
> steps. And I did not include voter verification checks the RM should run
> before opening a vote (verifying that the artifacts download and match
> their checksums, etc). As an RM, I run a bunch of tests on the RC before
> sending out the vote. Maybe we should add those to the task list.
>
> I think there has been confusion about the use of Ant in the release
> process. Because I was the RM for the first set of FlexJS/Royale releases,
> and I'm a lazy person who hates typing at the command line, I created Ant
> scripts to execute these 100 steps. But I agree that it is not a
> requirement that other RMs must use the Ant scripts for these commands. If
> you are the RM and like typing, go ahead.
>
> Then we found out that other people couldn't get through this task
> list. I think the 3 people who tried were having trouble with Maven
> uploads and downloads. So what I did was put the first 40 steps or so into
> Jenkins jobs. And by doing that, Piotr was able to produce our last
> release. And that also saves on manually typing commands. But again,
> going forward, the RM gets to choose how they want to execute these steps.
>
> If you scan the set of steps, you'll see that "ant" is only in there
> once. I believe the recent threads have been about this single command out
> of the 100+ commands. This is why this has been so frustrating to me. I
> believe there is a solid technical reason for that one command: it proves
> that the build.xml files in the source packages can build the .tar.gz that
> are useful to NPM and IDE users who use Ant and want to test a change.
>
> I think of it as code-coverage. If we had code-coverage tools, we
> would ask that the RM complete as much of the automated code-coverage
> testing as possible before posting the release for a vote. That one
> command increases our code coverage by running the build.xml files. We
> should be always working to increase automated code coverage in the RC.
> Certainly for me as RM, I will gladly watch TV as the automated tests run
> because a failed RC means going back through many of the first 25 commands
> again and wastes other people's time. Each RC is more emails to read and
> more time from the voters and testers.
>
> If there are other ways for the RM to get the same or better code
> coverage on the build.xml files before posting the RC, we can discuss those
> options.
>
> I am hopeful we can all agree on these simple principles: Strive for
> better code coverage and fewer failed RCs. Royale's main purpose is to
> save other people time. Let's do that in creating releases too.
>
> One issue that was brought up recently was whether it is a good
> decision to have the RM test all of the build platforms we support.
> Suppose we add some other build system support or more in the future?
> Again, the code coverage principle applies here, but also, I would like us
> to retain feature parity, and I also hope for as few RCs and votes as
> possible. So instead of having separate votes/features/release-dates for
> the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech
> artifacts, I think we should have one vote and keep them all in sync. If
> we do ever get around to monthly or bi-monthly releases, I think separate
> build platform releases would be too much work.
>
> But consider this thought I just had today: the RM doesn't really
> have to choose to do all 100 commands on a local machine or with Ant
> scripts or do the first 40 via CI. The RM can actually pick and choose
> commands to run on the CI server. The CI Jenkins jobs are not a
> separate/alternative release process, they are just another way of
> executing the first 40 steps. Using CI jobs actually requires additional
> command-line cut-and-paste to push commits on the CI server and to sign and
> validate binaries locally, but that's the trade-off of not having to
> configure your machine to successfully run all of the automated tests and
> build systems, and being able to run a command by filling in the version
> number and rc number and hitting the "ok" button instead of making sure you
> got the whole command typed in correctly.
>
> So, an RM can run the first 25 steps locally, then go the CI server
> and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run
> the first 12) and it will run tasks 26 through 32, and if it is successful,
> then the RM has proven code coverage of the build.xml files. (If the
> resulting tar.gz and zips are not posted, then the RM should verify that
> they match the ones from Maven distribution). I would encourage RMs to
> also use the CI jobs that generate the emails to make sure the subject and
> content is correct and contains the usual instructions so we have
> consistency. Maybe someday there will be CI jobs to do the last 60+ steps
> if that helps. We could add a Jenkins job that runs an Ant build on RC
> artifacts on dist.a.o as well.
>
> I would like you all to help maintain the list of 100 steps and other
> documents related to the release process, and improve the CI jobs and Ant
> steps if it helps you be a more efficient RM. I am hopeful that now that I
> have hopefully explained our release process better, that we can see that
> these 100+ steps just have to be done in some way. The RM can figure out
> what way works best for them, but they must get through all of them.
>
> Thanks,
> -Alex
>
>
>
>
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Releases
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
just a point you are bringing up: "Code coverage".
I strongly dislike the idea of "asjs" effectively being the test for the compiler. The reasoning behind this is: yes you do get more code covered, but only the happy-path (ideally) and even if things go wrong, the end results aren't tested. Did add a module to asjs years ago ("examples-integrationtest") that deployed the examples in a tomcat server then opens a Firefox browser and clicks through 2 of the examples (I added two dummy tests as an example, but seems no one touched this after me). I did this because I remember us working on asjs for weeks without anyone noticing the compiler wasn't producing runnable code ... same with the little unit-tests that are still run for every example, that simply check if an output is generated, because we had a prolonged period of time where we were all working on different parts, but for quite some time the application compilation just didn't output anything and no one noticed.
So coverage is nothing without assertions (my opinion) ... ok ... it's slightly better than no coverage, but not much, in my opinion.
I think in parallel to this release discussions I have seen numerous threads about someone doing something that broke something for someone else. This could be addressed by increasing coverage by providing explicit tests.
Coming back to the releases:
I have no objections, if you do a "release" locally and automate the validation on the CI server (Which effectively would be your proposal to do the first 12 steps on local hardware and the 13th on the CI server). I even think that's a good idea ... There could be one step for building a release from a given "git tag" for every build system and generic means to compare tar.gz and zips produced by any build system with that of another (ideally with better output than just a plain "true/false"). This would even help to iron out the last potentially existing bumps out of the Maven distribution.
Chris
Am 02.04.20, 07:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
Hi,
This is my attempt to explain what goes into a release in hopes that we can understand and agree on what our release process is. It became apparent in my reading of the wiki page with the new Maven steps and in talking with Harbs today that there are still many misunderstandings about what we do to create a release. I don't generally like writing instructions in English because it is easy to be ambiguous. All of the steps that we use to create releases had been captured in Ant scripts in a much more explicit way, IMO, but I took the time to write them down in English here: https://github.com/apache/royale-asjs/wiki/Task-List-For-Royale-Releases
I did this quickly by scanning the CI steps, the new Maven steps and the Ant scripts used in prior releases so there could certainly be mistakes and missed steps. If I did my math right, the RM for 0.9.7 will have to complete over 100 tasks (essentially, typing a command-line 100 times). Future RMs, when we don't have to release build-tools, will have about 92 steps. And I did not include voter verification checks the RM should run before opening a vote (verifying that the artifacts download and match their checksums, etc). As an RM, I run a bunch of tests on the RC before sending out the vote. Maybe we should add those to the task list.
I think there has been confusion about the use of Ant in the release process. Because I was the RM for the first set of FlexJS/Royale releases, and I'm a lazy person who hates typing at the command line, I created Ant scripts to execute these 100 steps. But I agree that it is not a requirement that other RMs must use the Ant scripts for these commands. If you are the RM and like typing, go ahead.
Then we found out that other people couldn't get through this task list. I think the 3 people who tried were having trouble with Maven uploads and downloads. So what I did was put the first 40 steps or so into Jenkins jobs. And by doing that, Piotr was able to produce our last release. And that also saves on manually typing commands. But again, going forward, the RM gets to choose how they want to execute these steps.
If you scan the set of steps, you'll see that "ant" is only in there once. I believe the recent threads have been about this single command out of the 100+ commands. This is why this has been so frustrating to me. I believe there is a solid technical reason for that one command: it proves that the build.xml files in the source packages can build the .tar.gz that are useful to NPM and IDE users who use Ant and want to test a change.
I think of it as code-coverage. If we had code-coverage tools, we would ask that the RM complete as much of the automated code-coverage testing as possible before posting the release for a vote. That one command increases our code coverage by running the build.xml files. We should be always working to increase automated code coverage in the RC. Certainly for me as RM, I will gladly watch TV as the automated tests run because a failed RC means going back through many of the first 25 commands again and wastes other people's time. Each RC is more emails to read and more time from the voters and testers.
If there are other ways for the RM to get the same or better code coverage on the build.xml files before posting the RC, we can discuss those options.
I am hopeful we can all agree on these simple principles: Strive for better code coverage and fewer failed RCs. Royale's main purpose is to save other people time. Let's do that in creating releases too.
One issue that was brought up recently was whether it is a good decision to have the RM test all of the build platforms we support. Suppose we add some other build system support or more in the future? Again, the code coverage principle applies here, but also, I would like us to retain feature parity, and I also hope for as few RCs and votes as possible. So instead of having separate votes/features/release-dates for the Maven artifacts vs the Ant artifacts vs the SomeFutureBuildTech artifacts, I think we should have one vote and keep them all in sync. If we do ever get around to monthly or bi-monthly releases, I think separate build platform releases would be too much work.
But consider this thought I just had today: the RM doesn't really have to choose to do all 100 commands on a local machine or with Ant scripts or do the first 40 via CI. The RM can actually pick and choose commands to run on the CI server. The CI Jenkins jobs are not a separate/alternative release process, they are just another way of executing the first 40 steps. Using CI jobs actually requires additional command-line cut-and-paste to push commits on the CI server and to sign and validate binaries locally, but that's the trade-off of not having to configure your machine to successfully run all of the automated tests and build systems, and being able to run a command by filling in the version number and rc number and hitting the "ok" button instead of making sure you got the whole command typed in correctly.
So, an RM can run the first 25 steps locally, then go the CI server and run what is now Jenkins Job "Royale_Release_Step_013" (no need to run the first 12) and it will run tasks 26 through 32, and if it is successful, then the RM has proven code coverage of the build.xml files. (If the resulting tar.gz and zips are not posted, then the RM should verify that they match the ones from Maven distribution). I would encourage RMs to also use the CI jobs that generate the emails to make sure the subject and content is correct and contains the usual instructions so we have consistency. Maybe someday there will be CI jobs to do the last 60+ steps if that helps. We could add a Jenkins job that runs an Ant build on RC artifacts on dist.a.o as well.
I would like you all to help maintain the list of 100 steps and other documents related to the release process, and improve the CI jobs and Ant steps if it helps you be a more efficient RM. I am hopeful that now that I have hopefully explained our release process better, that we can see that these 100+ steps just have to be done in some way. The RM can figure out what way works best for them, but they must get through all of them.
Thanks,
-Alex