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" <[email protected]> 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:[email protected]> Sent: Tuesday, March 31, 2020 9:32 PM To: [email protected]<mailto:[email protected]> 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" <[email protected]>: 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" <[email protected]> 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" <[email protected]>: > - 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" <[email protected]>: 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> wrote: > > Hi Chris, > > thanks. I revise and for me is totally fine :) > > > El lun., 30 mar. 2020 a las 9:33, Harbs (<[email protected]>) > escribió: > > > Thanks for that. The Google Doc is a great initiative! > > > > Harbs > > > > > On Mar 30, 2020, at 10:26 AM, Christofer Dutz < > [email protected]> > > 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:[email protected]> 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" <[email protected]>: > - 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" <[email protected]>: 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> wrote: > > Hi Chris, > > thanks. I revise and for me is totally fine :) > > > El lun., 30 mar. 2020 a las 9:33, Harbs (<[email protected]>) > escribió: > > > Thanks for that. The Google Doc is a great initiative! > > > > Harbs > > > > > On Mar 30, 2020, at 10:26 AM, Christofer Dutz < > [email protected]> > > 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 > > > > >
