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" <[email protected]>:
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 (<[email protected]>)
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" <[email protected]> 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
(<[email protected]
> >)
> 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" <[email protected]>
> 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
> (<[email protected]
> > >)
> > 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" <[email protected]>
> 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 <[email protected]>
> > > Sent: Thursday, April 2, 2020 4:42:00 PM
> > > To: [email protected] <[email protected]>
> > > 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" <
> > > [email protected]>:
> > >
> > > 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" <
> [email protected]>:
> > >
> > > 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 <
> > > [email protected]> 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 (<
> > > [email protected]>) 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 <
> > > [email protected]>
> > > >> 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 (<
> > > >> [email protected]>)
> > > >>> 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"
> > > <[email protected]>:
> > > >>>>
> > > >>>> 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
