Replying to your email on the other thread:
Currently the Maven release is able to produce a full Apache release including
convenience binary distributions for Maven, Ant and IDE usage.
The Ant build probably currently couldn't create and deploy the maven artifacts
on its own however.
But it should be possible to extend the Ant targets to just copy pom and jar
files to a given directory structure and then batch-deploy that.
The question remaining is, are you folks insisting on some of the things you
added on top of what Apache requires. Some things like binary reproducibility
are (from my point of view) nice to have and I couldn't see any discussion or
vote on if the project is wanting to even do reproducible releases. Another
"requirement" is that a release must be done on the CI server ... where has
this been discussed and voted on?
Why "must" a RM built with all supported build systems and not just be able to
choose the one he wants? I mean, even a RM is supposed to do the normal RC
checking before voting (I have cancelled several of my own RCs as when doing
this I noticed things).
I get the reasoning behind the CI server steps being setup years ago, but I
always understood it's an option not a mandatory rule and I think the
impediments for creating releases locally have been reduced dramatically.
Chris
Am 01.04.20, 11:00 schrieb "Yishay Weiss" <yishayj...@hotmail.com>:
Let’s keep this thread about the technical requirements. We can start a new
thread about what to do next. Although people feel like we’re going around in
circles, I personally have gained a much better grasp at what the actual issues
are. So let’s keep it concise and readable.
Thanks.
From: Piotr Zarzycki<mailto:piotrzarzyck...@gmail.com>
Sent: Wednesday, April 1, 2020 8:49 AM
To: Apache Royale Development<mailto:dev@royale.apache.org>
Subject: Re: [DISCUSS] Coming back to collect requirements for the release
process
Let's move forward with whatever you have guys :)
On Wed, Apr 1, 2020, 12:51 AM Carlos Rovira <carlosrov...@apache.org> wrote:
> Hi Alex,
>
> so I finally understand that you're in favor of all RM need to run Maven
> and ANT in the release process duplicating the effort, and in the future
> for each new build system we could add (potentially), add it too. So if we
> end having (let's imagine), 5 build systems, an RM will need to run all
the
> 5. Is that correct?
>
> But what's the purpose to do that? I don't understand at all.
>
> Release is not build (I think we're always mixing don't now why). And we
> should be able as RMs to work with just one system that ensures a release
> in good conditions, often, easily and generating the right bundle, and
> respect the rest of build systems so are available for the people
> interested to use it.
>
> Then people voting just need to revise release as always, some will decide
> to run Maven, others Ant, and will test using the SDK to build their apps
> and see if all is ok.... and that's all. SDK build with Maven is now fully
> working (or at least I'm using is in VSCode and I still didn't find
> problems), as well can be built with ANT...we already exposed how to build
> in the instructions in the wiki. So I think we have all the pieces.
>
> As someone that offer my time for release, I must say that I appreciate
all
> the work you did in the CI server, and I said that many times. And I
always
> promoted that people that wants to use it, should do it. I encourage them
> to do so. I just state that I see some problems with the stability (server
> use to hang), the fragility (is easy to break it since any change in ANT
or
> Maven, or any other new build system will break it easily), and the bugs
> that we discover that exposed that things was not working as expected and
> need fixing, since we could pass from step 7 due to problems in the
> compiler that was clearly something we break at all.
>
> So, in the same way, after my experience with the CI Server, I have clear
> that I don't want to use it, and prefer a release process more standard,
as
> the rest of Apache projects are doing to release often without much
> problem.
>
> So for me is freedom, people wanting to use, go and use it, people that
> does not want...don't worry there's other valid way (as valid as the
> hundreds of apache projects using it)
>
> In opposite to you, I want to be associated to that idea, since I trust it
> completely and is to me a sign of health of Apache Royale as an Open
Source
> project. I respect that idea and back it completely.
>
> So, if the position is to block a release as we was proposing and make
> mandatory the CI server to make a Royale release, I think I'm completely
> disagree with that position. In other way, if we can respect each other
and
> let people do releases in one or the other way, I'm all for it.
>
> I hope we stop going in circles, and do the release :)
> I said yesterday that Yishay and you can take over if you want, but still
> any of you said nothing to that.
> In the other hand, if you don't want to invest time in release, I can take
> over, but I need to be completely backed to do that
>
> Days continue passing, so just hope we can unblock all of this :)
>
> Thanks! :)
>
> Carlos
>
>
> El mar., 31 mar. 2020 a las 21:23, Alex Harui (<aha...@adobe.com.invalid>)
> escribió:
>
> > Chris is trying to find ways that the RM does not have to run the Ant
> > targets kicked off by the "release" target. That by inference, since
the
> > CI build runs those targets, the RM does not need to.
> >
> > I don't like that logic. That logic would say that none of us need to
> > test the artifacts since the CI server built ran the test on some other
> set
> > of code.
> >
> > I certainly would not want my name associated in public with such an
> idea.
> >
> > I am very frustrated by these continued attempts to eliminate Ant from
> the
> > RM's task list. I am also frustrated that the folks who continue to
> > support having more Maven and less Ant in the release process have not
> > stepped up to examine the build-tools release candidate, one of the
> > outcomes of these Maven changes that you wanted to see. Instead, this
> > effort has cost me considerable time that could have been use elsewhere.
> > It is not fair to vote for or encourage commits that cost other people
> time.
> >
> > -Alex
> >
> > On 3/31/20, 12:11 PM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
> >
> > I feel like we’re still not talking about the same thing. The
> scenario
> > as I understood it is about local changes, in which case the CI wouldn’t
> > help.
> >
> > >10) The distribution built by any build system should produce
> > distributions which can be used in any IDE
> >
> > I think your wording suggest that too.
> >
> >
> > From: Christofer Dutz<mailto:christofer.d...@c-ware.de>
> > Sent: Tuesday, March 31, 2020 9:32 PM
> > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> > Subject: Re: [DISCUSS] Coming back to collect requirements for the
> > release process
> >
> > Hi,
> >
> > well yes ... I am assuming that you have CI pipelines for
> continuously
> > checking that the builds work.
> > I wouldn't expect too many RCs to be cancelled for such reasons.
> >
> > Chris
> >
> >
> > Am 31.03.20, 19:55 schrieb "Yishay Weiss" <yishayj...@hotmail.com>:
> >
> > Chris, is this how you see it too?
> >
> > >Chris wants to put the verification of the build.xml files on
> the
> > voters.
> >
> > On 3/31/20, 10:05 AM, "Yishay Weiss" <yishayj...@hotmail.com>
> > wrote:
> >
> > > Ideally it wouldn't matter if you build it with Ant or
> Maven.
> >
> > As I understand it, the scenario is that a developer makes a
> > change and needs to package that change into a zip in order to see it in
> > his/her IDE. In order to do that s/he will need to run some Ant scripts.
> > How does the RM verify that these scripts work? I may be missing
> something…
> >
> >
> > Am 31.03.20, 17:59 schrieb "Yishay Weiss" <
> > yishayj...@hotmail.com>:
> >
> >
> > > - Some tooling could be added to validate artifacts
> > created by any form of distribution with ones built by Ant
> >
> > If I understand Alex’s concern correctly he wants Ant
> > users to see their Royale changes in any IDE. Is this tooling supposed
to
> > help with that?
> >
> >
> > Am 31.03.20, 07:48 schrieb "Piotr Zarzycki" <
> > piotrzarzyck...@gmail.com>:
> >
> > Hi Chris,
> >
> > Last comment from Alex explain exactly what release
> > process has to do
> > additional. - Did your document explanation included
> > that step? Reading it
> > I feel it includes, but I would like to make sure.
> >
> > Thanks,
> > Piotr
> >
> > On Tue, Mar 31, 2020, 6:34 AM Alex Harui
> > <aha...@adobe.com.invalid> wrote:
> >
> > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2Fr6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%2540%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689508605&sdata=AtwSURv%2FRMjilIoG6leT3Ic7B29MRJB%2FrxQidYq9xRM%3D&reserved=0
> > >
> > > A "build" (running 'ant main') produces jars and
> > swcs but does not create
> > > the same output as 'ant release' which produces
> > tar.gz and .zip files. The
> > > release artifacts are used in many IDEs and in
NPM.
> > So, IMO, in the
> > > creating of the release artifacts, the RM should
> > ensure that it is possible
> > > to create the tar.gz and .zip files via Ant, and
to
> > create at minimum, the
> > > Maven jars and swcs and hopefully a working
> > equivalent of the tar.gz and
> > > .zip via Maven using the "distribution" profile.
A
> > working "distribution"
> > > profile did not exist in the past so it is a
> > nice-to-have and not a
> > > regression if the distribution profile's tar.gz
and
> > .zip has problems. It
> > > would be a regression if it turned out the
> build.xml
> > files in the release
> > > could not build the tar.gz and .zip correctly.
> > >
> > > The only way I can think of to validate that the
> > build.xml files will do
> > > the right thing is to actually run "ant release"
at
> > some point in the
> > > release process. In which case, you might as well
> > use the resulting
> > > artifacts.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 3/30/20, 12:11 PM, "Yishay Weiss" <
> > yishayj...@hotmail.com> wrote:
> > >
> > > > Ant artifacts are reproducible by running
the
> > Ant scripts. Again,
> > > the scenario is that if an Ant user wants to try a
> > local change in an IDE
> > > or NPM we want >to ensure that they can run the
Ant
> > "release" target and
> > > get the tar.gz or .zip they need.
> > >
> > > “Again” suggests you’ve already given an
> > explanation, but I couldn’t
> > > find it. Can you expand on this scenario? If this
> is
> > the only difference
> > > you and Chris have I think it’s worth focusing on
> it.
> > >
> > > On 3/30/20, 2:17 AM, "Carlos Rovira" <
> > carlosrov...@apache.org> wrote:
> > >
> > > Hi Chris,
> > >
> > > thanks. I revise and for me is totally
fine
> > :)
> > >
> > >
> > > El lun., 30 mar. 2020 a las 9:33, Harbs (<
> > harbs.li...@gmail.com>)
> > > escribió:
> > >
> > > > Thanks for that. The Google Doc is a
> great
> > initiative!
> > > >
> > > > Harbs
> > > >
> > > > > On Mar 30, 2020, at 10:26 AM,
> Christofer
> > Dutz <
> > > christofer.d...@c-ware.de>
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > as the discussion has gone back to:
> “the
> > release should be as
> > > in the 13
> > > > steps”, I’d like to re-focus on the
> > probably more important
> > > parts:
> > > > >
> > > > > I already started writing up a list of
> > requirements and
> > > options to
> > > > achieve them:
> > > > >
> > > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit%23&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689508605&sdata=AFNrHTIsOOARCRpSl%2FVVsf5nexEt4Xacjlpxuk8DM7c%3D&reserved=0
> > > > <
> > > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689508605&sdata=1uhy44DpVU2yX9vJXD6NN1f%2BW7zPbWJEckhyDQ2hhGY%3D&reserved=0
> > > > >
> > > > > Feel free to continue.
> > > > >
> > > > > Will not participate in the other
> > discussion as it’s showing a
> > > typical
> > > > pattern of progressional-degradation,
and
> > continuing that thread
> > > will not
> > > > bring the project forward.
> > > > >
> > > > > Chris
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689508605&sdata=2p8vwn0xOZqR6BfXDDh7c%2BYXa6IwGP0RU5z%2FtdDKSpQ%3D&reserved=0
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > From: Christofer Dutz<mailto:christofer.d...@c-ware.de>
> > Sent: Tuesday, March 31, 2020 7:52 PM
> > Subject: Re: [DISCUSS] Coming back to collect requirements
> for
> > the release process
> >
> >
> > There is a difference between something working and being
> > bit-identical.
> >
> > But regarding seeing your changes in any IDE. Ideally it
> > wouldn't matter if you build it with Ant or Maven.
> > Right now the Maven distribution seems to work in the IDEs
it
> > was tested with ... so ... yes.
> >
> > So if you develop, it shouldn't matter if you build with Ant
> > or Maven
> >
> > Chris
> >
> >
> >
> >
> >
> > Am 31.03.20, 17:59 schrieb "Yishay Weiss" <
> > yishayj...@hotmail.com>:
> >
> >
> > > - Some tooling could be added to validate artifacts
> > created by any form of distribution with ones built by Ant
> >
> > If I understand Alex’s concern correctly he wants Ant
> > users to see their Royale changes in any IDE. Is this tooling supposed
to
> > help with that?
> >
> >
> > Am 31.03.20, 07:48 schrieb "Piotr Zarzycki" <
> > piotrzarzyck...@gmail.com>:
> >
> > Hi Chris,
> >
> > Last comment from Alex explain exactly what release
> > process has to do
> > additional. - Did your document explanation included
> > that step? Reading it
> > I feel it includes, but I would like to make sure.
> >
> > Thanks,
> > Piotr
> >
> > On Tue, Mar 31, 2020, 6:34 AM Alex Harui
> > <aha...@adobe.com.invalid> wrote:
> >
> > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2Fr6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%2540%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689508605&sdata=AtwSURv%2FRMjilIoG6leT3Ic7B29MRJB%2FrxQidYq9xRM%3D&reserved=0
> > >
> > > A "build" (running 'ant main') produces jars and
> > swcs but does not create
> > > the same output as 'ant release' which produces
> > tar.gz and .zip files. The
> > > release artifacts are used in many IDEs and in
NPM.
> > So, IMO, in the
> > > creating of the release artifacts, the RM should
> > ensure that it is possible
> > > to create the tar.gz and .zip files via Ant, and
to
> > create at minimum, the
> > > Maven jars and swcs and hopefully a working
> > equivalent of the tar.gz and
> > > .zip via Maven using the "distribution" profile.
A
> > working "distribution"
> > > profile did not exist in the past so it is a
> > nice-to-have and not a
> > > regression if the distribution profile's tar.gz
and
> > .zip has problems. It
> > > would be a regression if it turned out the
> build.xml
> > files in the release
> > > could not build the tar.gz and .zip correctly.
> > >
> > > The only way I can think of to validate that the
> > build.xml files will do
> > > the right thing is to actually run "ant release"
at
> > some point in the
> > > release process. In which case, you might as well
> > use the resulting
> > > artifacts.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 3/30/20, 12:11 PM, "Yishay Weiss" <
> > yishayj...@hotmail.com> wrote:
> > >
> > > > Ant artifacts are reproducible by running
the
> > Ant scripts. Again,
> > > the scenario is that if an Ant user wants to try a
> > local change in an IDE
> > > or NPM we want >to ensure that they can run the
Ant
> > "release" target and
> > > get the tar.gz or .zip they need.
> > >
> > > “Again” suggests you’ve already given an
> > explanation, but I couldn’t
> > > find it. Can you expand on this scenario? If this
> is
> > the only difference
> > > you and Chris have I think it’s worth focusing on
> it.
> > >
> > > On 3/30/20, 2:17 AM, "Carlos Rovira" <
> > carlosrov...@apache.org> wrote:
> > >
> > > Hi Chris,
> > >
> > > thanks. I revise and for me is totally
fine
> > :)
> > >
> > >
> > > El lun., 30 mar. 2020 a las 9:33, Harbs (<
> > harbs.li...@gmail.com>)
> > > escribió:
> > >
> > > > Thanks for that. The Google Doc is a
> great
> > initiative!
> > > >
> > > > Harbs
> > > >
> > > > > On Mar 30, 2020, at 10:26 AM,
> Christofer
> > Dutz <
> > > christofer.d...@c-ware.de>
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > as the discussion has gone back to:
> “the
> > release should be as
> > > in the 13
> > > > steps”, I’d like to re-focus on the
> > probably more important
> > > parts:
> > > > >
> > > > > I already started writing up a list of
> > requirements and
> > > options to
> > > > achieve them:
> > > > >
> > > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit%23&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689518600&sdata=s3GT8EtwSvaia0AVRVY0PST2RXqzXndvm9E5PhNjdSE%3D&reserved=0
> > > > <
> > > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689518600&sdata=HOZAJMG6%2B95uMDD0GdxRSs%2B8Xiin2g57cszsjmnle6k%3D&reserved=0
> > > > >
> > > > > Feel free to continue.
> > > > >
> > > > > Will not participate in the other
> > discussion as it’s showing a
> > > typical
> > > > pattern of progressional-degradation,
and
> > continuing that thread
> > > will not
> > > > bring the project forward.
> > > > >
> > > > > Chris
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C01033f7009d24597b51808d7d5a74410%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637212786689518600&sdata=72MX6CN4%2B%2BgZYTZ6BluqKI4f6MK3gYpgF6n5Koa4Ro4%3D&reserved=0
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
