Hi Yishay, most of us think already discussed many. I think it's clear what all of us want. What we're requesting is who's going to do. I left the position to Alex and you, but still we don't have a clear answer of "Yes, I'll take over" or "Not, left to you guys". Can we have some clear response to that?
Thanks! :) El mié., 1 abr. 2020 a las 11:00, Yishay Weiss (<yishayj...@hotmail.com>) escribió: > 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 > > > > -- Carlos Rovira http://about.me/carlosrovira
