Re: [DISCUSS] Coming back to collect requirements for the release process

[Piotr Zarzycki]

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  wrote:

>
> https://lists.apache.org/thread.html/r6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%40%3Cdev.royale.apache.org%3E
>
> 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"  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"  wrote:
>
> Hi Chris,
>
> thanks. I revise and for me is totally fine :)
>
>
> El lun., 30 mar. 2020 a las 9:33, Harbs ()
> 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%23data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954783626sdata=wykDg%2FGYXXpYQk2RE2Und%2BxZ7Qzr7lDXhInGuhgA4Xc%3Dreserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Feditdata=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626sdata=DsQpQRNkDnek03Iulknv2TFkE3fIRtdN%2BdB8WsaUyII%3Dreserved=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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626sdata=sZswsDv3TrjgbiXy0uIZ1RiysV91lpeaFMZvEFRR0lg%3Dreserved=0
>
>
>
>
>

Jenkins build is back to normal : royale-compiler-integration-tests #775

[apacheroyaleci]

See 

Re: [DISCUSS] Coming back to collect requirements for the release process

[Alex Harui]

https://lists.apache.org/thread.html/r6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%40%3Cdev.royale.apache.org%3E

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"  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"  wrote:

Hi Chris,

thanks. I revise and for me is totally fine :)


El lun., 30 mar. 2020 a las 9:33, Harbs () 
escribió:

> Thanks for that. The Google Doc is a great initiative!
>
> Harbs
>
> > On Mar 30, 2020, at 10:26 AM, Christofer Dutz 

> 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%23data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954783626sdata=wykDg%2FGYXXpYQk2RE2Und%2BxZ7Qzr7lDXhInGuhgA4Xc%3Dreserved=0
> <
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Feditdata=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626sdata=DsQpQRNkDnek03Iulknv2TFkE3fIRtdN%2BdB8WsaUyII%3Dreserved=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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626sdata=sZswsDv3TrjgbiXy0uIZ1RiysV91lpeaFMZvEFRR0lg%3Dreserved=0

Jenkins build is back to normal : royale-compiler #306

[apacheroyaleci]

See 

Build failed in Jenkins: royale-compiler #305

[apacheroyaleci]

See 


Changes:

[joshtynjala] JSRoyaleDocEmitter: nocollapse is needed for constants too


--
[...truncated 257.05 KB...]
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:

download-dependency:
  [get] Getting: 
https://raw.githubusercontent.com/kohsuke/args4j/master/LICENSE
  [get] To: 

 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency-closure:

download-dependency-closure:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:

download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:

download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:

download-dependency:

main:

compile:
[javac] 
:91:
 warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 204 source files to 

[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] 1 warning

main:
 [copy] Copying 1 file to 

 [copy] Copying 1 file to 

 [echo] Building 
c:/jenkins/workspace/royale-compiler/compiler-jx/lib/jsc.jar
  [jar] Building jar: 

 [echo] Building 
c:/jenkins/workspace/royale-compiler/compiler-jx/lib/mxmlc.jar
  [jar] Building jar: 

 [echo] Building 
c:/jenkins/workspace/royale-compiler/compiler-jx/lib/compc.jar
  [jar] Building jar: 

 [echo] Building 
c:/jenkins/workspace/royale-compiler/compiler-jx/lib/asdoc.jar
  [jar] Building jar: 


compiler.jx.tests:

test:

js.swc:
 [java] args:
 [java] -targets=SWF
 [java] 
-load-config=c:/jenkins/workspace/royale-compiler/compiler-jx/src/test/../../../compiler-externc/target/compile-as-config.xml
 [java] 
-output=c:/jenkins/workspace/royale-compiler/compiler-jx/src/test/../../../compiler-externc/target/js.swc
 [java] target:SWF
 [java] COMPC
 [java] Loading configuration: 

 [java] 
 [java] 391529 bytes written to 

Build failed in Jenkins: royale-compiler-integration-tests #774

[apacheroyaleci]

See 


Changes:

[joshtynjala] JSRoyaleDocEmitter: nocollapse is needed for constants too


--
[...truncated 130.16 KB...]
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:321: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const key in obj) {
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:343: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   const key = goog.object.findKey(obj, f, opt_this);
[junit]   ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:355: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const key in obj) {
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:368: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const i in obj) {
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:382: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: let declaration.
[junit]   let rv;
[junit]   ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:472: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   const val = f();
[junit]   ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:487: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const k in a) {
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:492: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const k in b) {
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:512: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   const res = {};
[junit]   ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:513: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const key in obj) {
[junit]^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:537: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   const type = goog.typeOf(obj);
[junit]   ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:542: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit] const clone = type == 'array' ? [] : {};
[junit] ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:543: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit] for (const key in obj) {
[junit]  ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:562: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   const transposed = {};
[junit]   ^
[junit] 
[junit] Mar 31, 2020 12:48:26 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] SEVERE: goog/object/object.js:563: ERROR - This language feature is 
only supported for ECMASCRIPT6 mode or better: const declaration.
[junit]   for (const key in obj) {
[junit]^

RE: [DISCUSS] Coming back to collect requirements for the release process

[Yishay Weiss]

> 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"  wrote:

Hi Chris,

thanks. I revise and for me is totally fine :)


El lun., 30 mar. 2020 a las 9:33, Harbs () escribió:

> Thanks for that. The Google Doc is a great initiative!
>
> Harbs
>
> > On Mar 30, 2020, at 10:26 AM, Christofer Dutz 

> 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%23data=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=f%2BDwNxJXznUKPyihwBAEoAxE7g%2Fl%2BGW8jkWfwlFqSHQ%3Dreserved=0
> <
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Feditdata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=Ss0aebR6U%2FAl6OYfj%2Flim1nYx3XAp6zNqm1E87rgczQ%3Dreserved=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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=6%2Fg%2FGsy67%2FK8Ard9dXecaKBJjHrED8%2BX9pqT4KwRqHk%3Dreserved=0

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

I did a quick test, and I can confirm that a public variable will not be
renamed if a public getter with the same name exists on a different class.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala 
wrote:

> Thanks for the info about Object.defineProperties(). That could be a way
> to provide a workaround that doesn't mess too much with other stuff.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui 
> wrote:
>
>>
>>
>> On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:
>>
>> We can walk the AST if we have the source code. However, if an MXML
>> class
>> gets compiled into a SWC, I don't think there's a way to figure out
>> which
>> properties are being set in MXML from the definitions alone. When I
>> was
>> investigating some things, I tried the AST walk until I realized that
>> it
>> only worked in my app project, and not with the classes that I was
>> using
>> from framework SWCs.
>>
>> One possibility is that the compiler scans every JS file and looks for
>> the MXMLDescriptor and scans it for strings.  Also have to look for the
>> properties array as well.
>>
>> I might actually end up looking at adding an option to convert public
>> vars
>> into getters/setters first. Should be easier than some of the
>> alternatives,
>> which I can dig into more later.
>>
>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
>> through the entire compilation, not just within the file being visited.  In
>> fact, I'm not even sure it has to be Object.defineProperties.  It looks
>> like there is some criteria for being a global structure.  So to me, it
>> looks like you can prevent a rename, not only by swapping in a legitimate
>> getter/setter for the public var, but also by having some global structure,
>> possibly in an Object.defineProperties attached to the app that defines a
>> bunch of empty properties on some never-to-be-used object and then Closure
>> will not rename those properties on other objects.
>>
>> Of course, I could be wrong, but that's what I think I've seen.  I think
>> I saw that including some class with a getter/setter would cause properties
>> in other classes that use the same property name to not be renamed.
>>
>> HTH,
>> -Alex
>>
>>
>>

Re: [DISCUSS] Coming back to collect requirements for the release process

[Piotr Zarzycki]

Hi Alex,

But I do see that Chris took into account that part, unless I don't
understand something.

Thanks,
Piotr

pon., 30 mar 2020 o 17:22 Alex Harui  napisał(a):

> This looks like your original offering and does not include my
> recommendations.
>
> I believe the document is missing the requirement that the process of
> creating the Ant release artifacts must verify that the 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.
>
> Thanks,
> -Alex
>
> On 3/30/20, 2:17 AM, "Carlos Rovira"  wrote:
>
> Hi Chris,
>
> thanks. I revise and for me is totally fine :)
>
>
> El lun., 30 mar. 2020 a las 9:33, Harbs ()
> 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%23data=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=f%2BDwNxJXznUKPyihwBAEoAxE7g%2Fl%2BGW8jkWfwlFqSHQ%3Dreserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Feditdata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=Ss0aebR6U%2FAl6OYfj%2Flim1nYx3XAp6zNqm1E87rgczQ%3Dreserved=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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=6%2Fg%2FGsy67%2FK8Ard9dXecaKBJjHrED8%2BX9pqT4KwRqHk%3Dreserved=0
>
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: [Vote] Release Compiler Build Tools 1.2.0

[Carlos Rovira]

Hi,

I was thinking in create another release since Chris discover this morning
that jburg and build-tools has not reproducible builds activated in maven.
So my impression is that we never had it before.

As I said in the other email, I think Alex and Yishay should take over the
release process since there's many objections with the current
proposed release process, so don't think we should all lose more time, and
I left to them to take over and make the release. So better cancel this one
and let them to do as they prefer. Will be sending a cancel email now.

Please take into account that some people in social networks was asking
where they will get a new release, so I think we should not delay too much
about this. Maybe nor much people is expecting it these day, but maybe is
worth to translate from what I see in our social networks.

Thanks! :)

Carlos



El dom., 29 mar. 2020 a las 15:19, Carlos Rovira ()
escribió:

> Many thanks Chris for the PRs and pointers so I can continue learning
> about the release project and improving :)
> Will try chain signatures with other people
>
> El dom., 29 mar. 2020 a las 14:03, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
>> +1 (Non-Binding)
>>
>> Chris
>>
>> - All artifacts downloaded: OK
>> - Verified the signature: OK (No trust root chain however ... you should
>> go to a key-signing event with other Apache folks)
>> gpg --verify compiler-build-tools-1.2.0-source-release.zip.asc
>> compiler-build-tools-1.2.0-source-release.zip
>> - Signature refers to an apache email: OK
>> - Validated the SHA512 hash: OK
>> shasum -a512 compiler-build-tools-1.2.0-source-release.zip
>> - Unzips correctly: OK
>> - Check existence of LICENSE and NOTICE files: OK (README and
>> RELEASE_NOTES are not mandatory)
>> - Check contents of NOTICE file: MINOR (See notes at end)
>> - All files have Apache headers in them: MINOR (See notes at end)
>> - No SNAPSHOT references: OK
>> - Build with "mvn clean install": OK
>>
>>
>> NOTES:
>>
>> NOTICE: It seems we are missing the attribution to Adobe, however the
>> initial commit already had the default Apache header with no attributions
>> to Adobe and it's just one file: UnknownTreePatternInputOutput ... usually
>> one file doesn't require attribution in the NOTICE file, so I think it's ok
>> to proceed. I added a PR which will add Adobe in the NOTICE files in future
>> releases.
>>
>> Headers: It seems when I initially wrote some of the code I used the 3rd
>> party Apache header ... I created a PR to fix all of these files. However
>> this shouldn't be considered a blocker to the release.
>>
>>
>> Am 28.03.20, 17:55 schrieb "Carlos Rovira" :
>>
>> +1 (Binding)
>>
>> - Package:
>>
>> https://dist.apache.org/repos/dist/dev/royale/compiler-build-tools/1.2.0/compiler-build-tools-1.2.0-source-release.zip
>> - Java: 1.8.0_181
>> - OS: Mac OS X x86_64 10.15.3
>> - Signatures and hashes fine
>> - No unexpected binary files
>> - Can compile from source with test
>> - Check In actual Apache Royale development branch
>> - Tested Tour De Jewel example working as expected
>>
>>
>> El sáb., 28 mar. 2020 a las 12:23, Carlos Rovira (<
>> carlosrov...@apache.org>)
>> escribió:
>>
>> > Ok Thanks Chris,
>> > I think now is fixed :)
>> >
>> > El sáb., 28 mar. 2020 a las 11:26, Christofer Dutz (<
>> > christofer.d...@c-ware.de>) escribió:
>> >
>> >> Hi Carlos,
>> >>
>> >> not checked the release yet however Apache requires sha512
>> checksums and
>> >> doesn't like md5 and sha1 ...
>> >> Please check that you're sort of doing it like described here:
>> >> https://plc4x.apache.org/developers/release/release.html
>> >>
>> >> Chris
>> >>
>> >> Am 28.03.20, 11:16 schrieb "Carlos Rovira" <
>> carlosrov...@apache.org>:
>> >>
>> >> Hi all,
>> >>
>> >> sorry the link to the 1.2.0 artifacts was wrong. The right one
>> is
>> >> this:
>> >>
>> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/royale/compiler-build-tools/1.2.0/
>> >>
>> >> Thanks
>> >>
>> >> Carlos
>> >>
>> >>
>> >>
>> >> El sáb., 28 mar. 2020 a las 11:00, Carlos Rovira (<
>> >> carlosrov...@apache.org>)
>> >> escribió:
>> >>
>> >> > Hi,
>> >> >
>> >> > This is the vote for the 1.2.0 release of Compiler Build
>> Tools.
>> >> >
>> >> > We solved some issues needed for reproducible releases of
>> Apache
>> >> Royale in
>> >> > this compiler build tools release:
>> >> >
>> >> > The release candidate can be found in this staging
>> repository:
>> >> >
>> >> >
>> >>
>> https://dist.apache.org/repos/dist/release/royale/compiler-build-tools/1.2.0/
>> >> >
>> >> > Before voting please review the section,'What are the ASF
>> >> requirements on
>> >> > approving a 

[Cancel] Release Compiler Build Tools 1.2.0

[Carlos Rovira]

Hi,

this is the cancellation thread.

Thanks

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [DISCUSS] Coming back to collect requirements for the release process

[Carlos Rovira]

Hi Alex,

I think the best is that you and Yishay take over the process of release
Apache Royale, to avoid the large process of emails that I think is not
carrying us to get the work done.

Thanks



El lun., 30 mar. 2020 a las 17:22, Alex Harui ()
escribió:

> This looks like your original offering and does not include my
> recommendations.
>
> I believe the document is missing the requirement that the process of
> creating the Ant release artifacts must verify that the 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.
>
> Thanks,
> -Alex
>
> On 3/30/20, 2:17 AM, "Carlos Rovira"  wrote:
>
> Hi Chris,
>
> thanks. I revise and for me is totally fine :)
>
>
> El lun., 30 mar. 2020 a las 9:33, Harbs ()
> 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%23data=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=f%2BDwNxJXznUKPyihwBAEoAxE7g%2Fl%2BGW8jkWfwlFqSHQ%3Dreserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Feditdata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=Ss0aebR6U%2FAl6OYfj%2Flim1nYx3XAp6zNqm1E87rgczQ%3Dreserved=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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=6%2Fg%2FGsy67%2FK8Ard9dXecaKBJjHrED8%2BX9pqT4KwRqHk%3Dreserved=0
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [DISCUSS] Coming back to collect requirements for the release process

[Alex Harui]

This looks like your original offering and does not include my recommendations.

I believe the document is missing the requirement that the process of creating 
the Ant release artifacts must verify that the 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.

Thanks,
-Alex

On 3/30/20, 2:17 AM, "Carlos Rovira"  wrote:

Hi Chris,

thanks. I revise and for me is totally fine :)


El lun., 30 mar. 2020 a las 9:33, Harbs () escribió:

> Thanks for that. The Google Doc is a great initiative!
>
> Harbs
>
> > On Mar 30, 2020, at 10:26 AM, Christofer Dutz 

> 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%23data=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=f%2BDwNxJXznUKPyihwBAEoAxE7g%2Fl%2BGW8jkWfwlFqSHQ%3Dreserved=0
> <
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Feditdata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=Ss0aebR6U%2FAl6OYfj%2Flim1nYx3XAp6zNqm1E87rgczQ%3Dreserved=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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C1a18c979ab3c41569f3c08d7d48b36e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211566762921662sdata=6%2Fg%2FGsy67%2FK8Ard9dXecaKBJjHrED8%2BX9pqT4KwRqHk%3Dreserved=0

Re: [DISCUSS] Coming back to collect requirements for the release process

[Carlos Rovira]

Hi Chris,

thanks. I revise and for me is totally fine :)


El lun., 30 mar. 2020 a las 9:33, Harbs () escribió:

> Thanks for that. The Google Doc is a great initiative!
>
> Harbs
>
> > On Mar 30, 2020, at 10:26 AM, Christofer Dutz 
> 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://docs.google.com/document/d/1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg/edit#
> <
> https://docs.google.com/document/d/1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg/edit
> >
> > 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
http://about.me/carlosrovira

Re: Releasing: Finally giving up

[Greg Dove]

There were issues identified with the original process as Chris and Carlos
worked through it that prevented them from completing it. Exposing any
problems in that itself is helpful, but I also observed that it was a very
frustrating discovery by Chris and Carlos, and we should be thankful it is
now known.

-The timestamp issue. Alex, you already suggested this was perhaps an issue
with the original process, and we are waiting to see if DST alignment is
the 'fix' (if it is, it still needs a real fix, we all agree).
-Chris mentioned that the compiler output is also inconsistent which makes
binary reproducibles a problem in the swf part of swcs. Perhaps there are
some settings for this that are not apparent to address it. In a swc, the
xml content/ordering seems to match which also corresponds to classes being
output in the same order in the bytecode of the swf content. But the class
members inside the bytecode for each class can be in a different order.
-there were also differences in the actual content between CI server and
local for nodejs externs, for unknown reasons

If there are indeed problems with the 'standard' against which the
alternative needs to be assessed then nobody is 'on the hook' or 'off the
hook'. So far it just means the starting point does not seem to be a
reliable reference implementation to attempt to match in the first place.
Let's focus on fixing that.




On Mon, Mar 30, 2020 at 8:48 AM Carlos Rovira 
wrote:

> Hi Alex and Yishay,
>
> as compiler-build-tools is released (hope others will have the time to test
> and vote it soon), let me know if I finally start 0.9.7.
> I'll be ok with whatever you decided.
>
> Thanks! :)
>
> Carlos
>
>
>
> El dom., 29 mar. 2020 a las 21:43, Alex Harui ()
> escribió:
>
> > I share your concern with the precedent being set here.  I don't think
> the
> > folks behind these changes should be off the hook for getting the CI
> steps
> > to work again.  Otherwise, any of us can go break stuff under the
> rationale
> > of making something else better and let someone else deal with the mess.
> >
> > Still, certain things have to be done.  I think there is consensus that a
> > release should be doable on a local machine or the CI server.  So,
> > hopefully Carlos is off to not just create an RC, but also document the
> > steps required to do this end-to-end on a local machine by actually doing
> > it.  That made sense while waiting for Sunday to roll around to see if
> that
> > gets past the timestamp issue in the SWCs.
> >
> > If you have time to tweak the CI steps and see if they work to help get
> > them working again, feel free to do so.  I will hopefully have cycles to
> > help.   The credentials are in the private@ archives.  I recommend
> > creating a completely new set of steps by cloning the old jobs as needed.
> > For example we won't need the 1a (utils) step (or probably the other
> utils
> > steps) anymore.  A differently named step or two is needed to match what
> > Carlos did for the compiler-build-tools release.
> >
> > If you can help them resolve the SWC timestamp issue, I hope to see the
> > folks who committed to restoring these steps back to working order will
> > complete that task.
> >
> > My 2 cents,
> > -Alex
> >
> > On 3/29/20, 10:43 AM, "Yishay Weiss"  wrote:
> >
> > I guess I misunderstood. I thought we were only talking about the
> > compiler-build-tools release.
> >
> > Carlos, I of course don’t mind you doing the work. I have plenty on
> my
> > plate. I’m concerned with the process. Although I haven’t been following
> > the threads closely enough to understand the whole technical debate, I
> did
> > understand that Alex and others have expressed reservations (e.g. should
> > the release actually use ant to verify the ant build). Has this debate
> > reached a conclusion that enjoys a consensus? If not, there should
> probably
> > be a vote. I don’t want to encourage a dynamic where debates are won by
> > unilateral action.
> >
> > If everyone feels comfortable with Carlos releasing with mvn, then I
> > won’t object. If there are reservations then I’d still like to give it
> > another week, and see if an RM newbie like me can apply the process
> > suggested by Alex.
> >
> > Thanks.
> >
> > From: Carlos Rovira
> > Sent: Sunday, March 29, 2020 7:34 PM
> > To: Apache Royale Development
> > Subject: Re: Releasing: Finally giving up
> >
> > Hi Yishay,
> >
> > I think we were all in agreement so I'll make the release. Right now
> > we're
> > voting the compiler-build-tools 1.2.0 release
> > As soon as this is approved, I'll continue withe 0.9.7 release.
> >
> > compiler build tools 1.2.0 is done to release some small changes for
> > reproducible builds and check the optional path about to release
> > compiler
> > build tools or jburg versions in the future (that should be very
> rare).
> >
> > Thanks
> >
> >
> > 

Re: [DISCUSS] Coming back to collect requirements for the release process

[Harbs]

Thanks for that. The Google Doc is a great initiative!

Harbs

> On Mar 30, 2020, at 10:26 AM, Christofer Dutz  
> 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://docs.google.com/document/d/1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg/edit#
> 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
> 

[DISCUSS] Coming back to collect requirements for the release process

[Christofer Dutz]

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://docs.google.com/document/d/1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg/edit#
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