You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Christofer Dutz <ch...@c-ware.de> on 2020/03/18 15:37:41 UTC
Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Ok ... as it sort of feels silly to not respond to this list, but read it ... here goes ;-)
Shouldn't the metric be: "does it bring the project forward?" and less "how much time did it cost to get here?"
In PLC4X I recently deleted code that took me more than 3/4 of a year to write in more than full-time work. No commit felt better as it improved things greatly and what we replaced it with, was a giant leap for the project.
So if you folks could explain what the refactoring I did some time ago broke ...
And perhaps let me explain the reason for doing it in the first place:
I really loved and still love the productivity I had with Apache Flex. I was consumed with counting and shifting bits, however knowing I need a frontend eventually. I was hoping that Royale was going to be that option. However I did notice with worries how long it took to get new releases out the door and hearing rumors about how many people invested so much time and some still failed. So I offered my assistance and had a look at the build. Being an expert in this particular area, I did notice some configuration "problems" or "misconfigurations", which I fixed. Usually if you need something special for some reason it's a good practice to write a comment to it in order for the person viewing the code to know the implications and reasoning behind this.
You can't expect every newcomer to parse the last few years of discussions before contributing.
Another reason was that I remembered that one of the "objections" to Maven was, that Maven couldn't do reproducible builds. So as the latest versions of the core maven plugins were updated to support this, I thought, perhaps this way we could get a stable release process.
From a Maven point of view the updated Maven build is now rock-solid. Releasing it would require two timely separated sessions and 3 commands in total and would be done on the developer machine.
1) Create the release branch
2) Prepare and do the release
The issues you folks were having ... I can't really confirm them ... Just to day I did a check of how many Apache project use which build tool. The result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that broken, I guess we would be hearing a lot more from the other projects. And I am not hearing any complaints at all.
If the distributions are currently not 100% match of the Ant ones, I would like to help to make them one. Just tell me what the difference is and it'll be done in no-time. However it's hard to fix something you don't know what's broken.
Also do I not quite understand why a jar used in Ant has to be built by Ant ... in general the jars should be identical. I know that maven saves some additional information in the pom (Actually storing the pom and the values properties had when it was built in the jar, which I think is a great thing for reproducibility). Perhaps disabling this could make them identical. And as soon as that's the case, I don't really see the point in building them twice. Do you agree?
And no worries, I am not interested in joining the project again ... I want to help the project be able to get releases out because I would like to use them. After that's done I'm happy to disappear again, if you wish that I do.
So far all the projects I have helped with their builds are firing out releases like machine-guns ... let me help you folks do so too.
Chris
Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <pi...@gmail.com>:
Btw. I truly doubt that it would be bigger than time which was invested in
building this whole release process.
śr., 18 mar 2020 o 12:41 Piotr Zarzycki <pi...@gmail.com>
napisał(a):
> Carlos,
>
> Why it is so huge effort ? What was broken so much that you are talking
> about huge effort ?
>
> śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi Piotr,
>>
>> as I responded before, I think that will be a huge task, in effort and
>> time, and a task that can be easily broken again as any other one
>> introduces new changes, what is something will happen for sure as we
>> evolve. So what I'm offering is my time to be used in a way that can allow
>> us to have a more reliable workflow. If I work on trying to fix as it's
>> now, I probably will not succeed since I already tried for several hours
>> and days (you can check emails around 19 or 20th Nov I think), and nothing
>> of my tries could make a difference. Instead, I'm think taking a big
>> different approach can make a difference. I can be wrong, but in that
>> case,
>> we'll know for sure that the way to go is the current one.
>>
>>
>> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>> > Carlos,
>> >
>> > In the other ways you are not going to fix current steps and release new
>> > version of SDK ?
>> >
>> >
>> >
>> > śr., 18 mar 2020 o 10:39 Carlos Rovira <ca...@apache.org>
>> > napisał(a):
>> >
>> > > Hi all and thanks for your responses:
>> > >
>> > > @greg, yes the plan I point is to do research to try a new way and see
>> > > where we go. At the end, we don't get it, it will be our
>> responsibility
>> > and
>> > > our time.
>> > >
>> > > @yishay, I think you state a concrete but very real issue. I think the
>> > work
>> > > done by Alex was amazing (no doubt here), but I'm afraid, as much as
>> it
>> > > pains me to say it, that it does not solve the problem you state and
>> the
>> > > proof is that only Piotr tried to use the process and it was not easy
>> and
>> > > then when fixing other things, it has broken with some ease.
>> > >
>> > > @om, as I said in the initial email. There's no war anymore between
>> Maven
>> > > and ANT. We all want both, and I'm using both when developing Royale
>> to
>> > > test. As well I continually know more about how things are done in
>> Maven.
>> > > My position is just that we need to separate concerns. One thing is to
>> > have
>> > > both systems for developers and user to use (Maven and ANT), but my
>> point
>> > > is that Releasing should just involve Maven, since is more suite for
>> > > releasing at Apache and CIs, and ensure Ant continue working as
>> expected.
>> > > So no one wants one over the other, or remove one of them. That's not
>> the
>> > > problem anymore.
>> > >
>> > > @piotr, I think your experience is very important, since you were the
>> > only
>> > > one that do the full process. My guess is that removing ANT from the
>> > > release process will remove completely all the pain with such complex
>> > > process and we all be able release from our own machines without
>> having
>> > > problems with complex task, uploading artifacts to a.o and more. We
>> just
>> > > need to ensure ANT still can be build exactly as before, and continue
>> to
>> > > produce the same.
>> > >
>> > > So in the end, we can stick with the old process, or try another
>> > different
>> > > approach to it build over standards. That means Chris and I will be
>> using
>> > > our times not yours. If we succeed, your test of the new approach will
>> > need
>> > > to ensure all the prerequisites and be lot more simpler. If we don't
>> get
>> > to
>> > > that and fail in the process, just announce here and we can continue
>> in
>> > the
>> > > old process.
>> > >
>> > > That's my proposal (that will need to be consensuated first here and
>> then
>> > > with Chris)
>> > >
>> > > Thanks
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
>> (<aharui@adobe.com.invalid
>> > >)
>> > > escribió:
>> > >
>> > > >
>> > > >
>> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <bi...@gmail.com>
>> > > wrote:
>> > > >
>> > > > My 2 cents:
>> > > >
>> > > > I don't think we need to go back to the Ant vs Maven discussion.
>> > If
>> > > > the
>> > > > Maven build/stage/release scripts works flawlessly, an Ant task
>> can
>> > > > simply
>> > > > call it. There is no reason both cannot be worked on
>> continuously.
>> > > > In the
>> > > > same way, if Maven users want, they can call Ant scripts as
>> needed.
>> > > >
>> > > > Why do both camps want the other way to go away?
>> > > >
>> > > > I don't want one to go away. I want to use Maven for what it is
>> good
>> > for
>> > > > and Ant for what it is good for.
>> > > >
>> > > > For example, we also publish to NPM as part of the release.
>> There
>> > is
>> > > a
>> > > > node.js script that gets called from the Ant script during the
>> > > release
>> > > > process. The node.js script is a black box as far as the Ant
>> > script
>> > > is
>> > > > concerned.
>> > > >
>> > > > That said, Carlos if you think you can get a release done with
>> just
>> > > > Maven,
>> > > > please go ahead and give it a shot. From what I remember, the
>> > Maven
>> > > > part
>> > > > of the build/release was the issue and not the Ant portions. We
>> > all
>> > > > would
>> > > > love to see improvements there.
>> > > >
>> > > > Alex, you say that Carlos did not work in the trenches during
>> the
>> > > > release
>> > > > process, but are objecting (I think, if I understand your email
>> > > > correctly)
>> > > > to him wanting to work now. That seem contradictory, IMHO.
>> > > >
>> > > > I'm saying that if Carlos/Chris go back to the Maven Release Plugin
>> > > > process, it will likely bring us back to the same problems we
>> created
>> > the
>> > > > CI steps to work around. So why go through all of that again?
>> > > >
>> > > > Like Piotr just posted, Carlos should get in the trenches and get
>> the
>> > CI
>> > > > steps to work with the new Maven poms. Not acknowledging that
>> there
>> > > have
>> > > > been past problems using the process they propose is going to
>> result in
>> > > > more time wasted.
>> > > >
>> > > > -Alex
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > > --
>> > > Carlos Rovira
>> > > http://about.me/carlosrovira
>> > >
>> >
>> >
>> > --
>> >
>> > Piotr Zarzycki
>> >
>> > Patreon: *https://www.patreon.com/piotrzarzycki
>> > <https://www.patreon.com/piotrzarzycki>*
>> >
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Chris,
Of course, it would be good to be able to verify a staged build. And
> jusding from Royales recent vote threads, I would doubt that a single PMC
> who voted actually built the SDK from the sources locally and checked the
> staged release-candidate for binary equality ... at least I couldn't find
> any reference to that in the vote emails.
Actually I'm always doing that, cause our projects are using Maven, so yea
it was tested even if I didn't mention it.
śr., 18 mar 2020 o 17:56 Carlos Rovira <ca...@apache.org> napisał(a):
> Hi Om,
>
> thanks, but I'd like to get the green light for Alex, Piotr, and others,
> since is lots of work.
> I think if we get that to work, we all get benefit. and If we don't get
> that, we can retire our propose and concentrate in the actual process. I
> don't think anyone should get attacked or be afraid of breaking even more
> things.
>
> we just can do our task, complete and people will try if we are wrong or
> not. Maybe Alex or others will surprise that the new way to do things solve
> all the old problems and remove lots of hours for all of us in the future.
>
> But we need the rest of consensus, since is not something we could do
> quick, it will require some time and hard work ahead to work on our own to
> finish and not find consensus although we succeed.
>
> Thanks for your words! :)
>
> Carlos
>
>
>
>
>
> El mié., 18 mar. 2020 a las 17:50, OmPrakash Muppirala (<
> bigosmallm@gmail.com>) escribió:
>
> > Carlos, Chris,
> >
> > There is nothing stopping you from building something from scratch.
> There
> > is no need to convince anyone. Please start committing.
> >
> > I think Alex and others have made their points clearly. I don't see a
> > reason to continue rehashing the same points over and over.
> >
> > As long as the current Ant based build/release is not broken, everyone
> > should be happy, or at least learn to live with it.
> >
> > That said, how can I help with your effort 😊?
> >
> > Thanks,
> > Om
> >
> >
> > On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <ca...@apache.org>
> > wrote:
> >
> > > Hi Alex,
> > >
> > > El mié., 18 mar. 2020 a las 17:12, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > > > The proposal I'm seeing takes us back a few years to when others
> > > couldn’t
> > > > create a release.
> > >
> > >
> > > As I posted in the other thread just a few minutes ago, it's not about
> to
> > > go back and coninue. Our propose is to create something new from
> scratch,
> > > so all that old problems should just gone.
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Om,
thanks, but I'd like to get the green light for Alex, Piotr, and others,
since is lots of work.
I think if we get that to work, we all get benefit. and If we don't get
that, we can retire our propose and concentrate in the actual process. I
don't think anyone should get attacked or be afraid of breaking even more
things.
we just can do our task, complete and people will try if we are wrong or
not. Maybe Alex or others will surprise that the new way to do things solve
all the old problems and remove lots of hours for all of us in the future.
But we need the rest of consensus, since is not something we could do
quick, it will require some time and hard work ahead to work on our own to
finish and not find consensus although we succeed.
Thanks for your words! :)
Carlos
El mié., 18 mar. 2020 a las 17:50, OmPrakash Muppirala (<
bigosmallm@gmail.com>) escribió:
> Carlos, Chris,
>
> There is nothing stopping you from building something from scratch. There
> is no need to convince anyone. Please start committing.
>
> I think Alex and others have made their points clearly. I don't see a
> reason to continue rehashing the same points over and over.
>
> As long as the current Ant based build/release is not broken, everyone
> should be happy, or at least learn to live with it.
>
> That said, how can I help with your effort 😊?
>
> Thanks,
> Om
>
>
> On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > El mié., 18 mar. 2020 a las 17:12, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > The proposal I'm seeing takes us back a few years to when others
> > couldn’t
> > > create a release.
> >
> >
> > As I posted in the other thread just a few minutes ago, it's not about to
> > go back and coninue. Our propose is to create something new from scratch,
> > so all that old problems should just gone.
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
El mié., 18 mar. 2020 a las 18:59, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I'm trying to avoid having Carlos and Chris spend a lot of time tossing
> out something that worked and replacing it with something that didn't work
> in the past.
I think this is the third time I post this, in this and other thread, but
here comes again :)
We are not trying to go back to the same process in time and try to make it
work or fix it. As Chris said that will not say so much of us.
This is a completely new effort with other approach but needs to fit a
series of concrete results we already talked about.
As I said, although you now think is not possible, maybe you can be
confident in us and let us try. If we finally don't succeed, you'll be
proven that was not possible, but if there's a change we get a really more
easier process, don't you think is worth the effort?
In the other hand, Chris is about to fix the CI. Want to thanks him, since
I must say I found it impossible to do myself.
Thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Josh,
you're right in all what you said. You resume all what we want to do.
Thanks :)
El mié., 18 mar. 2020 a las 20:27, Josh Tynjala (<jo...@bowlerhat.dev>)
escribió:
> As I said, I want them to restore the current process to working order
> before they start — because their work should not be assumed to be a
> guaranteed success. It seems like that's what they plan to do, and they
> have acknowledged that their plan may not work out.
>
> As I understand it, one part of the Apache Way is welcoming contributors to
> scratch their own itch. Various forms of this discussion have been bubbling
> up again and again for years. At some point, we need to acknowledge that
> this is a sign that we have failed to follow the Apache Way. I believe that
> it's beyond time for Carlos and Chris to try out their plan and I'm excited
> to see how it goes.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Mar 18, 2020 at 10:59 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > I'm trying to avoid having Carlos and Chris spend a lot of time tossing
> > out something that worked and replacing it with something that didn't
> work
> > in the past. How often is that a good decision? What makes it hard is
> > that there is a chance it will work for them, and then it won't work for
> > others. That is the lesson we learned the hard way. So we won't know
> how
> > good it is until someone else tries it and runs into the same issues we
> had
> > before. Note that the two people who have actually cut a release want to
> > just get the current process to work again. Everyone else is just
> talking
> > from theory, not reality.
> >
> > And it will all be moot if we don't get the current process fixed and a
> > release out ASAP.
> >
> > I only found build instructions at the wiki link that Carlos provided,
> not
> > release instructions. It made me look at the royale-compiler pom and it
> > appears that the compiler-build-tools and compiler-jburg-types project
> > builds have been removed. So I am not clear on how to build those two
> > artifacts with Maven should we need to change them in the future. This
> is
> > not raising my level of confidence in their plans at all. It is not fair
> > to toss out important things and then claim things are simpler.
> >
> > -Alex
> >
> > On 3/18/20, 10:25 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
> >
> > Agreed. Just do it! You shouldn't need consensus here. If it's as
> much
> > better as you claim it will be, I don't see anyone refusing to switch
> > to
> > the new process. However, if you insist on consensus, let this be my
> > +1.
> >
> > However, someone else may want to try doing a release with the old
> > process
> > in the meantime. With that in mind, before you get started on the new
> > process, you should ensure that the old one is not still broken from
> > the
> > recent Maven build changes. (It sounds like Chris is already trying
> to
> > fix
> > this, so great!)
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=p3GFZuKOAdosdIUUK6YQ7pyrQLAGCrdulrcyfAHUq%2FE%3D&reserved=0
> > >
> >
> >
> > On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <
> > bigosmallm@gmail.com>
> > wrote:
> >
> > > Carlos, Chris,
> > >
> > > There is nothing stopping you from building something from scratch.
> > There
> > > is no need to convince anyone. Please start committing.
> > >
> > > I think Alex and others have made their points clearly. I don't
> see
> > a
> > > reason to continue rehashing the same points over and over.
> > >
> > > As long as the current Ant based build/release is not broken,
> > everyone
> > > should be happy, or at least learn to live with it.
> > >
> > > That said, how can I help with your effort 😊?
> > >
> > > Thanks,
> > > Om
> > >
> > >
> > > On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <
> carlosrovira@apache.org
> > >
> > > wrote:
> > >
> > > > Hi Alex,
> > > >
> > > > El mié., 18 mar. 2020 a las 17:12, Alex Harui
> > (<aharui@adobe.com.invalid
> > > >)
> > > > escribió:
> > > >
> > > > > The proposal I'm seeing takes us back a few years to when
> others
> > > > couldn’t
> > > > > create a release.
> > > >
> > > >
> > > > As I posted in the other thread just a few minutes ago, it's not
> > about to
> > > > go back and coninue. Our propose is to create something new from
> > scratch,
> > > > so all that old problems should just gone.
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=N6loQSFF1p1N3AS0%2FDoObELUjgRCMV9I0ylQyuYL4Y8%3D&reserved=0
> > > >
> > >
> >
> >
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
As I said, I want them to restore the current process to working order
before they start — because their work should not be assumed to be a
guaranteed success. It seems like that's what they plan to do, and they
have acknowledged that their plan may not work out.
As I understand it, one part of the Apache Way is welcoming contributors to
scratch their own itch. Various forms of this discussion have been bubbling
up again and again for years. At some point, we need to acknowledge that
this is a sign that we have failed to follow the Apache Way. I believe that
it's beyond time for Carlos and Chris to try out their plan and I'm excited
to see how it goes.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Mar 18, 2020 at 10:59 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> I'm trying to avoid having Carlos and Chris spend a lot of time tossing
> out something that worked and replacing it with something that didn't work
> in the past. How often is that a good decision? What makes it hard is
> that there is a chance it will work for them, and then it won't work for
> others. That is the lesson we learned the hard way. So we won't know how
> good it is until someone else tries it and runs into the same issues we had
> before. Note that the two people who have actually cut a release want to
> just get the current process to work again. Everyone else is just talking
> from theory, not reality.
>
> And it will all be moot if we don't get the current process fixed and a
> release out ASAP.
>
> I only found build instructions at the wiki link that Carlos provided, not
> release instructions. It made me look at the royale-compiler pom and it
> appears that the compiler-build-tools and compiler-jburg-types project
> builds have been removed. So I am not clear on how to build those two
> artifacts with Maven should we need to change them in the future. This is
> not raising my level of confidence in their plans at all. It is not fair
> to toss out important things and then claim things are simpler.
>
> -Alex
>
> On 3/18/20, 10:25 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Agreed. Just do it! You shouldn't need consensus here. If it's as much
> better as you claim it will be, I don't see anyone refusing to switch
> to
> the new process. However, if you insist on consensus, let this be my
> +1.
>
> However, someone else may want to try doing a release with the old
> process
> in the meantime. With that in mind, before you get started on the new
> process, you should ensure that the old one is not still broken from
> the
> recent Maven build changes. (It sounds like Chris is already trying to
> fix
> this, so great!)
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=p3GFZuKOAdosdIUUK6YQ7pyrQLAGCrdulrcyfAHUq%2FE%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <
> bigosmallm@gmail.com>
> wrote:
>
> > Carlos, Chris,
> >
> > There is nothing stopping you from building something from scratch.
> There
> > is no need to convince anyone. Please start committing.
> >
> > I think Alex and others have made their points clearly. I don't see
> a
> > reason to continue rehashing the same points over and over.
> >
> > As long as the current Ant based build/release is not broken,
> everyone
> > should be happy, or at least learn to live with it.
> >
> > That said, how can I help with your effort 😊?
> >
> > Thanks,
> > Om
> >
> >
> > On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <carlosrovira@apache.org
> >
> > wrote:
> >
> > > Hi Alex,
> > >
> > > El mié., 18 mar. 2020 a las 17:12, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > > > The proposal I'm seeing takes us back a few years to when others
> > > couldn’t
> > > > create a release.
> > >
> > >
> > > As I posted in the other thread just a few minutes ago, it's not
> about to
> > > go back and coninue. Our propose is to create something new from
> scratch,
> > > so all that old problems should just gone.
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=N6loQSFF1p1N3AS0%2FDoObELUjgRCMV9I0ylQyuYL4Y8%3D&reserved=0
> > >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/19/20, 12:17 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
Good morning all :-)
Ok ... so I've just tested my changes in my fork and on my own maven infrastructure. Worked like a charm.
Now after the "mvn release:prepare" I can see 2 committed, but not pushed changes and I have to manually push them (including the tag)
After that the build now doesn't sign the artifacts.
But Apache's nexus won't let us release artifacts that are not signed. So what is the process in signing them in the 13 steps?
The RM downloads, verifies (hopefully by building the source package locally and doing a binary compare), then signs. There is an Ant script that automates that.
I could simply not deploy to a remote maven repo but to a directory in the local file-system and then all of them can be batch-signed (I hope)
Then you would use the wagon plugin to deploy the entire directory.
Was that the process?
Yes.
Chris
Am 19.03.20, 00:21 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
Ideally, in the fixing and testing of the steps, a release would be generated. The current steps will need adjusting since there is no utils profile anymore.
-Alex
On 3/18/20, 3:00 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
since I think we are doing circles, maybe the best way to solve, if we have
into account that hopefully Chris can repair soon the CI steps, is to ask
for someone that want to be then next RM using the current process 13 CI
step process to cut the 0.9.7 release.
What do you think?
Thanks
El mié., 18 mar. 2020 a las 21:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Because you keep proposing processes that don't actually use the build.xml
> files to build the Ant artifacts. Your prior post is not a correct summary
> of what I'm saying. The RM must run the build.xml files in creating the
> artifacts to prove that they work.
>
> -Alex
>
> On 3/18/20, 1:40 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> Gee ... I wanted to go to bed, but I had to respond to this.
>
> No one ever said to get rid of Ant ... why do you keep on claiming
> this is the goal?
> We just want to create the release with only one of the two and not
> with both.
>
> Chris
>
>
> Am 18.03.20, 21:37 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>
> We already use Maven to release the Maven artifacts. Maybe you
> can explain how the RM can test the validity of the Ant artifacts without
> using Ant. Otherwise the RM has to run Ant at some point, and that's why
> we currently use Ant in certain places and Maven in others. And not get
> rid of Ant.
>
> -Alex
>
> On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
>
> I believe, as they do, that a Maven release process will be
> easier.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cec52b8f899ab4aba1e5f08d7cbd59cd7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201990638198549&sdata=kPQQgQ9nRbmoy4e%2BQe3kVDV4Enzot7tIQn1s2AN8SPk%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:31 PM Alex Harui
> <ah...@adobe.com.invalid> wrote:
>
> >
> >
> > On 3/18/20, 1:25 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev> wrote:
> >
> > Make that two PMC members. If Carlos and Chris can make
> it possible to
> > do
> > frequent releases, I want that too.
> >
> > We already had a way to do frequent release. So I don't
> understand
> > spending more time to do something we already could do.
> >
> > If what they come up can't produce a valid release, then
> I agree that
> > that
> > would count as destroying existing work, and that's not
> acceptable. But
> > that's not what they're planning to do.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cec52b8f899ab4aba1e5f08d7cbd59cd7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201990638208544&sdata=HaYOM3MRzwcsoMtqjabhqmj2N7dA1GeWUGuAgHE3IAY%3D&reserved=0
> > >
> >
> >
> > On Wed, Mar 18, 2020 at 1:14 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > >
> > >
> > > On 3/18/20, 12:06 PM, "Christofer Dutz" <
> christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > Hi Alex,
> > >
> > > where is this thrown out?
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7Cec52b8f899ab4aba1e5f08d7cbd59cd7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201990638208544&sdata=jLBTFYM6Fds690vPJmRER1sg%2FW8YtfDZz%2F8ZpRVnH0k%3D&reserved=0
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7Cec52b8f899ab4aba1e5f08d7cbd59cd7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201990638208544&sdata=KMyuRghmFZ0Ywd94CTjx7HoNjDLxP0mfWctWT5Hh%2By4%3D&reserved=0
> > >
> > > If you want to release them, all you need to do is
> go into that
> > > directory and run:
> > >
> > > mvn release:prepare
> > > mvn release:perform
> > >
> > > So as you see nothing is removed ...
> > > there is no need to have them in the same reactor,
> if that's
> > what you
> > > are referring to.
> > >
> > > The new documentation does not mention them, so how
> would someone
> > know to
> > > do that? So sure, the new process seems simple but
> that's because it
> > > doesn't document how to handle those two modules.
> > >
> > > And the argument to not try something again which
> had failed in
> > the
> > > past is sort of a strange argument for a project
> discussing on going
> > 1.0
> > > I bet a lot of stuff is in Royale that didn't work
> before and now
> > > works. It's not that we are doing it the same way we
> did before.
> > > If we did, I agree that would be a stupid waste of
> time.
> > >
> > > AFAICT, you are doing it the same way as before, but I
> won't know
> > for sure
> > > until the set of steps to create a release are
> documented.
> > >
> > > But you didn't answer my question on where it is
> written that
> > you must
> > > build jars used by Ant with Ant.
> > > Would you mind giving an answer on that?
> > >
> > > Ant should be used to test Ant. I don't understand
> how you can test
> > Ant
> > > without running Ant.
> > >
> > > The Apache Way is about scratching your itch, but it
> is also about
> > > consensus, and the itch you scratch should not break
> or destroy
> > someone
> > > else's work. Otherwise you are saying that someone
> can say "no,
> > Royale
> > > should not be PAYG" and rewrite the Basic libraries
> and I can't do
> > anything
> > > about that. That's not how Apache projects are
> supposed to work.
> > >
> > > We have one PMC member who wants to use Maven to do
> things Ant
> > already
> > > does. Why bother? Ant is better for scripting a set
> of steps.
> > That's why
> > > it exists.
> > >
> > > Let's fix the current steps and get a release out. I
> think you'll
> > see
> > > that it uses Maven "appropriately". Then make a
> branch and figure
> > out how
> > > you want to make a release. Because we have
> reproducible binaries,
> > you
> > > should be able to have your branch exactly match then
> next release
> > so we
> > > know nothing got missed.
> > >
> > > My guess is that the net is going to be to use Maven
> to tie a bunch
> > of
> > > steps together that are currently tied together with
> Ant. Assuming
> > that
> > > Ant is still used to validate the build.xml files and
> ant task jars.
> > >
> > > -Alex
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cec52b8f899ab4aba1e5f08d7cbd59cd7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201990638208544&sdata=lVM%2FE1BSzPyPgVXRiv6dkFFCjl4u%2Bhwb7tr46UTZkL8%3D&reserved=0
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Christofer Dutz <ch...@c-ware.de>.
Good morning all :-)
Ok ... so I've just tested my changes in my fork and on my own maven infrastructure. Worked like a charm.
Now after the "mvn release:prepare" I can see 2 committed, but not pushed changes and I have to manually push them (including the tag)
After that the build now doesn't sign the artifacts.
But Apache's nexus won't let us release artifacts that are not signed. So what is the process in signing them in the 13 steps?
I could simply not deploy to a remote maven repo but to a directory in the local file-system and then all of them can be batch-signed (I hope)
Then you would use the wagon plugin to deploy the entire directory.
Was that the process?
Chris
Am 19.03.20, 00:21 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
Ideally, in the fixing and testing of the steps, a release would be generated. The current steps will need adjusting since there is no utils profile anymore.
-Alex
On 3/18/20, 3:00 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
since I think we are doing circles, maybe the best way to solve, if we have
into account that hopefully Chris can repair soon the CI steps, is to ask
for someone that want to be then next RM using the current process 13 CI
step process to cut the 0.9.7 release.
What do you think?
Thanks
El mié., 18 mar. 2020 a las 21:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Because you keep proposing processes that don't actually use the build.xml
> files to build the Ant artifacts. Your prior post is not a correct summary
> of what I'm saying. The RM must run the build.xml files in creating the
> artifacts to prove that they work.
>
> -Alex
>
> On 3/18/20, 1:40 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> Gee ... I wanted to go to bed, but I had to respond to this.
>
> No one ever said to get rid of Ant ... why do you keep on claiming
> this is the goal?
> We just want to create the release with only one of the two and not
> with both.
>
> Chris
>
>
> Am 18.03.20, 21:37 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>
> We already use Maven to release the Maven artifacts. Maybe you
> can explain how the RM can test the validity of the Ant artifacts without
> using Ant. Otherwise the RM has to run Ant at some point, and that's why
> we currently use Ant in certain places and Maven in others. And not get
> rid of Ant.
>
> -Alex
>
> On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
>
> I believe, as they do, that a Maven release process will be
> easier.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027010563&sdata=XGphLBEjE69qlwMihPkabM37wjriB%2FeZUum9SPnNix4%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:31 PM Alex Harui
> <ah...@adobe.com.invalid> wrote:
>
> >
> >
> > On 3/18/20, 1:25 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev> wrote:
> >
> > Make that two PMC members. If Carlos and Chris can make
> it possible to
> > do
> > frequent releases, I want that too.
> >
> > We already had a way to do frequent release. So I don't
> understand
> > spending more time to do something we already could do.
> >
> > If what they come up can't produce a valid release, then
> I agree that
> > that
> > would count as destroying existing work, and that's not
> acceptable. But
> > that's not what they're planning to do.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=iCrGptyuQt2mNDaxIsNPp6WP%2FpBqs2iZ5BCJev5EpR4%3D&reserved=0
> > >
> >
> >
> > On Wed, Mar 18, 2020 at 1:14 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > >
> > >
> > > On 3/18/20, 12:06 PM, "Christofer Dutz" <
> christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > Hi Alex,
> > >
> > > where is this thrown out?
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=YkkakCxfpGu41FtbojBVMudrcwjjXzF%2FPJwMu%2FE3e6U%3D&reserved=0
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=uVAVLBjVZbyF%2FvfQHeU156fWC8WRe4bMCgq40mZl%2FVc%3D&reserved=0
> > >
> > > If you want to release them, all you need to do is
> go into that
> > > directory and run:
> > >
> > > mvn release:prepare
> > > mvn release:perform
> > >
> > > So as you see nothing is removed ...
> > > there is no need to have them in the same reactor,
> if that's
> > what you
> > > are referring to.
> > >
> > > The new documentation does not mention them, so how
> would someone
> > know to
> > > do that? So sure, the new process seems simple but
> that's because it
> > > doesn't document how to handle those two modules.
> > >
> > > And the argument to not try something again which
> had failed in
> > the
> > > past is sort of a strange argument for a project
> discussing on going
> > 1.0
> > > I bet a lot of stuff is in Royale that didn't work
> before and now
> > > works. It's not that we are doing it the same way we
> did before.
> > > If we did, I agree that would be a stupid waste of
> time.
> > >
> > > AFAICT, you are doing it the same way as before, but I
> won't know
> > for sure
> > > until the set of steps to create a release are
> documented.
> > >
> > > But you didn't answer my question on where it is
> written that
> > you must
> > > build jars used by Ant with Ant.
> > > Would you mind giving an answer on that?
> > >
> > > Ant should be used to test Ant. I don't understand
> how you can test
> > Ant
> > > without running Ant.
> > >
> > > The Apache Way is about scratching your itch, but it
> is also about
> > > consensus, and the itch you scratch should not break
> or destroy
> > someone
> > > else's work. Otherwise you are saying that someone
> can say "no,
> > Royale
> > > should not be PAYG" and rewrite the Basic libraries
> and I can't do
> > anything
> > > about that. That's not how Apache projects are
> supposed to work.
> > >
> > > We have one PMC member who wants to use Maven to do
> things Ant
> > already
> > > does. Why bother? Ant is better for scripting a set
> of steps.
> > That's why
> > > it exists.
> > >
> > > Let's fix the current steps and get a release out. I
> think you'll
> > see
> > > that it uses Maven "appropriately". Then make a
> branch and figure
> > out how
> > > you want to make a release. Because we have
> reproducible binaries,
> > you
> > > should be able to have your branch exactly match then
> next release
> > so we
> > > know nothing got missed.
> > >
> > > My guess is that the net is going to be to use Maven
> to tie a bunch
> > of
> > > steps together that are currently tied together with
> Ant. Assuming
> > that
> > > Ant is still used to validate the build.xml files and
> ant task jars.
> > >
> > > -Alex
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=Dv4OLMpfweUBKXhFF8yTBwqEqGZiRtf%2FOtVtTltXwos%3D&reserved=0
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Ideally, in the fixing and testing of the steps, a release would be generated. The current steps will need adjusting since there is no utils profile anymore.
-Alex
On 3/18/20, 3:00 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
since I think we are doing circles, maybe the best way to solve, if we have
into account that hopefully Chris can repair soon the CI steps, is to ask
for someone that want to be then next RM using the current process 13 CI
step process to cut the 0.9.7 release.
What do you think?
Thanks
El mié., 18 mar. 2020 a las 21:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Because you keep proposing processes that don't actually use the build.xml
> files to build the Ant artifacts. Your prior post is not a correct summary
> of what I'm saying. The RM must run the build.xml files in creating the
> artifacts to prove that they work.
>
> -Alex
>
> On 3/18/20, 1:40 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> Gee ... I wanted to go to bed, but I had to respond to this.
>
> No one ever said to get rid of Ant ... why do you keep on claiming
> this is the goal?
> We just want to create the release with only one of the two and not
> with both.
>
> Chris
>
>
> Am 18.03.20, 21:37 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>
> We already use Maven to release the Maven artifacts. Maybe you
> can explain how the RM can test the validity of the Ant artifacts without
> using Ant. Otherwise the RM has to run Ant at some point, and that's why
> we currently use Ant in certain places and Maven in others. And not get
> rid of Ant.
>
> -Alex
>
> On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
>
> I believe, as they do, that a Maven release process will be
> easier.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027010563&sdata=XGphLBEjE69qlwMihPkabM37wjriB%2FeZUum9SPnNix4%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:31 PM Alex Harui
> <ah...@adobe.com.invalid> wrote:
>
> >
> >
> > On 3/18/20, 1:25 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev> wrote:
> >
> > Make that two PMC members. If Carlos and Chris can make
> it possible to
> > do
> > frequent releases, I want that too.
> >
> > We already had a way to do frequent release. So I don't
> understand
> > spending more time to do something we already could do.
> >
> > If what they come up can't produce a valid release, then
> I agree that
> > that
> > would count as destroying existing work, and that's not
> acceptable. But
> > that's not what they're planning to do.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=iCrGptyuQt2mNDaxIsNPp6WP%2FpBqs2iZ5BCJev5EpR4%3D&reserved=0
> > >
> >
> >
> > On Wed, Mar 18, 2020 at 1:14 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > >
> > >
> > > On 3/18/20, 12:06 PM, "Christofer Dutz" <
> christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > Hi Alex,
> > >
> > > where is this thrown out?
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=YkkakCxfpGu41FtbojBVMudrcwjjXzF%2FPJwMu%2FE3e6U%3D&reserved=0
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=uVAVLBjVZbyF%2FvfQHeU156fWC8WRe4bMCgq40mZl%2FVc%3D&reserved=0
> > >
> > > If you want to release them, all you need to do is
> go into that
> > > directory and run:
> > >
> > > mvn release:prepare
> > > mvn release:perform
> > >
> > > So as you see nothing is removed ...
> > > there is no need to have them in the same reactor,
> if that's
> > what you
> > > are referring to.
> > >
> > > The new documentation does not mention them, so how
> would someone
> > know to
> > > do that? So sure, the new process seems simple but
> that's because it
> > > doesn't document how to handle those two modules.
> > >
> > > And the argument to not try something again which
> had failed in
> > the
> > > past is sort of a strange argument for a project
> discussing on going
> > 1.0
> > > I bet a lot of stuff is in Royale that didn't work
> before and now
> > > works. It's not that we are doing it the same way we
> did before.
> > > If we did, I agree that would be a stupid waste of
> time.
> > >
> > > AFAICT, you are doing it the same way as before, but I
> won't know
> > for sure
> > > until the set of steps to create a release are
> documented.
> > >
> > > But you didn't answer my question on where it is
> written that
> > you must
> > > build jars used by Ant with Ant.
> > > Would you mind giving an answer on that?
> > >
> > > Ant should be used to test Ant. I don't understand
> how you can test
> > Ant
> > > without running Ant.
> > >
> > > The Apache Way is about scratching your itch, but it
> is also about
> > > consensus, and the itch you scratch should not break
> or destroy
> > someone
> > > else's work. Otherwise you are saying that someone
> can say "no,
> > Royale
> > > should not be PAYG" and rewrite the Basic libraries
> and I can't do
> > anything
> > > about that. That's not how Apache projects are
> supposed to work.
> > >
> > > We have one PMC member who wants to use Maven to do
> things Ant
> > already
> > > does. Why bother? Ant is better for scripting a set
> of steps.
> > That's why
> > > it exists.
> > >
> > > Let's fix the current steps and get a release out. I
> think you'll
> > see
> > > that it uses Maven "appropriately". Then make a
> branch and figure
> > out how
> > > you want to make a release. Because we have
> reproducible binaries,
> > you
> > > should be able to have your branch exactly match then
> next release
> > so we
> > > know nothing got missed.
> > >
> > > My guess is that the net is going to be to use Maven
> to tie a bunch
> > of
> > > steps together that are currently tied together with
> Ant. Assuming
> > that
> > > Ant is still used to validate the build.xml files and
> ant task jars.
> > >
> > > -Alex
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb5015381b5f94293c85308d7cb87b4ee%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201656027020553&sdata=Dv4OLMpfweUBKXhFF8yTBwqEqGZiRtf%2FOtVtTltXwos%3D&reserved=0
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
since I think we are doing circles, maybe the best way to solve, if we have
into account that hopefully Chris can repair soon the CI steps, is to ask
for someone that want to be then next RM using the current process 13 CI
step process to cut the 0.9.7 release.
What do you think?
Thanks
El mié., 18 mar. 2020 a las 21:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Because you keep proposing processes that don't actually use the build.xml
> files to build the Ant artifacts. Your prior post is not a correct summary
> of what I'm saying. The RM must run the build.xml files in creating the
> artifacts to prove that they work.
>
> -Alex
>
> On 3/18/20, 1:40 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> Gee ... I wanted to go to bed, but I had to respond to this.
>
> No one ever said to get rid of Ant ... why do you keep on claiming
> this is the goal?
> We just want to create the release with only one of the two and not
> with both.
>
> Chris
>
>
> Am 18.03.20, 21:37 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
>
> We already use Maven to release the Maven artifacts. Maybe you
> can explain how the RM can test the validity of the Ant artifacts without
> using Ant. Otherwise the RM has to run Ant at some point, and that's why
> we currently use Ant in certain places and Maven in others. And not get
> rid of Ant.
>
> -Alex
>
> On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
>
> I believe, as they do, that a Maven release process will be
> easier.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=Iy8OWlhN06YislGx4XSuLSO6pynaDiINky7woOOKcss%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:31 PM Alex Harui
> <ah...@adobe.com.invalid> wrote:
>
> >
> >
> > On 3/18/20, 1:25 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev> wrote:
> >
> > Make that two PMC members. If Carlos and Chris can make
> it possible to
> > do
> > frequent releases, I want that too.
> >
> > We already had a way to do frequent release. So I don't
> understand
> > spending more time to do something we already could do.
> >
> > If what they come up can't produce a valid release, then
> I agree that
> > that
> > would count as destroying existing work, and that's not
> acceptable. But
> > that's not what they're planning to do.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=Iy8OWlhN06YislGx4XSuLSO6pynaDiINky7woOOKcss%3D&reserved=0
> > >
> >
> >
> > On Wed, Mar 18, 2020 at 1:14 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > >
> > >
> > > On 3/18/20, 12:06 PM, "Christofer Dutz" <
> christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > Hi Alex,
> > >
> > > where is this thrown out?
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=VvtOiKIBFYoK86WPNKYY9l6kYCpcPnS%2B0m3B2qMWFG4%3D&reserved=0
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=Dqwf1HCceMvsNKxde68FHXLCtdkHSkLkpuHAdcohu78%3D&reserved=0
> > >
> > > If you want to release them, all you need to do is
> go into that
> > > directory and run:
> > >
> > > mvn release:prepare
> > > mvn release:perform
> > >
> > > So as you see nothing is removed ...
> > > there is no need to have them in the same reactor,
> if that's
> > what you
> > > are referring to.
> > >
> > > The new documentation does not mention them, so how
> would someone
> > know to
> > > do that? So sure, the new process seems simple but
> that's because it
> > > doesn't document how to handle those two modules.
> > >
> > > And the argument to not try something again which
> had failed in
> > the
> > > past is sort of a strange argument for a project
> discussing on going
> > 1.0
> > > I bet a lot of stuff is in Royale that didn't work
> before and now
> > > works. It's not that we are doing it the same way we
> did before.
> > > If we did, I agree that would be a stupid waste of
> time.
> > >
> > > AFAICT, you are doing it the same way as before, but I
> won't know
> > for sure
> > > until the set of steps to create a release are
> documented.
> > >
> > > But you didn't answer my question on where it is
> written that
> > you must
> > > build jars used by Ant with Ant.
> > > Would you mind giving an answer on that?
> > >
> > > Ant should be used to test Ant. I don't understand
> how you can test
> > Ant
> > > without running Ant.
> > >
> > > The Apache Way is about scratching your itch, but it
> is also about
> > > consensus, and the itch you scratch should not break
> or destroy
> > someone
> > > else's work. Otherwise you are saying that someone
> can say "no,
> > Royale
> > > should not be PAYG" and rewrite the Basic libraries
> and I can't do
> > anything
> > > about that. That's not how Apache projects are
> supposed to work.
> > >
> > > We have one PMC member who wants to use Maven to do
> things Ant
> > already
> > > does. Why bother? Ant is better for scripting a set
> of steps.
> > That's why
> > > it exists.
> > >
> > > Let's fix the current steps and get a release out. I
> think you'll
> > see
> > > that it uses Maven "appropriately". Then make a
> branch and figure
> > out how
> > > you want to make a release. Because we have
> reproducible binaries,
> > you
> > > should be able to have your branch exactly match then
> next release
> > so we
> > > know nothing got missed.
> > >
> > > My guess is that the net is going to be to use Maven
> to tie a bunch
> > of
> > > steps together that are currently tied together with
> Ant. Assuming
> > that
> > > Ant is still used to validate the build.xml files and
> ant task jars.
> > >
> > > -Alex
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Because you keep proposing processes that don't actually use the build.xml files to build the Ant artifacts. Your prior post is not a correct summary of what I'm saying. The RM must run the build.xml files in creating the artifacts to prove that they work.
-Alex
On 3/18/20, 1:40 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
Gee ... I wanted to go to bed, but I had to respond to this.
No one ever said to get rid of Ant ... why do you keep on claiming this is the goal?
We just want to create the release with only one of the two and not with both.
Chris
Am 18.03.20, 21:37 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
We already use Maven to release the Maven artifacts. Maybe you can explain how the RM can test the validity of the Ant artifacts without using Ant. Otherwise the RM has to run Ant at some point, and that's why we currently use Ant in certain places and Maven in others. And not get rid of Ant.
-Alex
On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
I believe, as they do, that a Maven release process will be easier.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=Iy8OWlhN06YislGx4XSuLSO6pynaDiINky7woOOKcss%3D&reserved=0>
On Wed, Mar 18, 2020 at 1:31 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>
> On 3/18/20, 1:25 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Make that two PMC members. If Carlos and Chris can make it possible to
> do
> frequent releases, I want that too.
>
> We already had a way to do frequent release. So I don't understand
> spending more time to do something we already could do.
>
> If what they come up can't produce a valid release, then I agree that
> that
> would count as destroying existing work, and that's not acceptable. But
> that's not what they're planning to do.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=Iy8OWlhN06YislGx4XSuLSO6pynaDiINky7woOOKcss%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:14 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> >
> >
> > On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de>
> > wrote:
> >
> > Hi Alex,
> >
> > where is this thrown out?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=VvtOiKIBFYoK86WPNKYY9l6kYCpcPnS%2B0m3B2qMWFG4%3D&reserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7C310b1519b44242bc5e5c08d7cb7ca135%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201608458935036&sdata=Dqwf1HCceMvsNKxde68FHXLCtdkHSkLkpuHAdcohu78%3D&reserved=0
> >
> > If you want to release them, all you need to do is go into that
> > directory and run:
> >
> > mvn release:prepare
> > mvn release:perform
> >
> > So as you see nothing is removed ...
> > there is no need to have them in the same reactor, if that's
> what you
> > are referring to.
> >
> > The new documentation does not mention them, so how would someone
> know to
> > do that? So sure, the new process seems simple but that's because it
> > doesn't document how to handle those two modules.
> >
> > And the argument to not try something again which had failed in
> the
> > past is sort of a strange argument for a project discussing on going
> 1.0
> > I bet a lot of stuff is in Royale that didn't work before and now
> > works. It's not that we are doing it the same way we did before.
> > If we did, I agree that would be a stupid waste of time.
> >
> > AFAICT, you are doing it the same way as before, but I won't know
> for sure
> > until the set of steps to create a release are documented.
> >
> > But you didn't answer my question on where it is written that
> you must
> > build jars used by Ant with Ant.
> > Would you mind giving an answer on that?
> >
> > Ant should be used to test Ant. I don't understand how you can test
> Ant
> > without running Ant.
> >
> > The Apache Way is about scratching your itch, but it is also about
> > consensus, and the itch you scratch should not break or destroy
> someone
> > else's work. Otherwise you are saying that someone can say "no,
> Royale
> > should not be PAYG" and rewrite the Basic libraries and I can't do
> anything
> > about that. That's not how Apache projects are supposed to work.
> >
> > We have one PMC member who wants to use Maven to do things Ant
> already
> > does. Why bother? Ant is better for scripting a set of steps.
> That's why
> > it exists.
> >
> > Let's fix the current steps and get a release out. I think you'll
> see
> > that it uses Maven "appropriately". Then make a branch and figure
> out how
> > you want to make a release. Because we have reproducible binaries,
> you
> > should be able to have your branch exactly match then next release
> so we
> > know nothing got missed.
> >
> > My guess is that the net is going to be to use Maven to tie a bunch
> of
> > steps together that are currently tied together with Ant. Assuming
> that
> > Ant is still used to validate the build.xml files and ant task jars.
> >
> > -Alex
> >
> >
> >
> >
> >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Christofer Dutz <ch...@c-ware.de>.
Gee ... I wanted to go to bed, but I had to respond to this.
No one ever said to get rid of Ant ... why do you keep on claiming this is the goal?
We just want to create the release with only one of the two and not with both.
Chris
Am 18.03.20, 21:37 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
We already use Maven to release the Maven artifacts. Maybe you can explain how the RM can test the validity of the Ant artifacts without using Ant. Otherwise the RM has to run Ant at some point, and that's why we currently use Ant in certain places and Maven in others. And not get rid of Ant.
-Alex
On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
I believe, as they do, that a Maven release process will be easier.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=jYL5FyBgHY97BlnGRSfUqe%2Fhd8SsPoxp%2BZEepQIWaqY%3D&reserved=0>
On Wed, Mar 18, 2020 at 1:31 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>
> On 3/18/20, 1:25 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Make that two PMC members. If Carlos and Chris can make it possible to
> do
> frequent releases, I want that too.
>
> We already had a way to do frequent release. So I don't understand
> spending more time to do something we already could do.
>
> If what they come up can't produce a valid release, then I agree that
> that
> would count as destroying existing work, and that's not acceptable. But
> that's not what they're planning to do.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=jYL5FyBgHY97BlnGRSfUqe%2Fhd8SsPoxp%2BZEepQIWaqY%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:14 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> >
> >
> > On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de>
> > wrote:
> >
> > Hi Alex,
> >
> > where is this thrown out?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=kP6mXhejYRBCaWBlLNQj%2Fe1mgoYDeb3du06U%2Fax07bo%3D&reserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=SPLl3YvGQOaofdPNLNDnpeGPCq1N%2FfGX4gYvsxwbHTo%3D&reserved=0
> >
> > If you want to release them, all you need to do is go into that
> > directory and run:
> >
> > mvn release:prepare
> > mvn release:perform
> >
> > So as you see nothing is removed ...
> > there is no need to have them in the same reactor, if that's
> what you
> > are referring to.
> >
> > The new documentation does not mention them, so how would someone
> know to
> > do that? So sure, the new process seems simple but that's because it
> > doesn't document how to handle those two modules.
> >
> > And the argument to not try something again which had failed in
> the
> > past is sort of a strange argument for a project discussing on going
> 1.0
> > I bet a lot of stuff is in Royale that didn't work before and now
> > works. It's not that we are doing it the same way we did before.
> > If we did, I agree that would be a stupid waste of time.
> >
> > AFAICT, you are doing it the same way as before, but I won't know
> for sure
> > until the set of steps to create a release are documented.
> >
> > But you didn't answer my question on where it is written that
> you must
> > build jars used by Ant with Ant.
> > Would you mind giving an answer on that?
> >
> > Ant should be used to test Ant. I don't understand how you can test
> Ant
> > without running Ant.
> >
> > The Apache Way is about scratching your itch, but it is also about
> > consensus, and the itch you scratch should not break or destroy
> someone
> > else's work. Otherwise you are saying that someone can say "no,
> Royale
> > should not be PAYG" and rewrite the Basic libraries and I can't do
> anything
> > about that. That's not how Apache projects are supposed to work.
> >
> > We have one PMC member who wants to use Maven to do things Ant
> already
> > does. Why bother? Ant is better for scripting a set of steps.
> That's why
> > it exists.
> >
> > Let's fix the current steps and get a release out. I think you'll
> see
> > that it uses Maven "appropriately". Then make a branch and figure
> out how
> > you want to make a release. Because we have reproducible binaries,
> you
> > should be able to have your branch exactly match then next release
> so we
> > know nothing got missed.
> >
> > My guess is that the net is going to be to use Maven to tie a bunch
> of
> > steps together that are currently tied together with Ant. Assuming
> that
> > Ant is still used to validate the build.xml files and ant task jars.
> >
> > -Alex
> >
> >
> >
> >
> >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
We already use Maven to release the Maven artifacts. Maybe you can explain how the RM can test the validity of the Ant artifacts without using Ant. Otherwise the RM has to run Ant at some point, and that's why we currently use Ant in certain places and Maven in others. And not get rid of Ant.
-Alex
On 3/18/20, 1:32 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
I believe, as they do, that a Maven release process will be easier.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=jYL5FyBgHY97BlnGRSfUqe%2Fhd8SsPoxp%2BZEepQIWaqY%3D&reserved=0>
On Wed, Mar 18, 2020 at 1:31 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>
> On 3/18/20, 1:25 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Make that two PMC members. If Carlos and Chris can make it possible to
> do
> frequent releases, I want that too.
>
> We already had a way to do frequent release. So I don't understand
> spending more time to do something we already could do.
>
> If what they come up can't produce a valid release, then I agree that
> that
> would count as destroying existing work, and that's not acceptable. But
> that's not what they're planning to do.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=jYL5FyBgHY97BlnGRSfUqe%2Fhd8SsPoxp%2BZEepQIWaqY%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:14 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> >
> >
> > On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de>
> > wrote:
> >
> > Hi Alex,
> >
> > where is this thrown out?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=kP6mXhejYRBCaWBlLNQj%2Fe1mgoYDeb3du06U%2Fax07bo%3D&reserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7C80dafc5c57694ad0923208d7cb7b8506%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201603692421553&sdata=SPLl3YvGQOaofdPNLNDnpeGPCq1N%2FfGX4gYvsxwbHTo%3D&reserved=0
> >
> > If you want to release them, all you need to do is go into that
> > directory and run:
> >
> > mvn release:prepare
> > mvn release:perform
> >
> > So as you see nothing is removed ...
> > there is no need to have them in the same reactor, if that's
> what you
> > are referring to.
> >
> > The new documentation does not mention them, so how would someone
> know to
> > do that? So sure, the new process seems simple but that's because it
> > doesn't document how to handle those two modules.
> >
> > And the argument to not try something again which had failed in
> the
> > past is sort of a strange argument for a project discussing on going
> 1.0
> > I bet a lot of stuff is in Royale that didn't work before and now
> > works. It's not that we are doing it the same way we did before.
> > If we did, I agree that would be a stupid waste of time.
> >
> > AFAICT, you are doing it the same way as before, but I won't know
> for sure
> > until the set of steps to create a release are documented.
> >
> > But you didn't answer my question on where it is written that
> you must
> > build jars used by Ant with Ant.
> > Would you mind giving an answer on that?
> >
> > Ant should be used to test Ant. I don't understand how you can test
> Ant
> > without running Ant.
> >
> > The Apache Way is about scratching your itch, but it is also about
> > consensus, and the itch you scratch should not break or destroy
> someone
> > else's work. Otherwise you are saying that someone can say "no,
> Royale
> > should not be PAYG" and rewrite the Basic libraries and I can't do
> anything
> > about that. That's not how Apache projects are supposed to work.
> >
> > We have one PMC member who wants to use Maven to do things Ant
> already
> > does. Why bother? Ant is better for scripting a set of steps.
> That's why
> > it exists.
> >
> > Let's fix the current steps and get a release out. I think you'll
> see
> > that it uses Maven "appropriately". Then make a branch and figure
> out how
> > you want to make a release. Because we have reproducible binaries,
> you
> > should be able to have your branch exactly match then next release
> so we
> > know nothing got missed.
> >
> > My guess is that the net is going to be to use Maven to tie a bunch
> of
> > steps together that are currently tied together with Ant. Assuming
> that
> > Ant is still used to validate the build.xml files and ant task jars.
> >
> > -Alex
> >
> >
> >
> >
> >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
I believe, as they do, that a Maven release process will be easier.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Mar 18, 2020 at 1:31 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>
> On 3/18/20, 1:25 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Make that two PMC members. If Carlos and Chris can make it possible to
> do
> frequent releases, I want that too.
>
> We already had a way to do frequent release. So I don't understand
> spending more time to do something we already could do.
>
> If what they come up can't produce a valid release, then I agree that
> that
> would count as destroying existing work, and that's not acceptable. But
> that's not what they're planning to do.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C2894af63dcbf4932122208d7cb7a82ae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201599351894795&sdata=%2Fg5qCXzVQ9uLLKhGYi3rNcio8ZGYQygXM%2FAe13%2F%2BmCk%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 1:14 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> >
> >
> > On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de>
> > wrote:
> >
> > Hi Alex,
> >
> > where is this thrown out?
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7C2894af63dcbf4932122208d7cb7a82ae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201599351894795&sdata=iiVNkXqcUd76nPyWmYG22RQbtETyNSoGoADwjVfNq1E%3D&reserved=0
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7C2894af63dcbf4932122208d7cb7a82ae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201599351894795&sdata=uiIF7oYEEWXV%2FYcUJbH%2FkUjxrS9T%2BDsumVzqf8holNQ%3D&reserved=0
> >
> > If you want to release them, all you need to do is go into that
> > directory and run:
> >
> > mvn release:prepare
> > mvn release:perform
> >
> > So as you see nothing is removed ...
> > there is no need to have them in the same reactor, if that's
> what you
> > are referring to.
> >
> > The new documentation does not mention them, so how would someone
> know to
> > do that? So sure, the new process seems simple but that's because it
> > doesn't document how to handle those two modules.
> >
> > And the argument to not try something again which had failed in
> the
> > past is sort of a strange argument for a project discussing on going
> 1.0
> > I bet a lot of stuff is in Royale that didn't work before and now
> > works. It's not that we are doing it the same way we did before.
> > If we did, I agree that would be a stupid waste of time.
> >
> > AFAICT, you are doing it the same way as before, but I won't know
> for sure
> > until the set of steps to create a release are documented.
> >
> > But you didn't answer my question on where it is written that
> you must
> > build jars used by Ant with Ant.
> > Would you mind giving an answer on that?
> >
> > Ant should be used to test Ant. I don't understand how you can test
> Ant
> > without running Ant.
> >
> > The Apache Way is about scratching your itch, but it is also about
> > consensus, and the itch you scratch should not break or destroy
> someone
> > else's work. Otherwise you are saying that someone can say "no,
> Royale
> > should not be PAYG" and rewrite the Basic libraries and I can't do
> anything
> > about that. That's not how Apache projects are supposed to work.
> >
> > We have one PMC member who wants to use Maven to do things Ant
> already
> > does. Why bother? Ant is better for scripting a set of steps.
> That's why
> > it exists.
> >
> > Let's fix the current steps and get a release out. I think you'll
> see
> > that it uses Maven "appropriately". Then make a branch and figure
> out how
> > you want to make a release. Because we have reproducible binaries,
> you
> > should be able to have your branch exactly match then next release
> so we
> > know nothing got missed.
> >
> > My guess is that the net is going to be to use Maven to tie a bunch
> of
> > steps together that are currently tied together with Ant. Assuming
> that
> > Ant is still used to validate the build.xml files and ant task jars.
> >
> > -Alex
> >
> >
> >
> >
> >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/18/20, 1:25 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Make that two PMC members. If Carlos and Chris can make it possible to do
frequent releases, I want that too.
We already had a way to do frequent release. So I don't understand spending more time to do something we already could do.
If what they come up can't produce a valid release, then I agree that that
would count as destroying existing work, and that's not acceptable. But
that's not what they're planning to do.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C2894af63dcbf4932122208d7cb7a82ae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201599351894795&sdata=%2Fg5qCXzVQ9uLLKhGYi3rNcio8ZGYQygXM%2FAe13%2F%2BmCk%3D&reserved=0>
On Wed, Mar 18, 2020 at 1:14 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>
> On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de>
> wrote:
>
> Hi Alex,
>
> where is this thrown out?
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7C2894af63dcbf4932122208d7cb7a82ae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201599351894795&sdata=iiVNkXqcUd76nPyWmYG22RQbtETyNSoGoADwjVfNq1E%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7C2894af63dcbf4932122208d7cb7a82ae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201599351894795&sdata=uiIF7oYEEWXV%2FYcUJbH%2FkUjxrS9T%2BDsumVzqf8holNQ%3D&reserved=0
>
> If you want to release them, all you need to do is go into that
> directory and run:
>
> mvn release:prepare
> mvn release:perform
>
> So as you see nothing is removed ...
> there is no need to have them in the same reactor, if that's what you
> are referring to.
>
> The new documentation does not mention them, so how would someone know to
> do that? So sure, the new process seems simple but that's because it
> doesn't document how to handle those two modules.
>
> And the argument to not try something again which had failed in the
> past is sort of a strange argument for a project discussing on going 1.0
> I bet a lot of stuff is in Royale that didn't work before and now
> works. It's not that we are doing it the same way we did before.
> If we did, I agree that would be a stupid waste of time.
>
> AFAICT, you are doing it the same way as before, but I won't know for sure
> until the set of steps to create a release are documented.
>
> But you didn't answer my question on where it is written that you must
> build jars used by Ant with Ant.
> Would you mind giving an answer on that?
>
> Ant should be used to test Ant. I don't understand how you can test Ant
> without running Ant.
>
> The Apache Way is about scratching your itch, but it is also about
> consensus, and the itch you scratch should not break or destroy someone
> else's work. Otherwise you are saying that someone can say "no, Royale
> should not be PAYG" and rewrite the Basic libraries and I can't do anything
> about that. That's not how Apache projects are supposed to work.
>
> We have one PMC member who wants to use Maven to do things Ant already
> does. Why bother? Ant is better for scripting a set of steps. That's why
> it exists.
>
> Let's fix the current steps and get a release out. I think you'll see
> that it uses Maven "appropriately". Then make a branch and figure out how
> you want to make a release. Because we have reproducible binaries, you
> should be able to have your branch exactly match then next release so we
> know nothing got missed.
>
> My guess is that the net is going to be to use Maven to tie a bunch of
> steps together that are currently tied together with Ant. Assuming that
> Ant is still used to validate the build.xml files and ant task jars.
>
> -Alex
>
>
>
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Make that two PMC members. If Carlos and Chris can make it possible to do
frequent releases, I want that too.
If what they come up can't produce a valid release, then I agree that that
would count as destroying existing work, and that's not acceptable. But
that's not what they're planning to do.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Mar 18, 2020 at 1:14 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>
> On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de>
> wrote:
>
> Hi Alex,
>
> where is this thrown out?
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7Caaad86012aff4088cfce08d7cb6f68f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201551684695870&sdata=08kAgWKFZq8a15jHOivOq4oB6c2z5XPLKuJmexu3zfs%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7Caaad86012aff4088cfce08d7cb6f68f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201551684695870&sdata=MtfRqNnNQE84twNXGa1ChJKCzt%2FyHAIwMKf47VTy%2FaQ%3D&reserved=0
>
> If you want to release them, all you need to do is go into that
> directory and run:
>
> mvn release:prepare
> mvn release:perform
>
> So as you see nothing is removed ...
> there is no need to have them in the same reactor, if that's what you
> are referring to.
>
> The new documentation does not mention them, so how would someone know to
> do that? So sure, the new process seems simple but that's because it
> doesn't document how to handle those two modules.
>
> And the argument to not try something again which had failed in the
> past is sort of a strange argument for a project discussing on going 1.0
> I bet a lot of stuff is in Royale that didn't work before and now
> works. It's not that we are doing it the same way we did before.
> If we did, I agree that would be a stupid waste of time.
>
> AFAICT, you are doing it the same way as before, but I won't know for sure
> until the set of steps to create a release are documented.
>
> But you didn't answer my question on where it is written that you must
> build jars used by Ant with Ant.
> Would you mind giving an answer on that?
>
> Ant should be used to test Ant. I don't understand how you can test Ant
> without running Ant.
>
> The Apache Way is about scratching your itch, but it is also about
> consensus, and the itch you scratch should not break or destroy someone
> else's work. Otherwise you are saying that someone can say "no, Royale
> should not be PAYG" and rewrite the Basic libraries and I can't do anything
> about that. That's not how Apache projects are supposed to work.
>
> We have one PMC member who wants to use Maven to do things Ant already
> does. Why bother? Ant is better for scripting a set of steps. That's why
> it exists.
>
> Let's fix the current steps and get a release out. I think you'll see
> that it uses Maven "appropriately". Then make a branch and figure out how
> you want to make a release. Because we have reproducible binaries, you
> should be able to have your branch exactly match then next release so we
> know nothing got missed.
>
> My guess is that the net is going to be to use Maven to tie a bunch of
> steps together that are currently tied together with Ant. Assuming that
> Ant is still used to validate the build.xml files and ant task jars.
>
> -Alex
>
>
>
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
you don't need to release these modules every time ... they are released if something changes with them, not otherwise.
That's why they are already in the 1.1.0 version ... we released them once and then had to do so again because something changed, but for the past 4 4-5 years nothing has changed here.
That's also why there is no documentation on how to release them ... my two lines should be enough to do so.
Well if you boil it down to "use the maven-release-plugin" yes ... then we're doing it the same way, if you however look a little deeper, not quite.
And in the end it's not my goal to just have the 13 step release working, I am more aiming for a 3 step process, so I wouldn't call this not changing anything.
What I suggested would do nothing else than use ant to build something and then verify it worked. The only difference is that this ant build would be started from a maven plugin. But you did notice that you were initially talking about all jars used by Ant having to be built by Ant and now are just referring to testing the Ant targets with Ant ... I do agree ... nothing else makes sense than to test the Ant targets with Ant and I never proposed anything else.
Also don't I agree that it's only one PMC wanting this.
Another Neat Tool (Ant) exists because the Jakarta project (Not the Eclipse Jakarta) needed a Java based build tool and the only option at that time was ANT. Maven (Also originating from the Jakarta project) however was built by taking all the best practices that emerged througout all Apache projects and distilled these into a new tool -> Apache Maven was born. In my scan though all Apache repos, I did notice that Ant seems to have a tendency to be used in the older Apache projects (Taking out Cassandra, which really surprised me).
Good night and good health in these crazy times to you all ... Going to bed now ;-)
Chris
Am 18.03.20, 21:15 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
Hi Alex,
where is this thrown out?
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7Caaad86012aff4088cfce08d7cb6f68f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201551684695870&sdata=08kAgWKFZq8a15jHOivOq4oB6c2z5XPLKuJmexu3zfs%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7Caaad86012aff4088cfce08d7cb6f68f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201551684695870&sdata=MtfRqNnNQE84twNXGa1ChJKCzt%2FyHAIwMKf47VTy%2FaQ%3D&reserved=0
If you want to release them, all you need to do is go into that directory and run:
mvn release:prepare
mvn release:perform
So as you see nothing is removed ...
there is no need to have them in the same reactor, if that's what you are referring to.
The new documentation does not mention them, so how would someone know to do that? So sure, the new process seems simple but that's because it doesn't document how to handle those two modules.
And the argument to not try something again which had failed in the past is sort of a strange argument for a project discussing on going 1.0
I bet a lot of stuff is in Royale that didn't work before and now works. It's not that we are doing it the same way we did before.
If we did, I agree that would be a stupid waste of time.
AFAICT, you are doing it the same way as before, but I won't know for sure until the set of steps to create a release are documented.
But you didn't answer my question on where it is written that you must build jars used by Ant with Ant.
Would you mind giving an answer on that?
Ant should be used to test Ant. I don't understand how you can test Ant without running Ant.
The Apache Way is about scratching your itch, but it is also about consensus, and the itch you scratch should not break or destroy someone else's work. Otherwise you are saying that someone can say "no, Royale should not be PAYG" and rewrite the Basic libraries and I can't do anything about that. That's not how Apache projects are supposed to work.
We have one PMC member who wants to use Maven to do things Ant already does. Why bother? Ant is better for scripting a set of steps. That's why it exists.
Let's fix the current steps and get a release out. I think you'll see that it uses Maven "appropriately". Then make a branch and figure out how you want to make a release. Because we have reproducible binaries, you should be able to have your branch exactly match then next release so we know nothing got missed.
My guess is that the net is going to be to use Maven to tie a bunch of steps together that are currently tied together with Ant. Assuming that Ant is still used to validate the build.xml files and ant task jars.
-Alex
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/18/20, 12:06 PM, "Christofer Dutz" <ch...@c-ware.de> wrote:
Hi Alex,
where is this thrown out?
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-build-tools&data=02%7C01%7Caharui%40adobe.com%7Caaad86012aff4088cfce08d7cb6f68f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201551684695870&sdata=08kAgWKFZq8a15jHOivOq4oB6c2z5XPLKuJmexu3zfs%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Ftree%2Fdevelop%2Fcompiler-jburg-types&data=02%7C01%7Caharui%40adobe.com%7Caaad86012aff4088cfce08d7cb6f68f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201551684695870&sdata=MtfRqNnNQE84twNXGa1ChJKCzt%2FyHAIwMKf47VTy%2FaQ%3D&reserved=0
If you want to release them, all you need to do is go into that directory and run:
mvn release:prepare
mvn release:perform
So as you see nothing is removed ...
there is no need to have them in the same reactor, if that's what you are referring to.
The new documentation does not mention them, so how would someone know to do that? So sure, the new process seems simple but that's because it doesn't document how to handle those two modules.
And the argument to not try something again which had failed in the past is sort of a strange argument for a project discussing on going 1.0
I bet a lot of stuff is in Royale that didn't work before and now works. It's not that we are doing it the same way we did before.
If we did, I agree that would be a stupid waste of time.
AFAICT, you are doing it the same way as before, but I won't know for sure until the set of steps to create a release are documented.
But you didn't answer my question on where it is written that you must build jars used by Ant with Ant.
Would you mind giving an answer on that?
Ant should be used to test Ant. I don't understand how you can test Ant without running Ant.
The Apache Way is about scratching your itch, but it is also about consensus, and the itch you scratch should not break or destroy someone else's work. Otherwise you are saying that someone can say "no, Royale should not be PAYG" and rewrite the Basic libraries and I can't do anything about that. That's not how Apache projects are supposed to work.
We have one PMC member who wants to use Maven to do things Ant already does. Why bother? Ant is better for scripting a set of steps. That's why it exists.
Let's fix the current steps and get a release out. I think you'll see that it uses Maven "appropriately". Then make a branch and figure out how you want to make a release. Because we have reproducible binaries, you should be able to have your branch exactly match then next release so we know nothing got missed.
My guess is that the net is going to be to use Maven to tie a bunch of steps together that are currently tied together with Ant. Assuming that Ant is still used to validate the build.xml files and ant task jars.
-Alex
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
where is this thrown out?
https://github.com/apache/royale-compiler/tree/develop/compiler-build-tools
https://github.com/apache/royale-compiler/tree/develop/compiler-jburg-types
If you want to release them, all you need to do is go into that directory and run:
mvn release:prepare
mvn release:perform
So as you see nothing is removed ...
there is no need to have them in the same reactor, if that's what you are referring to.
And the argument to not try something again which had failed in the past is sort of a strange argument for a project discussing on going 1.0
I bet a lot of stuff is in Royale that didn't work before and now works. It's not that we are doing it the same way we did before.
If we did, I agree that would be a stupid waste of time.
But you didn't answer my question on where it is written that you must build jars used by Ant with Ant.
Would you mind giving an answer on that?
Chris
PS: I've got a PR almost finished gotta do some $stuff for my company first.
Am 18.03.20, 18:59 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
I'm trying to avoid having Carlos and Chris spend a lot of time tossing out something that worked and replacing it with something that didn't work in the past. How often is that a good decision? What makes it hard is that there is a chance it will work for them, and then it won't work for others. That is the lesson we learned the hard way. So we won't know how good it is until someone else tries it and runs into the same issues we had before. Note that the two people who have actually cut a release want to just get the current process to work again. Everyone else is just talking from theory, not reality.
And it will all be moot if we don't get the current process fixed and a release out ASAP.
I only found build instructions at the wiki link that Carlos provided, not release instructions. It made me look at the royale-compiler pom and it appears that the compiler-build-tools and compiler-jburg-types project builds have been removed. So I am not clear on how to build those two artifacts with Maven should we need to change them in the future. This is not raising my level of confidence in their plans at all. It is not fair to toss out important things and then claim things are simpler.
-Alex
On 3/18/20, 10:25 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Agreed. Just do it! You shouldn't need consensus here. If it's as much
better as you claim it will be, I don't see anyone refusing to switch to
the new process. However, if you insist on consensus, let this be my +1.
However, someone else may want to try doing a release with the old process
in the meantime. With that in mind, before you get started on the new
process, you should ensure that the old one is not still broken from the
recent Maven build changes. (It sounds like Chris is already trying to fix
this, so great!)
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=p3GFZuKOAdosdIUUK6YQ7pyrQLAGCrdulrcyfAHUq%2FE%3D&reserved=0>
On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <bi...@gmail.com>
wrote:
> Carlos, Chris,
>
> There is nothing stopping you from building something from scratch. There
> is no need to convince anyone. Please start committing.
>
> I think Alex and others have made their points clearly. I don't see a
> reason to continue rehashing the same points over and over.
>
> As long as the current Ant based build/release is not broken, everyone
> should be happy, or at least learn to live with it.
>
> That said, how can I help with your effort 😊?
>
> Thanks,
> Om
>
>
> On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > El mié., 18 mar. 2020 a las 17:12, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > The proposal I'm seeing takes us back a few years to when others
> > couldn’t
> > > create a release.
> >
> >
> > As I posted in the other thread just a few minutes ago, it's not about to
> > go back and coninue. Our propose is to create something new from scratch,
> > so all that old problems should just gone.
> >
> >
> > --
> > Carlos Rovira
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=N6loQSFF1p1N3AS0%2FDoObELUjgRCMV9I0ylQyuYL4Y8%3D&reserved=0
> >
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Greg Dove <gr...@gmail.com>.
'I'm trying to avoid having Carlos and Chris spend a lot of time tossing
out something that worked and replacing it with something that didn't work
in the past.' 'a chance it will work for them, and then it won't work for
others.'
Based on everything I read which admittedly was quite a lot after I woke up
this morning, that has already been avoided. There is (I believe) agreement
not to replace anything with something that does not work (better).
'...just get the current process to work again.'
It sounds like this is also agreed as a first step, or at least there is a
commitment/activity to do so.
I don't understand this stuff, and have no experience of its 'reality' let
alone much of the 'theory'.
But if
a) the current release system is restored and therefore viable for at least
next release (if we have a RM to use it), and
b) anyone is willing to donate their time to make it (objectively) better
(i.e. easier to use/more reliable/more maintainable)
then that is where I understand we are at. If so, that gets my +1 (which
should not be needed in any case)
On Thu, Mar 19, 2020 at 6:59 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> I'm trying to avoid having Carlos and Chris spend a lot of time tossing
> out something that worked and replacing it with something that didn't work
> in the past. How often is that a good decision? What makes it hard is
> that there is a chance it will work for them, and then it won't work for
> others. That is the lesson we learned the hard way. So we won't know how
> good it is until someone else tries it and runs into the same issues we had
> before. Note that the two people who have actually cut a release want to
> just get the current process to work again. Everyone else is just talking
> from theory, not reality.
>
> And it will all be moot if we don't get the current process fixed and a
> release out ASAP.
>
> I only found build instructions at the wiki link that Carlos provided, not
> release instructions. It made me look at the royale-compiler pom and it
> appears that the compiler-build-tools and compiler-jburg-types project
> builds have been removed. So I am not clear on how to build those two
> artifacts with Maven should we need to change them in the future. This is
> not raising my level of confidence in their plans at all. It is not fair
> to toss out important things and then claim things are simpler.
>
> -Alex
>
> On 3/18/20, 10:25 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Agreed. Just do it! You shouldn't need consensus here. If it's as much
> better as you claim it will be, I don't see anyone refusing to switch
> to
> the new process. However, if you insist on consensus, let this be my
> +1.
>
> However, someone else may want to try doing a release with the old
> process
> in the meantime. With that in mind, before you get started on the new
> process, you should ensure that the old one is not still broken from
> the
> recent Maven build changes. (It sounds like Chris is already trying to
> fix
> this, so great!)
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=p3GFZuKOAdosdIUUK6YQ7pyrQLAGCrdulrcyfAHUq%2FE%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <
> bigosmallm@gmail.com>
> wrote:
>
> > Carlos, Chris,
> >
> > There is nothing stopping you from building something from scratch.
> There
> > is no need to convince anyone. Please start committing.
> >
> > I think Alex and others have made their points clearly. I don't see
> a
> > reason to continue rehashing the same points over and over.
> >
> > As long as the current Ant based build/release is not broken,
> everyone
> > should be happy, or at least learn to live with it.
> >
> > That said, how can I help with your effort 😊?
> >
> > Thanks,
> > Om
> >
> >
> > On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <carlosrovira@apache.org
> >
> > wrote:
> >
> > > Hi Alex,
> > >
> > > El mié., 18 mar. 2020 a las 17:12, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > > > The proposal I'm seeing takes us back a few years to when others
> > > couldn’t
> > > > create a release.
> > >
> > >
> > > As I posted in the other thread just a few minutes ago, it's not
> about to
> > > go back and coninue. Our propose is to create something new from
> scratch,
> > > so all that old problems should just gone.
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=N6loQSFF1p1N3AS0%2FDoObELUjgRCMV9I0ylQyuYL4Y8%3D&reserved=0
> > >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Mar 18, 2020 at 10:59 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> I'm trying to avoid having Carlos and Chris spend a lot of time tossing
> out something that worked and replacing it with something that didn't work
> in the past. How often is that a good decision?
Alex, we have been through this before. I don't think you will be able to
convince them otherwise. Maybe they can make things better this time. It
is just software - why do you think it is impossible to fix something that
dint work in the past?
> What makes it hard is that there is a chance it will work for them, and
> then it won't work for others.
That is the lesson we learned the hard way. So we won't know how good it
> is until someone else tries it and runs into the same issues we had before.
Let's give it a shot and see if others can run it.
> Note that the two people who have actually cut a release want to just get
> the current process to work again. Everyone else is just talking from
> theory, not reality.
>
There are a lot of Apache projects and companies who use Maven every day.
That is not theory.
>
> And it will all be moot if we don't get the current process fixed and a
> release out ASAP.
>
No one is stopping you are anyone else from releasing. Chris is already
working on a fix for what was broken.
>
> I only found build instructions at the wiki link that Carlos provided, not
> release instructions. It made me look at the royale-compiler pom and it
> appears that the compiler-build-tools and compiler-jburg-types project
> builds have been removed. So I am not clear on how to build those two
> artifacts with Maven should we need to change them in the future. This is
> not raising my level of confidence in their plans at all. It is not fair
> to toss out important things and then claim things are simpler.
> -Alex
>
> On 3/18/20, 10:25 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Agreed. Just do it! You shouldn't need consensus here. If it's as much
> better as you claim it will be, I don't see anyone refusing to switch
> to
> the new process. However, if you insist on consensus, let this be my
> +1.
>
> However, someone else may want to try doing a release with the old
> process
> in the meantime. With that in mind, before you get started on the new
> process, you should ensure that the old one is not still broken from
> the
> recent Maven build changes. (It sounds like Chris is already trying to
> fix
> this, so great!)
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=p3GFZuKOAdosdIUUK6YQ7pyrQLAGCrdulrcyfAHUq%2FE%3D&reserved=0
> >
>
>
> On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <
> bigosmallm@gmail.com>
> wrote:
>
> > Carlos, Chris,
> >
> > There is nothing stopping you from building something from scratch.
> There
> > is no need to convince anyone. Please start committing.
> >
> > I think Alex and others have made their points clearly. I don't see
> a
> > reason to continue rehashing the same points over and over.
> >
> > As long as the current Ant based build/release is not broken,
> everyone
> > should be happy, or at least learn to live with it.
> >
> > That said, how can I help with your effort 😊?
> >
> > Thanks,
> > Om
> >
> >
> > On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <carlosrovira@apache.org
> >
> > wrote:
> >
> > > Hi Alex,
> > >
> > > El mié., 18 mar. 2020 a las 17:12, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > > > The proposal I'm seeing takes us back a few years to when others
> > > couldn’t
> > > > create a release.
> > >
> > >
> > > As I posted in the other thread just a few minutes ago, it's not
> about to
> > > go back and coninue. Our propose is to create something new from
> scratch,
> > > so all that old problems should just gone.
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=N6loQSFF1p1N3AS0%2FDoObELUjgRCMV9I0ylQyuYL4Y8%3D&reserved=0
> > >
> >
>
>
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm trying to avoid having Carlos and Chris spend a lot of time tossing out something that worked and replacing it with something that didn't work in the past. How often is that a good decision? What makes it hard is that there is a chance it will work for them, and then it won't work for others. That is the lesson we learned the hard way. So we won't know how good it is until someone else tries it and runs into the same issues we had before. Note that the two people who have actually cut a release want to just get the current process to work again. Everyone else is just talking from theory, not reality.
And it will all be moot if we don't get the current process fixed and a release out ASAP.
I only found build instructions at the wiki link that Carlos provided, not release instructions. It made me look at the royale-compiler pom and it appears that the compiler-build-tools and compiler-jburg-types project builds have been removed. So I am not clear on how to build those two artifacts with Maven should we need to change them in the future. This is not raising my level of confidence in their plans at all. It is not fair to toss out important things and then claim things are simpler.
-Alex
On 3/18/20, 10:25 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Agreed. Just do it! You shouldn't need consensus here. If it's as much
better as you claim it will be, I don't see anyone refusing to switch to
the new process. However, if you insist on consensus, let this be my +1.
However, someone else may want to try doing a release with the old process
in the meantime. With that in mind, before you get started on the new
process, you should ensure that the old one is not still broken from the
recent Maven build changes. (It sounds like Chris is already trying to fix
this, so great!)
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=p3GFZuKOAdosdIUUK6YQ7pyrQLAGCrdulrcyfAHUq%2FE%3D&reserved=0>
On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <bi...@gmail.com>
wrote:
> Carlos, Chris,
>
> There is nothing stopping you from building something from scratch. There
> is no need to convince anyone. Please start committing.
>
> I think Alex and others have made their points clearly. I don't see a
> reason to continue rehashing the same points over and over.
>
> As long as the current Ant based build/release is not broken, everyone
> should be happy, or at least learn to live with it.
>
> That said, how can I help with your effort 😊?
>
> Thanks,
> Om
>
>
> On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > El mié., 18 mar. 2020 a las 17:12, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > The proposal I'm seeing takes us back a few years to when others
> > couldn’t
> > > create a release.
> >
> >
> > As I posted in the other thread just a few minutes ago, it's not about to
> > go back and coninue. Our propose is to create something new from scratch,
> > so all that old problems should just gone.
> >
> >
> > --
> > Carlos Rovira
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caaac0c3693294c72c62608d7cb614ad0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201491043736972&sdata=N6loQSFF1p1N3AS0%2FDoObELUjgRCMV9I0ylQyuYL4Y8%3D&reserved=0
> >
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Agreed. Just do it! You shouldn't need consensus here. If it's as much
better as you claim it will be, I don't see anyone refusing to switch to
the new process. However, if you insist on consensus, let this be my +1.
However, someone else may want to try doing a release with the old process
in the meantime. With that in mind, before you get started on the new
process, you should ensure that the old one is not still broken from the
recent Maven build changes. (It sounds like Chris is already trying to fix
this, so great!)
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Mar 18, 2020 at 9:50 AM OmPrakash Muppirala <bi...@gmail.com>
wrote:
> Carlos, Chris,
>
> There is nothing stopping you from building something from scratch. There
> is no need to convince anyone. Please start committing.
>
> I think Alex and others have made their points clearly. I don't see a
> reason to continue rehashing the same points over and over.
>
> As long as the current Ant based build/release is not broken, everyone
> should be happy, or at least learn to live with it.
>
> That said, how can I help with your effort 😊?
>
> Thanks,
> Om
>
>
> On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > El mié., 18 mar. 2020 a las 17:12, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > The proposal I'm seeing takes us back a few years to when others
> > couldn’t
> > > create a release.
> >
> >
> > As I posted in the other thread just a few minutes ago, it's not about to
> > go back and coninue. Our propose is to create something new from scratch,
> > so all that old problems should just gone.
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Carlos, Chris,
There is nothing stopping you from building something from scratch. There
is no need to convince anyone. Please start committing.
I think Alex and others have made their points clearly. I don't see a
reason to continue rehashing the same points over and over.
As long as the current Ant based build/release is not broken, everyone
should be happy, or at least learn to live with it.
That said, how can I help with your effort 😊?
Thanks,
Om
On Wed, Mar 18, 2020, 9:38 AM Carlos Rovira <ca...@apache.org> wrote:
> Hi Alex,
>
> El mié., 18 mar. 2020 a las 17:12, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > The proposal I'm seeing takes us back a few years to when others
> couldn’t
> > create a release.
>
>
> As I posted in the other thread just a few minutes ago, it's not about to
> go back and coninue. Our propose is to create something new from scratch,
> so all that old problems should just gone.
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
El mié., 18 mar. 2020 a las 17:12, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> The proposal I'm seeing takes us back a few years to when others couldn’t
> create a release.
As I posted in the other thread just a few minutes ago, it's not about to
go back and coninue. Our propose is to create something new from scratch,
so all that old problems should just gone.
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex
docs updates for Maven steps are here:
https://github.com/apache/royale-asjs/wiki/Build-Apache-Royale-with-Maven
El mié., 18 mar. 2020 a las 17:12, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> First, thanks for cleaning up the Maven build. I haven't looked at it in
> detail but if the profiles are better organized, that's great.
>
> We have different opinions on what will move the project forward. The
> proposal I'm seeing takes us back a few years to when others couldn’t
> create a release. It has nothing to do with Maven per-se. The actual
> issues were that for some reason, the uploading process kept failing for
> people, and there folks sometimes had trouble getting setup. The CI server
> gives us a known working configuration so we don't have to worry about
> setup issues on the RM's computer. It has a side benefit that if the RM
> runs out of time, another person can take over.
>
> A Jar built for Ant must be tested by Ant before putting the artifacts up
> for a vote. So, you must have Ant and use it at some point in the release
> process. Also, since we want to make sure that there is a working Ant
> script to build an IDE compatible release, it is best to use that Ant
> script to create the artifacts, in order to prove that it works.
>
> And, I've written this many times, if we need to support some third build
> system, I expect we would use that build system to build the artifacts for
> that system.
>
> Getting the Maven changes to work for CI should be as simple as
> re-introducing the noPush and skipGPG options. But I would know more if I
> could find the current instructions on how to build the artifacts for
> Maven. Where is that now documented?
>
> -Alex
>
> On 3/18/20, 8:37 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>
> Ok ... as it sort of feels silly to not respond to this list, but read
> it ... here goes ;-)
>
> Shouldn't the metric be: "does it bring the project forward?" and less
> "how much time did it cost to get here?"
> In PLC4X I recently deleted code that took me more than 3/4 of a year
> to write in more than full-time work. No commit felt better as it improved
> things greatly and what we replaced it with, was a giant leap for the
> project.
>
> So if you folks could explain what the refactoring I did some time ago
> broke ...
>
> And perhaps let me explain the reason for doing it in the first place:
> I really loved and still love the productivity I had with Apache Flex.
> I was consumed with counting and shifting bits, however knowing I need a
> frontend eventually. I was hoping that Royale was going to be that option.
> However I did notice with worries how long it took to get new releases out
> the door and hearing rumors about how many people invested so much time and
> some still failed. So I offered my assistance and had a look at the build.
> Being an expert in this particular area, I did notice some configuration
> "problems" or "misconfigurations", which I fixed. Usually if you need
> something special for some reason it's a good practice to write a comment
> to it in order for the person viewing the code to know the implications and
> reasoning behind this.
>
> You can't expect every newcomer to parse the last few years of
> discussions before contributing.
>
> Another reason was that I remembered that one of the "objections" to
> Maven was, that Maven couldn't do reproducible builds. So as the latest
> versions of the core maven plugins were updated to support this, I thought,
> perhaps this way we could get a stable release process.
>
> From a Maven point of view the updated Maven build is now rock-solid.
> Releasing it would require two timely separated sessions and 3 commands in
> total and would be done on the developer machine.
> 1) Create the release branch
> 2) Prepare and do the release
>
> The issues you folks were having ... I can't really confirm them ...
> Just to day I did a check of how many Apache project use which build tool.
> The result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was
> that broken, I guess we would be hearing a lot more from the other
> projects. And I am not hearing any complaints at all.
>
> If the distributions are currently not 100% match of the Ant ones, I
> would like to help to make them one. Just tell me what the difference is
> and it'll be done in no-time. However it's hard to fix something you don't
> know what's broken.
>
> Also do I not quite understand why a jar used in Ant has to be built
> by Ant ... in general the jars should be identical. I know that maven saves
> some additional information in the pom (Actually storing the pom and the
> values properties had when it was built in the jar, which I think is a
> great thing for reproducibility). Perhaps disabling this could make them
> identical. And as soon as that's the case, I don't really see the point in
> building them twice. Do you agree?
>
> And no worries, I am not interested in joining the project again ... I
> want to help the project be able to get releases out because I would like
> to use them. After that's done I'm happy to disappear again, if you wish
> that I do.
>
> So far all the projects I have helped with their builds are firing out
> releases like machine-guns ... let me help you folks do so too.
>
> Chris
>
>
>
>
>
> Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <piotrzarzycki21@gmail.com
> >:
>
> Btw. I truly doubt that it would be bigger than time which was
> invested in
> building this whole release process.
>
> śr., 18 mar 2020 o 12:41 Piotr Zarzycki <piotrzarzycki21@gmail.com
> >
> napisał(a):
>
> > Carlos,
> >
> > Why it is so huge effort ? What was broken so much that you are
> talking
> > about huge effort ?
> >
> > śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >> as I responded before, I think that will be a huge task, in
> effort and
> >> time, and a task that can be easily broken again as any other
> one
> >> introduces new changes, what is something will happen for sure
> as we
> >> evolve. So what I'm offering is my time to be used in a way
> that can allow
> >> us to have a more reliable workflow. If I work on trying to fix
> as it's
> >> now, I probably will not succeed since I already tried for
> several hours
> >> and days (you can check emails around 19 or 20th Nov I think),
> and nothing
> >> of my tries could make a difference. Instead, I'm think taking
> a big
> >> different approach can make a difference. I can be wrong, but
> in that
> >> case,
> >> we'll know for sure that the way to go is the current one.
> >>
> >>
> >> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
> >> piotrzarzycki21@gmail.com>) escribió:
> >>
> >> > Carlos,
> >> >
> >> > In the other ways you are not going to fix current steps and
> release new
> >> > version of SDK ?
> >> >
> >> >
> >> >
> >> > śr., 18 mar 2020 o 10:39 Carlos Rovira <
> carlosrovira@apache.org>
> >> > napisał(a):
> >> >
> >> > > Hi all and thanks for your responses:
> >> > >
> >> > > @greg, yes the plan I point is to do research to try a new
> way and see
> >> > > where we go. At the end, we don't get it, it will be our
> >> responsibility
> >> > and
> >> > > our time.
> >> > >
> >> > > @yishay, I think you state a concrete but very real issue.
> I think the
> >> > work
> >> > > done by Alex was amazing (no doubt here), but I'm afraid,
> as much as
> >> it
> >> > > pains me to say it, that it does not solve the problem you
> state and
> >> the
> >> > > proof is that only Piotr tried to use the process and it
> was not easy
> >> and
> >> > > then when fixing other things, it has broken with some ease.
> >> > >
> >> > > @om, as I said in the initial email. There's no war anymore
> between
> >> Maven
> >> > > and ANT. We all want both, and I'm using both when
> developing Royale
> >> to
> >> > > test. As well I continually know more about how things are
> done in
> >> Maven.
> >> > > My position is just that we need to separate concerns. One
> thing is to
> >> > have
> >> > > both systems for developers and user to use (Maven and
> ANT), but my
> >> point
> >> > > is that Releasing should just involve Maven, since is more
> suite for
> >> > > releasing at Apache and CIs, and ensure Ant continue
> working as
> >> expected.
> >> > > So no one wants one over the other, or remove one of them.
> That's not
> >> the
> >> > > problem anymore.
> >> > >
> >> > > @piotr, I think your experience is very important, since
> you were the
> >> > only
> >> > > one that do the full process. My guess is that removing ANT
> from the
> >> > > release process will remove completely all the pain with
> such complex
> >> > > process and we all be able release from our own machines
> without
> >> having
> >> > > problems with complex task, uploading artifacts to a.o and
> more. We
> >> just
> >> > > need to ensure ANT still can be build exactly as before,
> and continue
> >> to
> >> > > produce the same.
> >> > >
> >> > > So in the end, we can stick with the old process, or try
> another
> >> > different
> >> > > approach to it build over standards. That means Chris and I
> will be
> >> using
> >> > > our times not yours. If we succeed, your test of the new
> approach will
> >> > need
> >> > > to ensure all the prerequisites and be lot more simpler. If
> we don't
> >> get
> >> > to
> >> > > that and fail in the process, just announce here and we can
> continue
> >> in
> >> > the
> >> > > old process.
> >> > >
> >> > > That's my proposal (that will need to be consensuated first
> here and
> >> then
> >> > > with Chris)
> >> > >
> >> > > Thanks
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
> >> (<aharui@adobe.com.invalid
> >> > >)
> >> > > escribió:
> >> > >
> >> > > >
> >> > > >
> >> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <
> bigosmallm@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > My 2 cents:
> >> > > >
> >> > > > I don't think we need to go back to the Ant vs Maven
> discussion.
> >> > If
> >> > > > the
> >> > > > Maven build/stage/release scripts works flawlessly,
> an Ant task
> >> can
> >> > > > simply
> >> > > > call it. There is no reason both cannot be worked on
> >> continuously.
> >> > > > In the
> >> > > > same way, if Maven users want, they can call Ant
> scripts as
> >> needed.
> >> > > >
> >> > > > Why do both camps want the other way to go away?
> >> > > >
> >> > > > I don't want one to go away. I want to use Maven for
> what it is
> >> good
> >> > for
> >> > > > and Ant for what it is good for.
> >> > > >
> >> > > > For example, we also publish to NPM as part of the
> release.
> >> There
> >> > is
> >> > > a
> >> > > > node.js script that gets called from the Ant script
> during the
> >> > > release
> >> > > > process. The node.js script is a black box as far as
> the Ant
> >> > script
> >> > > is
> >> > > > concerned.
> >> > > >
> >> > > > That said, Carlos if you think you can get a release
> done with
> >> just
> >> > > > Maven,
> >> > > > please go ahead and give it a shot. From what I
> remember, the
> >> > Maven
> >> > > > part
> >> > > > of the build/release was the issue and not the Ant
> portions. We
> >> > all
> >> > > > would
> >> > > > love to see improvements there.
> >> > > >
> >> > > > Alex, you say that Carlos did not work in the
> trenches during
> >> the
> >> > > > release
> >> > > > process, but are objecting (I think, if I understand
> your email
> >> > > > correctly)
> >> > > > to him wanting to work now. That seem contradictory,
> IMHO.
> >> > > >
> >> > > > I'm saying that if Carlos/Chris go back to the Maven
> Release Plugin
> >> > > > process, it will likely bring us back to the same
> problems we
> >> created
> >> > the
> >> > > > CI steps to work around. So why go through all of that
> again?
> >> > > >
> >> > > > Like Piotr just posted, Carlos should get in the trenches
> and get
> >> the
> >> > CI
> >> > > > steps to work with the new Maven poms. Not
> acknowledging that
> >> there
> >> > > have
> >> > > > been past problems using the process they propose is
> going to
> >> result in
> >> > > > more time wasted.
> >> > > >
> >> > > > -Alex
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=jntOAxG3gWC1G6%2BdmIjQrR2cj%2BJzv3AOQyeAE6B4cjU%3D&reserved=0
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Piotr Zarzycki
> >> >
> >> > Patreon: *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=4zgoM3oKO7ZSDBMbEjAQCKvck9Tel%2FUrZ779AMLkTiQ%3D&reserved=0
> >> > <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=4zgoM3oKO7ZSDBMbEjAQCKvck9Tel%2FUrZ779AMLkTiQ%3D&reserved=0
> >*
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=jntOAxG3gWC1G6%2BdmIjQrR2cj%2BJzv3AOQyeAE6B4cjU%3D&reserved=0
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0
> > <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0
> >*
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0
> >*
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
First, thanks for cleaning up the Maven build. I haven't looked at it in detail but if the profiles are better organized, that's great.
We have different opinions on what will move the project forward. The proposal I'm seeing takes us back a few years to when others couldn’t create a release. It has nothing to do with Maven per-se. The actual issues were that for some reason, the uploading process kept failing for people, and there folks sometimes had trouble getting setup. The CI server gives us a known working configuration so we don't have to worry about setup issues on the RM's computer. It has a side benefit that if the RM runs out of time, another person can take over.
A Jar built for Ant must be tested by Ant before putting the artifacts up for a vote. So, you must have Ant and use it at some point in the release process. Also, since we want to make sure that there is a working Ant script to build an IDE compatible release, it is best to use that Ant script to create the artifacts, in order to prove that it works.
And, I've written this many times, if we need to support some third build system, I expect we would use that build system to build the artifacts for that system.
Getting the Maven changes to work for CI should be as simple as re-introducing the noPush and skipGPG options. But I would know more if I could find the current instructions on how to build the artifacts for Maven. Where is that now documented?
-Alex
On 3/18/20, 8:37 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
Ok ... as it sort of feels silly to not respond to this list, but read it ... here goes ;-)
Shouldn't the metric be: "does it bring the project forward?" and less "how much time did it cost to get here?"
In PLC4X I recently deleted code that took me more than 3/4 of a year to write in more than full-time work. No commit felt better as it improved things greatly and what we replaced it with, was a giant leap for the project.
So if you folks could explain what the refactoring I did some time ago broke ...
And perhaps let me explain the reason for doing it in the first place:
I really loved and still love the productivity I had with Apache Flex. I was consumed with counting and shifting bits, however knowing I need a frontend eventually. I was hoping that Royale was going to be that option. However I did notice with worries how long it took to get new releases out the door and hearing rumors about how many people invested so much time and some still failed. So I offered my assistance and had a look at the build. Being an expert in this particular area, I did notice some configuration "problems" or "misconfigurations", which I fixed. Usually if you need something special for some reason it's a good practice to write a comment to it in order for the person viewing the code to know the implications and reasoning behind this.
You can't expect every newcomer to parse the last few years of discussions before contributing.
Another reason was that I remembered that one of the "objections" to Maven was, that Maven couldn't do reproducible builds. So as the latest versions of the core maven plugins were updated to support this, I thought, perhaps this way we could get a stable release process.
From a Maven point of view the updated Maven build is now rock-solid. Releasing it would require two timely separated sessions and 3 commands in total and would be done on the developer machine.
1) Create the release branch
2) Prepare and do the release
The issues you folks were having ... I can't really confirm them ... Just to day I did a check of how many Apache project use which build tool. The result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that broken, I guess we would be hearing a lot more from the other projects. And I am not hearing any complaints at all.
If the distributions are currently not 100% match of the Ant ones, I would like to help to make them one. Just tell me what the difference is and it'll be done in no-time. However it's hard to fix something you don't know what's broken.
Also do I not quite understand why a jar used in Ant has to be built by Ant ... in general the jars should be identical. I know that maven saves some additional information in the pom (Actually storing the pom and the values properties had when it was built in the jar, which I think is a great thing for reproducibility). Perhaps disabling this could make them identical. And as soon as that's the case, I don't really see the point in building them twice. Do you agree?
And no worries, I am not interested in joining the project again ... I want to help the project be able to get releases out because I would like to use them. After that's done I'm happy to disappear again, if you wish that I do.
So far all the projects I have helped with their builds are firing out releases like machine-guns ... let me help you folks do so too.
Chris
Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <pi...@gmail.com>:
Btw. I truly doubt that it would be bigger than time which was invested in
building this whole release process.
śr., 18 mar 2020 o 12:41 Piotr Zarzycki <pi...@gmail.com>
napisał(a):
> Carlos,
>
> Why it is so huge effort ? What was broken so much that you are talking
> about huge effort ?
>
> śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
>> Hi Piotr,
>>
>> as I responded before, I think that will be a huge task, in effort and
>> time, and a task that can be easily broken again as any other one
>> introduces new changes, what is something will happen for sure as we
>> evolve. So what I'm offering is my time to be used in a way that can allow
>> us to have a more reliable workflow. If I work on trying to fix as it's
>> now, I probably will not succeed since I already tried for several hours
>> and days (you can check emails around 19 or 20th Nov I think), and nothing
>> of my tries could make a difference. Instead, I'm think taking a big
>> different approach can make a difference. I can be wrong, but in that
>> case,
>> we'll know for sure that the way to go is the current one.
>>
>>
>> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
>> piotrzarzycki21@gmail.com>) escribió:
>>
>> > Carlos,
>> >
>> > In the other ways you are not going to fix current steps and release new
>> > version of SDK ?
>> >
>> >
>> >
>> > śr., 18 mar 2020 o 10:39 Carlos Rovira <ca...@apache.org>
>> > napisał(a):
>> >
>> > > Hi all and thanks for your responses:
>> > >
>> > > @greg, yes the plan I point is to do research to try a new way and see
>> > > where we go. At the end, we don't get it, it will be our
>> responsibility
>> > and
>> > > our time.
>> > >
>> > > @yishay, I think you state a concrete but very real issue. I think the
>> > work
>> > > done by Alex was amazing (no doubt here), but I'm afraid, as much as
>> it
>> > > pains me to say it, that it does not solve the problem you state and
>> the
>> > > proof is that only Piotr tried to use the process and it was not easy
>> and
>> > > then when fixing other things, it has broken with some ease.
>> > >
>> > > @om, as I said in the initial email. There's no war anymore between
>> Maven
>> > > and ANT. We all want both, and I'm using both when developing Royale
>> to
>> > > test. As well I continually know more about how things are done in
>> Maven.
>> > > My position is just that we need to separate concerns. One thing is to
>> > have
>> > > both systems for developers and user to use (Maven and ANT), but my
>> point
>> > > is that Releasing should just involve Maven, since is more suite for
>> > > releasing at Apache and CIs, and ensure Ant continue working as
>> expected.
>> > > So no one wants one over the other, or remove one of them. That's not
>> the
>> > > problem anymore.
>> > >
>> > > @piotr, I think your experience is very important, since you were the
>> > only
>> > > one that do the full process. My guess is that removing ANT from the
>> > > release process will remove completely all the pain with such complex
>> > > process and we all be able release from our own machines without
>> having
>> > > problems with complex task, uploading artifacts to a.o and more. We
>> just
>> > > need to ensure ANT still can be build exactly as before, and continue
>> to
>> > > produce the same.
>> > >
>> > > So in the end, we can stick with the old process, or try another
>> > different
>> > > approach to it build over standards. That means Chris and I will be
>> using
>> > > our times not yours. If we succeed, your test of the new approach will
>> > need
>> > > to ensure all the prerequisites and be lot more simpler. If we don't
>> get
>> > to
>> > > that and fail in the process, just announce here and we can continue
>> in
>> > the
>> > > old process.
>> > >
>> > > That's my proposal (that will need to be consensuated first here and
>> then
>> > > with Chris)
>> > >
>> > > Thanks
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
>> (<aharui@adobe.com.invalid
>> > >)
>> > > escribió:
>> > >
>> > > >
>> > > >
>> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <bi...@gmail.com>
>> > > wrote:
>> > > >
>> > > > My 2 cents:
>> > > >
>> > > > I don't think we need to go back to the Ant vs Maven discussion.
>> > If
>> > > > the
>> > > > Maven build/stage/release scripts works flawlessly, an Ant task
>> can
>> > > > simply
>> > > > call it. There is no reason both cannot be worked on
>> continuously.
>> > > > In the
>> > > > same way, if Maven users want, they can call Ant scripts as
>> needed.
>> > > >
>> > > > Why do both camps want the other way to go away?
>> > > >
>> > > > I don't want one to go away. I want to use Maven for what it is
>> good
>> > for
>> > > > and Ant for what it is good for.
>> > > >
>> > > > For example, we also publish to NPM as part of the release.
>> There
>> > is
>> > > a
>> > > > node.js script that gets called from the Ant script during the
>> > > release
>> > > > process. The node.js script is a black box as far as the Ant
>> > script
>> > > is
>> > > > concerned.
>> > > >
>> > > > That said, Carlos if you think you can get a release done with
>> just
>> > > > Maven,
>> > > > please go ahead and give it a shot. From what I remember, the
>> > Maven
>> > > > part
>> > > > of the build/release was the issue and not the Ant portions. We
>> > all
>> > > > would
>> > > > love to see improvements there.
>> > > >
>> > > > Alex, you say that Carlos did not work in the trenches during
>> the
>> > > > release
>> > > > process, but are objecting (I think, if I understand your email
>> > > > correctly)
>> > > > to him wanting to work now. That seem contradictory, IMHO.
>> > > >
>> > > > I'm saying that if Carlos/Chris go back to the Maven Release Plugin
>> > > > process, it will likely bring us back to the same problems we
>> created
>> > the
>> > > > CI steps to work around. So why go through all of that again?
>> > > >
>> > > > Like Piotr just posted, Carlos should get in the trenches and get
>> the
>> > CI
>> > > > steps to work with the new Maven poms. Not acknowledging that
>> there
>> > > have
>> > > > been past problems using the process they propose is going to
>> result in
>> > > > more time wasted.
>> > > >
>> > > > -Alex
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > > --
>> > > Carlos Rovira
>> > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=jntOAxG3gWC1G6%2BdmIjQrR2cj%2BJzv3AOQyeAE6B4cjU%3D&reserved=0
>> > >
>> >
>> >
>> > --
>> >
>> > Piotr Zarzycki
>> >
>> > Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=4zgoM3oKO7ZSDBMbEjAQCKvck9Tel%2FUrZ779AMLkTiQ%3D&reserved=0
>> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=4zgoM3oKO7ZSDBMbEjAQCKvck9Tel%2FUrZ779AMLkTiQ%3D&reserved=0>*
>> >
>>
>>
>> --
>> Carlos Rovira
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743097976&sdata=jntOAxG3gWC1G6%2BdmIjQrR2cj%2BJzv3AOQyeAE6B4cjU%3D&reserved=0
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0>*
>
--
Piotr Zarzycki
Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb645a795c0b7436c632c08d7cb525233%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201426743107970&sdata=LiB4Gl1fkwdUCQMU8Uo2LdkU07xqRrNH7cC86qHIjOU%3D&reserved=0>*
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Alex,
I think you are judging this plugin's functionality from its name, which I always thought is misleading.
It's not the main goal of this plugin to invoke things. It's an integration test-tool for maven plugins.
It does what it does by invoking maven builds (Therefore the name).
With the invoker plugin you can define a number of projects which are built as separate integration tests.
For each test-projcect you can even define an acceptance test where the output is inspected. I would much more trust a real test than just not getting an error in a build. I remember adding the UI integration tests in the framework module after noticing we were building FlexJS for days but due to some changes in the compiler (I think) the build did not fail, but the output didn't work and this wasn't discovered as we didn't have any sort of test)
And replying to your other email:
"A Jar built for Ant must be tested by Ant before putting the artifacts up for a vote. So, you must have Ant and use it at some point in the release process. Also, since we want to make sure that there is a working Ant script to build an IDE compatible release, it is best to use that Ant script to create the artifacts, in order to prove that it works."
Where is this requirement written down? It's definitely not an Ant and not an ASF requirement.
If it's a Royale requirement I would like to challenge that.
In the end we're actually not building Jars for ANT, but for the Java VM and that's the same in both cases.
If I have two ways to produce the same output, I can't see the need to actually go both paths.
Of course, it would be good to be able to verify a staged build. And jusding from Royales recent vote threads, I would doubt that a single PMC who voted actually built the SDK from the sources locally and checked the staged release-candidate for binary equality ... at least I couldn't find any reference to that in the vote emails. (That's something the maven team is currently working on)
I think it shouldn't be a problem to create a profile that tweaks the parts needed on the CI server ... that's actually a quite common pattern.
So the problem is that the release:prepare step pushes it's changes and that the gpg plugin signs the artifacts, correct?
I'll whip up a PR for fixing that ASAP.
Chris
Am 18.03.20, 17:17 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
On 3/18/20, 9:12 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
We could use the maven-invoker-plugin to execute a number of Ant builds.
This way we could ensure the Ant tasks work correctly.
Would that be an option?
Of course it is an option, but I do not like it. IMO, invoker is just a verbose Maven way of doing what Ant does. As I just posted, IMO we still need to run Ant at some point, so why not use Ant for scripting? That's what it is meant for.
Please, can we just try to fix the CI steps? Add the noPush and skipGPG params. Tell me where I can read what the steps are.
-Alex
Chris
Am 18.03.20, 16:54 schrieb "Carlos Rovira" <ca...@apache.org>:
Hi Chris,
thanks for joining the conversation :)
About "creating artifacts two times", I think we should just create one
with Maven *for the release process*, while ensuring ANT continues to work
as expected, since many people rely on it. So maybe the solution is:
0.- we need to fix the Maven distribution for IDE compilation (this is
independent of the release process, since is needed)
---
1.- make all the release process using the 2 steps you said
2.- check the ant build by adding a step that generates it and then check
agains the reproducible maven build distribution
(for this we need to find a way to check that distribution is generating
the same SDK as ANT, can that be done?)
For me that means removing lots of problems and ease the overall process
Make this sense?
El mié., 18 mar. 2020 a las 16:37, Christofer Dutz (<
christofer.dutz@c-ware.de>) escribió:
> Ok ... as it sort of feels silly to not respond to this list, but read it
> ... here goes ;-)
>
> Shouldn't the metric be: "does it bring the project forward?" and less
> "how much time did it cost to get here?"
> In PLC4X I recently deleted code that took me more than 3/4 of a year to
> write in more than full-time work. No commit felt better as it improved
> things greatly and what we replaced it with, was a giant leap for the
> project.
>
> So if you folks could explain what the refactoring I did some time ago
> broke ...
>
> And perhaps let me explain the reason for doing it in the first place:
> I really loved and still love the productivity I had with Apache Flex. I
> was consumed with counting and shifting bits, however knowing I need a
> frontend eventually. I was hoping that Royale was going to be that option.
> However I did notice with worries how long it took to get new releases out
> the door and hearing rumors about how many people invested so much time and
> some still failed. So I offered my assistance and had a look at the build.
> Being an expert in this particular area, I did notice some configuration
> "problems" or "misconfigurations", which I fixed. Usually if you need
> something special for some reason it's a good practice to write a comment
> to it in order for the person viewing the code to know the implications and
> reasoning behind this.
>
> You can't expect every newcomer to parse the last few years of discussions
> before contributing.
>
> Another reason was that I remembered that one of the "objections" to Maven
> was, that Maven couldn't do reproducible builds. So as the latest versions
> of the core maven plugins were updated to support this, I thought, perhaps
> this way we could get a stable release process.
>
> From a Maven point of view the updated Maven build is now rock-solid.
> Releasing it would require two timely separated sessions and 3 commands in
> total and would be done on the developer machine.
> 1) Create the release branch
> 2) Prepare and do the release
>
> The issues you folks were having ... I can't really confirm them ... Just
> to day I did a check of how many Apache project use which build tool. The
> result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that
> broken, I guess we would be hearing a lot more from the other projects. And
> I am not hearing any complaints at all.
>
> If the distributions are currently not 100% match of the Ant ones, I would
> like to help to make them one. Just tell me what the difference is and
> it'll be done in no-time. However it's hard to fix something you don't know
> what's broken.
>
> Also do I not quite understand why a jar used in Ant has to be built by
> Ant ... in general the jars should be identical. I know that maven saves
> some additional information in the pom (Actually storing the pom and the
> values properties had when it was built in the jar, which I think is a
> great thing for reproducibility). Perhaps disabling this could make them
> identical. And as soon as that's the case, I don't really see the point in
> building them twice. Do you agree?
>
> And no worries, I am not interested in joining the project again ... I
> want to help the project be able to get releases out because I would like
> to use them. After that's done I'm happy to disappear again, if you wish
> that I do.
>
> So far all the projects I have helped with their builds are firing out
> releases like machine-guns ... let me help you folks do so too.
>
> Chris
>
>
>
>
>
> Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <pi...@gmail.com>:
>
> Btw. I truly doubt that it would be bigger than time which was
> invested in
> building this whole release process.
>
> śr., 18 mar 2020 o 12:41 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
> > Carlos,
> >
> > Why it is so huge effort ? What was broken so much that you are
> talking
> > about huge effort ?
> >
> > śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >> as I responded before, I think that will be a huge task, in effort
> and
> >> time, and a task that can be easily broken again as any other one
> >> introduces new changes, what is something will happen for sure as we
> >> evolve. So what I'm offering is my time to be used in a way that
> can allow
> >> us to have a more reliable workflow. If I work on trying to fix as
> it's
> >> now, I probably will not succeed since I already tried for several
> hours
> >> and days (you can check emails around 19 or 20th Nov I think), and
> nothing
> >> of my tries could make a difference. Instead, I'm think taking a big
> >> different approach can make a difference. I can be wrong, but in
> that
> >> case,
> >> we'll know for sure that the way to go is the current one.
> >>
> >>
> >> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
> >> piotrzarzycki21@gmail.com>) escribió:
> >>
> >> > Carlos,
> >> >
> >> > In the other ways you are not going to fix current steps and
> release new
> >> > version of SDK ?
> >> >
> >> >
> >> >
> >> > śr., 18 mar 2020 o 10:39 Carlos Rovira <ca...@apache.org>
> >> > napisał(a):
> >> >
> >> > > Hi all and thanks for your responses:
> >> > >
> >> > > @greg, yes the plan I point is to do research to try a new way
> and see
> >> > > where we go. At the end, we don't get it, it will be our
> >> responsibility
> >> > and
> >> > > our time.
> >> > >
> >> > > @yishay, I think you state a concrete but very real issue. I
> think the
> >> > work
> >> > > done by Alex was amazing (no doubt here), but I'm afraid, as
> much as
> >> it
> >> > > pains me to say it, that it does not solve the problem you
> state and
> >> the
> >> > > proof is that only Piotr tried to use the process and it was
> not easy
> >> and
> >> > > then when fixing other things, it has broken with some ease.
> >> > >
> >> > > @om, as I said in the initial email. There's no war anymore
> between
> >> Maven
> >> > > and ANT. We all want both, and I'm using both when developing
> Royale
> >> to
> >> > > test. As well I continually know more about how things are done
> in
> >> Maven.
> >> > > My position is just that we need to separate concerns. One
> thing is to
> >> > have
> >> > > both systems for developers and user to use (Maven and ANT),
> but my
> >> point
> >> > > is that Releasing should just involve Maven, since is more
> suite for
> >> > > releasing at Apache and CIs, and ensure Ant continue working as
> >> expected.
> >> > > So no one wants one over the other, or remove one of them.
> That's not
> >> the
> >> > > problem anymore.
> >> > >
> >> > > @piotr, I think your experience is very important, since you
> were the
> >> > only
> >> > > one that do the full process. My guess is that removing ANT
> from the
> >> > > release process will remove completely all the pain with such
> complex
> >> > > process and we all be able release from our own machines without
> >> having
> >> > > problems with complex task, uploading artifacts to a.o and
> more. We
> >> just
> >> > > need to ensure ANT still can be build exactly as before, and
> continue
> >> to
> >> > > produce the same.
> >> > >
> >> > > So in the end, we can stick with the old process, or try another
> >> > different
> >> > > approach to it build over standards. That means Chris and I
> will be
> >> using
> >> > > our times not yours. If we succeed, your test of the new
> approach will
> >> > need
> >> > > to ensure all the prerequisites and be lot more simpler. If we
> don't
> >> get
> >> > to
> >> > > that and fail in the process, just announce here and we can
> continue
> >> in
> >> > the
> >> > > old process.
> >> > >
> >> > > That's my proposal (that will need to be consensuated first
> here and
> >> then
> >> > > with Chris)
> >> > >
> >> > > Thanks
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
> >> (<aharui@adobe.com.invalid
> >> > >)
> >> > > escribió:
> >> > >
> >> > > >
> >> > > >
> >> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <
> bigosmallm@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > My 2 cents:
> >> > > >
> >> > > > I don't think we need to go back to the Ant vs Maven
> discussion.
> >> > If
> >> > > > the
> >> > > > Maven build/stage/release scripts works flawlessly, an
> Ant task
> >> can
> >> > > > simply
> >> > > > call it. There is no reason both cannot be worked on
> >> continuously.
> >> > > > In the
> >> > > > same way, if Maven users want, they can call Ant scripts
> as
> >> needed.
> >> > > >
> >> > > > Why do both camps want the other way to go away?
> >> > > >
> >> > > > I don't want one to go away. I want to use Maven for what it
> is
> >> good
> >> > for
> >> > > > and Ant for what it is good for.
> >> > > >
> >> > > > For example, we also publish to NPM as part of the
> release.
> >> There
> >> > is
> >> > > a
> >> > > > node.js script that gets called from the Ant script
> during the
> >> > > release
> >> > > > process. The node.js script is a black box as far as the
> Ant
> >> > script
> >> > > is
> >> > > > concerned.
> >> > > >
> >> > > > That said, Carlos if you think you can get a release done
> with
> >> just
> >> > > > Maven,
> >> > > > please go ahead and give it a shot. From what I
> remember, the
> >> > Maven
> >> > > > part
> >> > > > of the build/release was the issue and not the Ant
> portions. We
> >> > all
> >> > > > would
> >> > > > love to see improvements there.
> >> > > >
> >> > > > Alex, you say that Carlos did not work in the trenches
> during
> >> the
> >> > > > release
> >> > > > process, but are objecting (I think, if I understand your
> email
> >> > > > correctly)
> >> > > > to him wanting to work now. That seem contradictory,
> IMHO.
> >> > > >
> >> > > > I'm saying that if Carlos/Chris go back to the Maven Release
> Plugin
> >> > > > process, it will likely bring us back to the same problems we
> >> created
> >> > the
> >> > > > CI steps to work around. So why go through all of that again?
> >> > > >
> >> > > > Like Piotr just posted, Carlos should get in the trenches and
> get
> >> the
> >> > CI
> >> > > > steps to work with the new Maven poms. Not acknowledging
> that
> >> there
> >> > > have
> >> > > > been past problems using the process they propose is going to
> >> result in
> >> > > > more time wasted.
> >> > > >
> >> > > > -Alex
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=leozIkcJAUyXngghf2wTlbR0CsZq3cEELDsZrD8uEc4%3D&reserved=0
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Piotr Zarzycki
> >> >
> >> > Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0
> >> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0>*
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=leozIkcJAUyXngghf2wTlbR0CsZq3cEELDsZrD8uEc4%3D&reserved=0
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0
> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0>*
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0>*
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=leozIkcJAUyXngghf2wTlbR0CsZq3cEELDsZrD8uEc4%3D&reserved=0
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
El mié., 18 mar. 2020 a las 17:17, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> IMO we still need to run Ant at some point, so why not use Ant for
> scripting? That's what it is meant for.
>
Our perception is that trying to force 2 builds (three, four or more if we
add new build systems in the future) to the *release* (not talking about
*building* here) is what makes the whole process not reliable.
That's the point. Instead, if we just focus on just one, could be ANT,
Maven (**) or any other new one, and then ensure the other(s) still work
and are checked post release, makes remove all the old problems and make
the process much more reliable. I think that's a fact and something that we
can foresee for sure.
(**) we propose Maven for this (just release) and not (Ant), since is the
most used for releasing and CI due to numbers [1], and hence the most
prepared for the task and the one that should allow us to be updated in the
future without much hassle or breaking things.
[1] https://twitter.com/ChristoferDutz/status/1240219399551934473
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/18/20, 9:12 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
We could use the maven-invoker-plugin to execute a number of Ant builds.
This way we could ensure the Ant tasks work correctly.
Would that be an option?
Of course it is an option, but I do not like it. IMO, invoker is just a verbose Maven way of doing what Ant does. As I just posted, IMO we still need to run Ant at some point, so why not use Ant for scripting? That's what it is meant for.
Please, can we just try to fix the CI steps? Add the noPush and skipGPG params. Tell me where I can read what the steps are.
-Alex
Chris
Am 18.03.20, 16:54 schrieb "Carlos Rovira" <ca...@apache.org>:
Hi Chris,
thanks for joining the conversation :)
About "creating artifacts two times", I think we should just create one
with Maven *for the release process*, while ensuring ANT continues to work
as expected, since many people rely on it. So maybe the solution is:
0.- we need to fix the Maven distribution for IDE compilation (this is
independent of the release process, since is needed)
---
1.- make all the release process using the 2 steps you said
2.- check the ant build by adding a step that generates it and then check
agains the reproducible maven build distribution
(for this we need to find a way to check that distribution is generating
the same SDK as ANT, can that be done?)
For me that means removing lots of problems and ease the overall process
Make this sense?
El mié., 18 mar. 2020 a las 16:37, Christofer Dutz (<
christofer.dutz@c-ware.de>) escribió:
> Ok ... as it sort of feels silly to not respond to this list, but read it
> ... here goes ;-)
>
> Shouldn't the metric be: "does it bring the project forward?" and less
> "how much time did it cost to get here?"
> In PLC4X I recently deleted code that took me more than 3/4 of a year to
> write in more than full-time work. No commit felt better as it improved
> things greatly and what we replaced it with, was a giant leap for the
> project.
>
> So if you folks could explain what the refactoring I did some time ago
> broke ...
>
> And perhaps let me explain the reason for doing it in the first place:
> I really loved and still love the productivity I had with Apache Flex. I
> was consumed with counting and shifting bits, however knowing I need a
> frontend eventually. I was hoping that Royale was going to be that option.
> However I did notice with worries how long it took to get new releases out
> the door and hearing rumors about how many people invested so much time and
> some still failed. So I offered my assistance and had a look at the build.
> Being an expert in this particular area, I did notice some configuration
> "problems" or "misconfigurations", which I fixed. Usually if you need
> something special for some reason it's a good practice to write a comment
> to it in order for the person viewing the code to know the implications and
> reasoning behind this.
>
> You can't expect every newcomer to parse the last few years of discussions
> before contributing.
>
> Another reason was that I remembered that one of the "objections" to Maven
> was, that Maven couldn't do reproducible builds. So as the latest versions
> of the core maven plugins were updated to support this, I thought, perhaps
> this way we could get a stable release process.
>
> From a Maven point of view the updated Maven build is now rock-solid.
> Releasing it would require two timely separated sessions and 3 commands in
> total and would be done on the developer machine.
> 1) Create the release branch
> 2) Prepare and do the release
>
> The issues you folks were having ... I can't really confirm them ... Just
> to day I did a check of how many Apache project use which build tool. The
> result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that
> broken, I guess we would be hearing a lot more from the other projects. And
> I am not hearing any complaints at all.
>
> If the distributions are currently not 100% match of the Ant ones, I would
> like to help to make them one. Just tell me what the difference is and
> it'll be done in no-time. However it's hard to fix something you don't know
> what's broken.
>
> Also do I not quite understand why a jar used in Ant has to be built by
> Ant ... in general the jars should be identical. I know that maven saves
> some additional information in the pom (Actually storing the pom and the
> values properties had when it was built in the jar, which I think is a
> great thing for reproducibility). Perhaps disabling this could make them
> identical. And as soon as that's the case, I don't really see the point in
> building them twice. Do you agree?
>
> And no worries, I am not interested in joining the project again ... I
> want to help the project be able to get releases out because I would like
> to use them. After that's done I'm happy to disappear again, if you wish
> that I do.
>
> So far all the projects I have helped with their builds are firing out
> releases like machine-guns ... let me help you folks do so too.
>
> Chris
>
>
>
>
>
> Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <pi...@gmail.com>:
>
> Btw. I truly doubt that it would be bigger than time which was
> invested in
> building this whole release process.
>
> śr., 18 mar 2020 o 12:41 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
> > Carlos,
> >
> > Why it is so huge effort ? What was broken so much that you are
> talking
> > about huge effort ?
> >
> > śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >> as I responded before, I think that will be a huge task, in effort
> and
> >> time, and a task that can be easily broken again as any other one
> >> introduces new changes, what is something will happen for sure as we
> >> evolve. So what I'm offering is my time to be used in a way that
> can allow
> >> us to have a more reliable workflow. If I work on trying to fix as
> it's
> >> now, I probably will not succeed since I already tried for several
> hours
> >> and days (you can check emails around 19 or 20th Nov I think), and
> nothing
> >> of my tries could make a difference. Instead, I'm think taking a big
> >> different approach can make a difference. I can be wrong, but in
> that
> >> case,
> >> we'll know for sure that the way to go is the current one.
> >>
> >>
> >> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
> >> piotrzarzycki21@gmail.com>) escribió:
> >>
> >> > Carlos,
> >> >
> >> > In the other ways you are not going to fix current steps and
> release new
> >> > version of SDK ?
> >> >
> >> >
> >> >
> >> > śr., 18 mar 2020 o 10:39 Carlos Rovira <ca...@apache.org>
> >> > napisał(a):
> >> >
> >> > > Hi all and thanks for your responses:
> >> > >
> >> > > @greg, yes the plan I point is to do research to try a new way
> and see
> >> > > where we go. At the end, we don't get it, it will be our
> >> responsibility
> >> > and
> >> > > our time.
> >> > >
> >> > > @yishay, I think you state a concrete but very real issue. I
> think the
> >> > work
> >> > > done by Alex was amazing (no doubt here), but I'm afraid, as
> much as
> >> it
> >> > > pains me to say it, that it does not solve the problem you
> state and
> >> the
> >> > > proof is that only Piotr tried to use the process and it was
> not easy
> >> and
> >> > > then when fixing other things, it has broken with some ease.
> >> > >
> >> > > @om, as I said in the initial email. There's no war anymore
> between
> >> Maven
> >> > > and ANT. We all want both, and I'm using both when developing
> Royale
> >> to
> >> > > test. As well I continually know more about how things are done
> in
> >> Maven.
> >> > > My position is just that we need to separate concerns. One
> thing is to
> >> > have
> >> > > both systems for developers and user to use (Maven and ANT),
> but my
> >> point
> >> > > is that Releasing should just involve Maven, since is more
> suite for
> >> > > releasing at Apache and CIs, and ensure Ant continue working as
> >> expected.
> >> > > So no one wants one over the other, or remove one of them.
> That's not
> >> the
> >> > > problem anymore.
> >> > >
> >> > > @piotr, I think your experience is very important, since you
> were the
> >> > only
> >> > > one that do the full process. My guess is that removing ANT
> from the
> >> > > release process will remove completely all the pain with such
> complex
> >> > > process and we all be able release from our own machines without
> >> having
> >> > > problems with complex task, uploading artifacts to a.o and
> more. We
> >> just
> >> > > need to ensure ANT still can be build exactly as before, and
> continue
> >> to
> >> > > produce the same.
> >> > >
> >> > > So in the end, we can stick with the old process, or try another
> >> > different
> >> > > approach to it build over standards. That means Chris and I
> will be
> >> using
> >> > > our times not yours. If we succeed, your test of the new
> approach will
> >> > need
> >> > > to ensure all the prerequisites and be lot more simpler. If we
> don't
> >> get
> >> > to
> >> > > that and fail in the process, just announce here and we can
> continue
> >> in
> >> > the
> >> > > old process.
> >> > >
> >> > > That's my proposal (that will need to be consensuated first
> here and
> >> then
> >> > > with Chris)
> >> > >
> >> > > Thanks
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
> >> (<aharui@adobe.com.invalid
> >> > >)
> >> > > escribió:
> >> > >
> >> > > >
> >> > > >
> >> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <
> bigosmallm@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > My 2 cents:
> >> > > >
> >> > > > I don't think we need to go back to the Ant vs Maven
> discussion.
> >> > If
> >> > > > the
> >> > > > Maven build/stage/release scripts works flawlessly, an
> Ant task
> >> can
> >> > > > simply
> >> > > > call it. There is no reason both cannot be worked on
> >> continuously.
> >> > > > In the
> >> > > > same way, if Maven users want, they can call Ant scripts
> as
> >> needed.
> >> > > >
> >> > > > Why do both camps want the other way to go away?
> >> > > >
> >> > > > I don't want one to go away. I want to use Maven for what it
> is
> >> good
> >> > for
> >> > > > and Ant for what it is good for.
> >> > > >
> >> > > > For example, we also publish to NPM as part of the
> release.
> >> There
> >> > is
> >> > > a
> >> > > > node.js script that gets called from the Ant script
> during the
> >> > > release
> >> > > > process. The node.js script is a black box as far as the
> Ant
> >> > script
> >> > > is
> >> > > > concerned.
> >> > > >
> >> > > > That said, Carlos if you think you can get a release done
> with
> >> just
> >> > > > Maven,
> >> > > > please go ahead and give it a shot. From what I
> remember, the
> >> > Maven
> >> > > > part
> >> > > > of the build/release was the issue and not the Ant
> portions. We
> >> > all
> >> > > > would
> >> > > > love to see improvements there.
> >> > > >
> >> > > > Alex, you say that Carlos did not work in the trenches
> during
> >> the
> >> > > > release
> >> > > > process, but are objecting (I think, if I understand your
> email
> >> > > > correctly)
> >> > > > to him wanting to work now. That seem contradictory,
> IMHO.
> >> > > >
> >> > > > I'm saying that if Carlos/Chris go back to the Maven Release
> Plugin
> >> > > > process, it will likely bring us back to the same problems we
> >> created
> >> > the
> >> > > > CI steps to work around. So why go through all of that again?
> >> > > >
> >> > > > Like Piotr just posted, Carlos should get in the trenches and
> get
> >> the
> >> > CI
> >> > > > steps to work with the new Maven poms. Not acknowledging
> that
> >> there
> >> > > have
> >> > > > been past problems using the process they propose is going to
> >> result in
> >> > > > more time wasted.
> >> > > >
> >> > > > -Alex
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=leozIkcJAUyXngghf2wTlbR0CsZq3cEELDsZrD8uEc4%3D&reserved=0
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Piotr Zarzycki
> >> >
> >> > Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0
> >> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0>*
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=leozIkcJAUyXngghf2wTlbR0CsZq3cEELDsZrD8uEc4%3D&reserved=0
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0
> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0>*
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=NJFoIIrl5jF4fHfWO07P1IOkXaqWeNSKImuLDMMuf5s%3D&reserved=0>*
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfcab155a339f489dbf2b08d7cb572fba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201447644039384&sdata=leozIkcJAUyXngghf2wTlbR0CsZq3cEELDsZrD8uEc4%3D&reserved=0
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Christofer Dutz <ch...@c-ware.de>.
We could use the maven-invoker-plugin to execute a number of Ant builds.
This way we could ensure the Ant tasks work correctly.
Would that be an option?
Chris
Am 18.03.20, 16:54 schrieb "Carlos Rovira" <ca...@apache.org>:
Hi Chris,
thanks for joining the conversation :)
About "creating artifacts two times", I think we should just create one
with Maven *for the release process*, while ensuring ANT continues to work
as expected, since many people rely on it. So maybe the solution is:
0.- we need to fix the Maven distribution for IDE compilation (this is
independent of the release process, since is needed)
---
1.- make all the release process using the 2 steps you said
2.- check the ant build by adding a step that generates it and then check
agains the reproducible maven build distribution
(for this we need to find a way to check that distribution is generating
the same SDK as ANT, can that be done?)
For me that means removing lots of problems and ease the overall process
Make this sense?
El mié., 18 mar. 2020 a las 16:37, Christofer Dutz (<
christofer.dutz@c-ware.de>) escribió:
> Ok ... as it sort of feels silly to not respond to this list, but read it
> ... here goes ;-)
>
> Shouldn't the metric be: "does it bring the project forward?" and less
> "how much time did it cost to get here?"
> In PLC4X I recently deleted code that took me more than 3/4 of a year to
> write in more than full-time work. No commit felt better as it improved
> things greatly and what we replaced it with, was a giant leap for the
> project.
>
> So if you folks could explain what the refactoring I did some time ago
> broke ...
>
> And perhaps let me explain the reason for doing it in the first place:
> I really loved and still love the productivity I had with Apache Flex. I
> was consumed with counting and shifting bits, however knowing I need a
> frontend eventually. I was hoping that Royale was going to be that option.
> However I did notice with worries how long it took to get new releases out
> the door and hearing rumors about how many people invested so much time and
> some still failed. So I offered my assistance and had a look at the build.
> Being an expert in this particular area, I did notice some configuration
> "problems" or "misconfigurations", which I fixed. Usually if you need
> something special for some reason it's a good practice to write a comment
> to it in order for the person viewing the code to know the implications and
> reasoning behind this.
>
> You can't expect every newcomer to parse the last few years of discussions
> before contributing.
>
> Another reason was that I remembered that one of the "objections" to Maven
> was, that Maven couldn't do reproducible builds. So as the latest versions
> of the core maven plugins were updated to support this, I thought, perhaps
> this way we could get a stable release process.
>
> From a Maven point of view the updated Maven build is now rock-solid.
> Releasing it would require two timely separated sessions and 3 commands in
> total and would be done on the developer machine.
> 1) Create the release branch
> 2) Prepare and do the release
>
> The issues you folks were having ... I can't really confirm them ... Just
> to day I did a check of how many Apache project use which build tool. The
> result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that
> broken, I guess we would be hearing a lot more from the other projects. And
> I am not hearing any complaints at all.
>
> If the distributions are currently not 100% match of the Ant ones, I would
> like to help to make them one. Just tell me what the difference is and
> it'll be done in no-time. However it's hard to fix something you don't know
> what's broken.
>
> Also do I not quite understand why a jar used in Ant has to be built by
> Ant ... in general the jars should be identical. I know that maven saves
> some additional information in the pom (Actually storing the pom and the
> values properties had when it was built in the jar, which I think is a
> great thing for reproducibility). Perhaps disabling this could make them
> identical. And as soon as that's the case, I don't really see the point in
> building them twice. Do you agree?
>
> And no worries, I am not interested in joining the project again ... I
> want to help the project be able to get releases out because I would like
> to use them. After that's done I'm happy to disappear again, if you wish
> that I do.
>
> So far all the projects I have helped with their builds are firing out
> releases like machine-guns ... let me help you folks do so too.
>
> Chris
>
>
>
>
>
> Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <pi...@gmail.com>:
>
> Btw. I truly doubt that it would be bigger than time which was
> invested in
> building this whole release process.
>
> śr., 18 mar 2020 o 12:41 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
> > Carlos,
> >
> > Why it is so huge effort ? What was broken so much that you are
> talking
> > about huge effort ?
> >
> > śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >> as I responded before, I think that will be a huge task, in effort
> and
> >> time, and a task that can be easily broken again as any other one
> >> introduces new changes, what is something will happen for sure as we
> >> evolve. So what I'm offering is my time to be used in a way that
> can allow
> >> us to have a more reliable workflow. If I work on trying to fix as
> it's
> >> now, I probably will not succeed since I already tried for several
> hours
> >> and days (you can check emails around 19 or 20th Nov I think), and
> nothing
> >> of my tries could make a difference. Instead, I'm think taking a big
> >> different approach can make a difference. I can be wrong, but in
> that
> >> case,
> >> we'll know for sure that the way to go is the current one.
> >>
> >>
> >> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
> >> piotrzarzycki21@gmail.com>) escribió:
> >>
> >> > Carlos,
> >> >
> >> > In the other ways you are not going to fix current steps and
> release new
> >> > version of SDK ?
> >> >
> >> >
> >> >
> >> > śr., 18 mar 2020 o 10:39 Carlos Rovira <ca...@apache.org>
> >> > napisał(a):
> >> >
> >> > > Hi all and thanks for your responses:
> >> > >
> >> > > @greg, yes the plan I point is to do research to try a new way
> and see
> >> > > where we go. At the end, we don't get it, it will be our
> >> responsibility
> >> > and
> >> > > our time.
> >> > >
> >> > > @yishay, I think you state a concrete but very real issue. I
> think the
> >> > work
> >> > > done by Alex was amazing (no doubt here), but I'm afraid, as
> much as
> >> it
> >> > > pains me to say it, that it does not solve the problem you
> state and
> >> the
> >> > > proof is that only Piotr tried to use the process and it was
> not easy
> >> and
> >> > > then when fixing other things, it has broken with some ease.
> >> > >
> >> > > @om, as I said in the initial email. There's no war anymore
> between
> >> Maven
> >> > > and ANT. We all want both, and I'm using both when developing
> Royale
> >> to
> >> > > test. As well I continually know more about how things are done
> in
> >> Maven.
> >> > > My position is just that we need to separate concerns. One
> thing is to
> >> > have
> >> > > both systems for developers and user to use (Maven and ANT),
> but my
> >> point
> >> > > is that Releasing should just involve Maven, since is more
> suite for
> >> > > releasing at Apache and CIs, and ensure Ant continue working as
> >> expected.
> >> > > So no one wants one over the other, or remove one of them.
> That's not
> >> the
> >> > > problem anymore.
> >> > >
> >> > > @piotr, I think your experience is very important, since you
> were the
> >> > only
> >> > > one that do the full process. My guess is that removing ANT
> from the
> >> > > release process will remove completely all the pain with such
> complex
> >> > > process and we all be able release from our own machines without
> >> having
> >> > > problems with complex task, uploading artifacts to a.o and
> more. We
> >> just
> >> > > need to ensure ANT still can be build exactly as before, and
> continue
> >> to
> >> > > produce the same.
> >> > >
> >> > > So in the end, we can stick with the old process, or try another
> >> > different
> >> > > approach to it build over standards. That means Chris and I
> will be
> >> using
> >> > > our times not yours. If we succeed, your test of the new
> approach will
> >> > need
> >> > > to ensure all the prerequisites and be lot more simpler. If we
> don't
> >> get
> >> > to
> >> > > that and fail in the process, just announce here and we can
> continue
> >> in
> >> > the
> >> > > old process.
> >> > >
> >> > > That's my proposal (that will need to be consensuated first
> here and
> >> then
> >> > > with Chris)
> >> > >
> >> > > Thanks
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
> >> (<aharui@adobe.com.invalid
> >> > >)
> >> > > escribió:
> >> > >
> >> > > >
> >> > > >
> >> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <
> bigosmallm@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > My 2 cents:
> >> > > >
> >> > > > I don't think we need to go back to the Ant vs Maven
> discussion.
> >> > If
> >> > > > the
> >> > > > Maven build/stage/release scripts works flawlessly, an
> Ant task
> >> can
> >> > > > simply
> >> > > > call it. There is no reason both cannot be worked on
> >> continuously.
> >> > > > In the
> >> > > > same way, if Maven users want, they can call Ant scripts
> as
> >> needed.
> >> > > >
> >> > > > Why do both camps want the other way to go away?
> >> > > >
> >> > > > I don't want one to go away. I want to use Maven for what it
> is
> >> good
> >> > for
> >> > > > and Ant for what it is good for.
> >> > > >
> >> > > > For example, we also publish to NPM as part of the
> release.
> >> There
> >> > is
> >> > > a
> >> > > > node.js script that gets called from the Ant script
> during the
> >> > > release
> >> > > > process. The node.js script is a black box as far as the
> Ant
> >> > script
> >> > > is
> >> > > > concerned.
> >> > > >
> >> > > > That said, Carlos if you think you can get a release done
> with
> >> just
> >> > > > Maven,
> >> > > > please go ahead and give it a shot. From what I
> remember, the
> >> > Maven
> >> > > > part
> >> > > > of the build/release was the issue and not the Ant
> portions. We
> >> > all
> >> > > > would
> >> > > > love to see improvements there.
> >> > > >
> >> > > > Alex, you say that Carlos did not work in the trenches
> during
> >> the
> >> > > > release
> >> > > > process, but are objecting (I think, if I understand your
> email
> >> > > > correctly)
> >> > > > to him wanting to work now. That seem contradictory,
> IMHO.
> >> > > >
> >> > > > I'm saying that if Carlos/Chris go back to the Maven Release
> Plugin
> >> > > > process, it will likely bring us back to the same problems we
> >> created
> >> > the
> >> > > > CI steps to work around. So why go through all of that again?
> >> > > >
> >> > > > Like Piotr just posted, Carlos should get in the trenches and
> get
> >> the
> >> > CI
> >> > > > steps to work with the new Maven poms. Not acknowledging
> that
> >> there
> >> > > have
> >> > > > been past problems using the process they propose is going to
> >> result in
> >> > > > more time wasted.
> >> > > >
> >> > > > -Alex
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > > http://about.me/carlosrovira
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Piotr Zarzycki
> >> >
> >> > Patreon: *https://www.patreon.com/piotrzarzycki
> >> > <https://www.patreon.com/piotrzarzycki>*
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Reporting back (Was: Re: About release 0.9.7 and how to fix and
streamline the process)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Chris,
thanks for joining the conversation :)
About "creating artifacts two times", I think we should just create one
with Maven *for the release process*, while ensuring ANT continues to work
as expected, since many people rely on it. So maybe the solution is:
0.- we need to fix the Maven distribution for IDE compilation (this is
independent of the release process, since is needed)
---
1.- make all the release process using the 2 steps you said
2.- check the ant build by adding a step that generates it and then check
agains the reproducible maven build distribution
(for this we need to find a way to check that distribution is generating
the same SDK as ANT, can that be done?)
For me that means removing lots of problems and ease the overall process
Make this sense?
El mié., 18 mar. 2020 a las 16:37, Christofer Dutz (<
christofer.dutz@c-ware.de>) escribió:
> Ok ... as it sort of feels silly to not respond to this list, but read it
> ... here goes ;-)
>
> Shouldn't the metric be: "does it bring the project forward?" and less
> "how much time did it cost to get here?"
> In PLC4X I recently deleted code that took me more than 3/4 of a year to
> write in more than full-time work. No commit felt better as it improved
> things greatly and what we replaced it with, was a giant leap for the
> project.
>
> So if you folks could explain what the refactoring I did some time ago
> broke ...
>
> And perhaps let me explain the reason for doing it in the first place:
> I really loved and still love the productivity I had with Apache Flex. I
> was consumed with counting and shifting bits, however knowing I need a
> frontend eventually. I was hoping that Royale was going to be that option.
> However I did notice with worries how long it took to get new releases out
> the door and hearing rumors about how many people invested so much time and
> some still failed. So I offered my assistance and had a look at the build.
> Being an expert in this particular area, I did notice some configuration
> "problems" or "misconfigurations", which I fixed. Usually if you need
> something special for some reason it's a good practice to write a comment
> to it in order for the person viewing the code to know the implications and
> reasoning behind this.
>
> You can't expect every newcomer to parse the last few years of discussions
> before contributing.
>
> Another reason was that I remembered that one of the "objections" to Maven
> was, that Maven couldn't do reproducible builds. So as the latest versions
> of the core maven plugins were updated to support this, I thought, perhaps
> this way we could get a stable release process.
>
> From a Maven point of view the updated Maven build is now rock-solid.
> Releasing it would require two timely separated sessions and 3 commands in
> total and would be done on the developer machine.
> 1) Create the release branch
> 2) Prepare and do the release
>
> The issues you folks were having ... I can't really confirm them ... Just
> to day I did a check of how many Apache project use which build tool. The
> result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that
> broken, I guess we would be hearing a lot more from the other projects. And
> I am not hearing any complaints at all.
>
> If the distributions are currently not 100% match of the Ant ones, I would
> like to help to make them one. Just tell me what the difference is and
> it'll be done in no-time. However it's hard to fix something you don't know
> what's broken.
>
> Also do I not quite understand why a jar used in Ant has to be built by
> Ant ... in general the jars should be identical. I know that maven saves
> some additional information in the pom (Actually storing the pom and the
> values properties had when it was built in the jar, which I think is a
> great thing for reproducibility). Perhaps disabling this could make them
> identical. And as soon as that's the case, I don't really see the point in
> building them twice. Do you agree?
>
> And no worries, I am not interested in joining the project again ... I
> want to help the project be able to get releases out because I would like
> to use them. After that's done I'm happy to disappear again, if you wish
> that I do.
>
> So far all the projects I have helped with their builds are firing out
> releases like machine-guns ... let me help you folks do so too.
>
> Chris
>
>
>
>
>
> Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <pi...@gmail.com>:
>
> Btw. I truly doubt that it would be bigger than time which was
> invested in
> building this whole release process.
>
> śr., 18 mar 2020 o 12:41 Piotr Zarzycki <pi...@gmail.com>
> napisał(a):
>
> > Carlos,
> >
> > Why it is so huge effort ? What was broken so much that you are
> talking
> > about huge effort ?
> >
> > śr., 18 mar 2020 o 12:37 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> >> Hi Piotr,
> >>
> >> as I responded before, I think that will be a huge task, in effort
> and
> >> time, and a task that can be easily broken again as any other one
> >> introduces new changes, what is something will happen for sure as we
> >> evolve. So what I'm offering is my time to be used in a way that
> can allow
> >> us to have a more reliable workflow. If I work on trying to fix as
> it's
> >> now, I probably will not succeed since I already tried for several
> hours
> >> and days (you can check emails around 19 or 20th Nov I think), and
> nothing
> >> of my tries could make a difference. Instead, I'm think taking a big
> >> different approach can make a difference. I can be wrong, but in
> that
> >> case,
> >> we'll know for sure that the way to go is the current one.
> >>
> >>
> >> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (<
> >> piotrzarzycki21@gmail.com>) escribió:
> >>
> >> > Carlos,
> >> >
> >> > In the other ways you are not going to fix current steps and
> release new
> >> > version of SDK ?
> >> >
> >> >
> >> >
> >> > śr., 18 mar 2020 o 10:39 Carlos Rovira <ca...@apache.org>
> >> > napisał(a):
> >> >
> >> > > Hi all and thanks for your responses:
> >> > >
> >> > > @greg, yes the plan I point is to do research to try a new way
> and see
> >> > > where we go. At the end, we don't get it, it will be our
> >> responsibility
> >> > and
> >> > > our time.
> >> > >
> >> > > @yishay, I think you state a concrete but very real issue. I
> think the
> >> > work
> >> > > done by Alex was amazing (no doubt here), but I'm afraid, as
> much as
> >> it
> >> > > pains me to say it, that it does not solve the problem you
> state and
> >> the
> >> > > proof is that only Piotr tried to use the process and it was
> not easy
> >> and
> >> > > then when fixing other things, it has broken with some ease.
> >> > >
> >> > > @om, as I said in the initial email. There's no war anymore
> between
> >> Maven
> >> > > and ANT. We all want both, and I'm using both when developing
> Royale
> >> to
> >> > > test. As well I continually know more about how things are done
> in
> >> Maven.
> >> > > My position is just that we need to separate concerns. One
> thing is to
> >> > have
> >> > > both systems for developers and user to use (Maven and ANT),
> but my
> >> point
> >> > > is that Releasing should just involve Maven, since is more
> suite for
> >> > > releasing at Apache and CIs, and ensure Ant continue working as
> >> expected.
> >> > > So no one wants one over the other, or remove one of them.
> That's not
> >> the
> >> > > problem anymore.
> >> > >
> >> > > @piotr, I think your experience is very important, since you
> were the
> >> > only
> >> > > one that do the full process. My guess is that removing ANT
> from the
> >> > > release process will remove completely all the pain with such
> complex
> >> > > process and we all be able release from our own machines without
> >> having
> >> > > problems with complex task, uploading artifacts to a.o and
> more. We
> >> just
> >> > > need to ensure ANT still can be build exactly as before, and
> continue
> >> to
> >> > > produce the same.
> >> > >
> >> > > So in the end, we can stick with the old process, or try another
> >> > different
> >> > > approach to it build over standards. That means Chris and I
> will be
> >> using
> >> > > our times not yours. If we succeed, your test of the new
> approach will
> >> > need
> >> > > to ensure all the prerequisites and be lot more simpler. If we
> don't
> >> get
> >> > to
> >> > > that and fail in the process, just announce here and we can
> continue
> >> in
> >> > the
> >> > > old process.
> >> > >
> >> > > That's my proposal (that will need to be consensuated first
> here and
> >> then
> >> > > with Chris)
> >> > >
> >> > > Thanks
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui
> >> (<aharui@adobe.com.invalid
> >> > >)
> >> > > escribió:
> >> > >
> >> > > >
> >> > > >
> >> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <
> bigosmallm@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > My 2 cents:
> >> > > >
> >> > > > I don't think we need to go back to the Ant vs Maven
> discussion.
> >> > If
> >> > > > the
> >> > > > Maven build/stage/release scripts works flawlessly, an
> Ant task
> >> can
> >> > > > simply
> >> > > > call it. There is no reason both cannot be worked on
> >> continuously.
> >> > > > In the
> >> > > > same way, if Maven users want, they can call Ant scripts
> as
> >> needed.
> >> > > >
> >> > > > Why do both camps want the other way to go away?
> >> > > >
> >> > > > I don't want one to go away. I want to use Maven for what it
> is
> >> good
> >> > for
> >> > > > and Ant for what it is good for.
> >> > > >
> >> > > > For example, we also publish to NPM as part of the
> release.
> >> There
> >> > is
> >> > > a
> >> > > > node.js script that gets called from the Ant script
> during the
> >> > > release
> >> > > > process. The node.js script is a black box as far as the
> Ant
> >> > script
> >> > > is
> >> > > > concerned.
> >> > > >
> >> > > > That said, Carlos if you think you can get a release done
> with
> >> just
> >> > > > Maven,
> >> > > > please go ahead and give it a shot. From what I
> remember, the
> >> > Maven
> >> > > > part
> >> > > > of the build/release was the issue and not the Ant
> portions. We
> >> > all
> >> > > > would
> >> > > > love to see improvements there.
> >> > > >
> >> > > > Alex, you say that Carlos did not work in the trenches
> during
> >> the
> >> > > > release
> >> > > > process, but are objecting (I think, if I understand your
> email
> >> > > > correctly)
> >> > > > to him wanting to work now. That seem contradictory,
> IMHO.
> >> > > >
> >> > > > I'm saying that if Carlos/Chris go back to the Maven Release
> Plugin
> >> > > > process, it will likely bring us back to the same problems we
> >> created
> >> > the
> >> > > > CI steps to work around. So why go through all of that again?
> >> > > >
> >> > > > Like Piotr just posted, Carlos should get in the trenches and
> get
> >> the
> >> > CI
> >> > > > steps to work with the new Maven poms. Not acknowledging
> that
> >> there
> >> > > have
> >> > > > been past problems using the process they propose is going to
> >> result in
> >> > > > more time wasted.
> >> > > >
> >> > > > -Alex
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > > http://about.me/carlosrovira
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Piotr Zarzycki
> >> >
> >> > Patreon: *https://www.patreon.com/piotrzarzycki
> >> > <https://www.patreon.com/piotrzarzycki>*
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira