You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2020/03/17 15:47:42 UTC
About release 0.9.7 and how to fix and streamline the process
Hi
this morning in the slack Apache Royale official channel Chris Dutz asked
about plans for release 0.9.7. If you see Greg and I help him to create an
Apache Royale interface for pulling data from a Consumer in an IoT Apache
PLC4X app. Something very cool :). He published a tweet with a video
showing it.
So regarding the release, I explain that I spent many days some months ago
trying to fix the CI release steps to release, but I was unable to do it. I
think making changes to the Maven o Ant make the 13 steps very fragile and
difficult to fix. And we need to evolve continually Maven and Ant, so that
means a huge task that will require an huge amount of time that almost
nobody here has. So I must say that although the work done on that front
was amazing and huge maybe we need to streamline it to an standard. I know
is difficult, but although we had many expectations put on the 13 step
release process, after try it seems that we finally are not getting what we
wanted, that is streamline the release process.
This is one of the critical points that hold us to release 1.0, since not
having an easy way to release means as we push 1.0 and people tries us,
we'll need to be faster on releasing, and we can't wait 6 month or a year,
since that we'll mean user will not want that kind of release cycle.
So here is my proposal to work on a release process that allow us to
release more often and more easily. Hope you all can consider it:
First: We all know we want build with ANT and MAVEN. And when I refer to
"all" I really mean "all". Although I'm a Maven advocate, I really
appreciate the point to have ANT on place so having 2 build systems that
completely works mean advantage. In fact although I use maven I build with
both system daily.
Second: Build does not mean Release. I think other times we discussed
Release as a way to impose Maven over Ant. Or maybe that was the perception
for others, but not my intention (and maybe not the intention of others).
But that's not the objective. Release [1] means to us just "publication
outside the development community, defined as individuals actively
participating in development or following the dev list."
That means that we don't need to release using Maven and Ant at the same
time, we can streamline greatly the process to just releasing with Maven so
we can ensure a simple process the same as any other Apache project.
It means that people trying the release need to check it with Maven, but
community users can continue using ANT or Maven to build or even just
download the SDK and use it on his IDE of choice and don't use ANT or Maven
at all.
Third: The fact is the rest of projects I know all use releases and CI
based on Maven, and that should point us that maybe we're trying to
force something that is not standard in our industry, so if we want to make
it more reliable and easy process, is normal to embrace how others are
doing, since that does not mean we're throwing away a build system, since
per previous point we don't want to remove ANT.
Finally, Chris and I offer our time to make the easiest release process we can
that let all of us release easily and often (maybe each 1-2 month?)
Thanks
[1] http://www.apache.org/legal/release-policy.html#release-definition
--
Carlos Rovira
http://about.me/carlosrovira
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Harbs <ha...@gmail.com>.
Let’s keep the Ant part of the release as it’s been. Please.
If you have ways to improve the Maven part of the release, that’s fine. I don’t think anyone has an issue with it, but we’ve discussed Ant releases and the consensus is that we should keep Ant releases for the Ant build. There’s no reason to rehash this for every release.
Thanks,
Harbs
> On Mar 17, 2020, at 9:49 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I don't think you should be upset, don't think that to be a positive way to
> discuss this task, since in that way you force a solution and maybe not all
> of us think the same way as you. So although it could cause some tiring to
> all of us (me included) I think we need to put all our effort to get to
> some point where we all be satisfied.
>
> This is probably the most problematic task we have in Royale, and since is
> difficult to solve and seems there are at least two groups of people
> thinking in different ways, we need to get what's the better way to solve
> it. No one way of thinking is better that other you have valid points (but
> in the same way I can find arguments against them), but don't think that is
> a productive route. I want to spend our times in get a real solution.
>
> The CI steps you did was a great effort and very appreciated. I was very
> happy when you made it, since from outside it all sound very promising.
> Then IIRC Piotr's release doesn't was as straight as expected. So I think
> that was a point we should all take into account. Then my experience
> updating maven and broken some steps was as well something from what we
> should learn and think about it. I tried to fix them without exit. I still
> want to improve Maven even more in the future. One of the problem I see is:
> If we fix CI steps, will broke again when new changes in maven will be
> done? probably...and will the fix as difficult as now? In my experience,
> probably too.
>
> Don't think as well that is good for this discussion impose a way to act.
> I'll be fixing CI steps if I could, but I repeat that I tried during some
> days without exit. Spend many hours over it. So is not something I'd not
> do, is just that the process is very fragile and is not what I expect it
> will bring to us. Each thing we change can break it and that's a huge
> problem ahead. Or is just me the only one that see a huge problem on this?.
>
> Instead, I can offer my work in fixing in other way that I think is more
> "industrial" or proven, but you don't like it, due to the points you
> express (that I repeat can be valid, but I see that all are totally
> surmountable If we work in a more industrial way to solve it. Don't think
> we are more special that other hundreds of projects out there, and all of
> that projects just use maven for release.
>
> Maven SDK could still not be 100%, that's right, but is one of the things
> we need to fix in the actual process I offer. For sure. And releasing that
> way, you still can build with ANT and check it was all right. We don't need
> to do at the same time that releasing. I think that's a valid point.
>
> I think that if you defend the CI steps in such fixed way, the rest of us
> thinking that's not the way to go can just not oppose, but you can't ask us
> to be responsible of trying to solve something that is very (very)
> difficult to solve, since maybe we just can't do it. You must take into
> account that new changes could come (to ant, to maven), and working that
> way should be your responsibility or the any others here that think in that
> way. I can help or support in the way I can, but maybe limited in some way.
> And of course, we should all know that new optimizations to build systems
> can't be stopped to defend a concrete way to release. IOW, release is a
> process to "publish for other", and we can't block progress in the project
> or in the way we build to support a concrete way of release.
>
> just my 2
>
> Carlos
>
>
>
>
>
> El mar., 17 mar. 2020 a las 19:50, Harbs (<harbs.lists@gmail.com <ma...@gmail.com>>) escribió:
>
>> +1
>>
>> Harbs
>>
>>> On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID>
>> wrote:
>>>
>>> I’m sorry, but these repeated attempts to try to use Maven too much just
>> make me very upset. This was a concern of mine when two people who have
>> never produced a release went off to refactor the process. There is theory
>> and reality. The reality is that Maven cannot and should not be used to
>> streamline our release process because:
>>>
>>> - We've learned over the years that RMs have trouble getting set up
>> correctly.
>>> - We've learned over the years that RMs have trouble uploading Maven
>> artifacts to repository.a.o.
>>> - We should know that the only way to validate the Ant Task in the
>> release artifacts is to use Ant to verify it.
>>>
>>> Those are the three main reasons there are multiple release steps on the
>> CI server. I am hopeful that the new Maven builds can cut down on one or
>> two steps, or maybe just make those steps more straightforward, but the
>> process simply cannot just run Maven's release steps on the RM's local
>> computer. It must run on the CI server, and that requires stopping from
>> time to time to verify and sign stuff.
>>>
>>> A fourth reason was that the Ant script had proven to be able to build
>> an IDE-compatible artifact. I am not 100% convinced that the Maven
>> distribution build can exactly replicate that artifact. But again, if an
>> Ant user wants to use Ant to create artifacts for some IDE to test local
>> changes, then we need to prove in each release that Ant can produce that
>> set of artifacts for the IDE. So now that Maven can supposedly do the
>> same, it actually adds more work to the verification process. The Maven
>> artifacts for an IDE will need to be compared against the Ant-produced
>> artifacts for an IDE.
>>>
>>> In short, we should use Maven to produce Maven artifacts, and Ant to
>> produce Ant artifacts so that the RM is verifying the artifacts long before
>> the voters have to. And make it all work on a CI server so that RM's don't
>> have to deal with system setup, and not have upload issues blow up the
>> process.
>>>
>>> I also am not a fan of using Maven to do scripting, especially if it
>> involves custom mojos/plugins. That's what scripting tools like Ant are
>> for. The goal should be to make the release system maintainable by
>> everyone, not just by experts in Maven. Similarly, the Ant steps do not
>> use custom plugins/tasks for the same reason.
>>>
>>> Use Maven to build the Maven artifacts. Use Ant to build the Ant
>> artifacts and sequence the steps. Use the CI server. Verify and sign
>> locally. These are the requirements. It was all working and we could have
>> released every month. I think it is your responsibility to make it work
>> again within those constraints.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org> <mailto:
>> carlosrovira@apache.org <ma...@apache.org>>> wrote:
>>>
>>> Hi
>>>
>>> this morning in the slack Apache Royale official channel Chris Dutz
>> asked
>>> about plans for release 0.9.7. If you see Greg and I help him to
>> create an
>>> Apache Royale interface for pulling data from a Consumer in an IoT
>> Apache
>>> PLC4X app. Something very cool :). He published a tweet with a video
>>> showing it.
>>>
>>> So regarding the release, I explain that I spent many days some
>> months ago
>>> trying to fix the CI release steps to release, but I was unable to do
>> it. I
>>> think making changes to the Maven o Ant make the 13 steps very
>> fragile and
>>> difficult to fix. And we need to evolve continually Maven and Ant, so
>> that
>>> means a huge task that will require an huge amount of time that almost
>>> nobody here has. So I must say that although the work done on that
>> front
>>> was amazing and huge maybe we need to streamline it to an standard. I
>> know
>>> is difficult, but although we had many expectations put on the 13 step
>>> release process, after try it seems that we finally are not getting
>> what we
>>> wanted, that is streamline the release process.
>>>
>>> This is one of the critical points that hold us to release 1.0, since
>> not
>>> having an easy way to release means as we push 1.0 and people tries
>> us,
>>> we'll need to be faster on releasing, and we can't wait 6 month or a
>> year,
>>> since that we'll mean user will not want that kind of release cycle.
>>>
>>> So here is my proposal to work on a release process that allow us to
>>> release more often and more easily. Hope you all can consider it:
>>>
>>> First: We all know we want build with ANT and MAVEN. And when I refer
>> to
>>> "all" I really mean "all". Although I'm a Maven advocate, I really
>>> appreciate the point to have ANT on place so having 2 build systems
>> that
>>> completely works mean advantage. In fact although I use maven I build
>> with
>>> both system daily.
>>>
>>> Second: Build does not mean Release. I think other times we discussed
>>> Release as a way to impose Maven over Ant. Or maybe that was the
>> perception
>>> for others, but not my intention (and maybe not the intention of
>> others).
>>> But that's not the objective. Release [1] means to us just
>> "publication
>>> outside the development community, defined as individuals actively
>>> participating in development or following the dev list."
>>>
>>> That means that we don't need to release using Maven and Ant at the
>> same
>>> time, we can streamline greatly the process to just releasing with
>> Maven so
>>> we can ensure a simple process the same as any other Apache project.
>>>
>>> It means that people trying the release need to check it with Maven,
>> but
>>> community users can continue using ANT or Maven to build or even just
>>> download the SDK and use it on his IDE of choice and don't use ANT or
>> Maven
>>> at all.
>>>
>>> Third: The fact is the rest of projects I know all use releases and CI
>>> based on Maven, and that should point us that maybe we're trying to
>>> force something that is not standard in our industry, so if we want
>> to make
>>> it more reliable and easy process, is normal to embrace how others are
>>> doing, since that does not mean we're throwing away a build system,
>> since
>>> per previous point we don't want to remove ANT.
>>>
>>> Finally, Chris and I offer our time to make the easiest release
>> process we can
>>> that let all of us release easily and often (maybe each 1-2 month?)
>>>
>>> Thanks
>>>
>>>
>>> [1]
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0>
>> <
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0>
>>>
>>> --
>>> Carlos Rovira
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0>
>> <
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0>
>>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira <http://about.me/carlosrovira>
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Greg Dove <gr...@gmail.com>.
I don't know about any of this in terms of technical details or even
experience.
But if we simply focus on the release process itself and make sure we ask
ourselves at least 3 levels of 'why?' for any of the problems or challenges
(or assumptions) in the process (completely ignoring 'ant vs. maven' unless
it comes up in the absolute root cause answer), then *anything* that
removes complexity but can still achieve *exactly* the same results with
the same level of validation/assurance (for both ant and maven) should be
welcome, IMO.
If you get to a point that is not much different than pressing a green
button that says 'release', then I think we won't have a problem getting
release managers to volunteer :).
In addition, I do understand our needs as a project are unique but I also
have to assume a close-to-optimal solution should not be - has anybody
investigated approaches used by others that might have at least somewhat
similar needs?
If the same sort of issues have been 'solved' elsewhere and match our needs
then maybe we could avoid a lot of time invested.
Anyway, I can't contribute to this discussion beyond that because I really
don't have experience or deep knowledge here.
On Wed, Mar 18, 2020 at 1:09 PM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Alex,
>
> as I see it we have mostly two ways to choose:
>
> 1) Left Chris and I try to fix Maven distribution SDK (compilation with IDE
> is the only thing broken). And try what we defend. Maybe we can be wrong. I
> don't mind to recognize it if we reach a wrong path (Maybe in this process
> we find some low level issues that we didn't know and fail in the attempt.
> It's clear that we don't know as you all the involved things in the
> process, and if that happens, will be easy to say, "Hey! the proposal was
> not ok since we found X and Y, so that can't be done").
> In the other hand, if we succed...We (all) can get from this effort a more
> easy way to release. We know we need to ensure Maven and Ant continue to
> work as a build and can be reproducible. I think that must be the main
> point for all of us and not any other thing. Just that. If we get success
> along the way we get some improvements and streamline the process, I think
> we all will benefit from that and Apache Royale as a project will benefit
> of all the improvements done with that effort. All of this of course taking
> into account that I can get Chris help to do this.
>
> Note for Harbs: If we can ensure ANT build is working right (I assume that
> is what you should care since is the build system you use), where is the
> point on imposing us the need to complicate a release with doing such
> intricate process?
>
> 2) We continue with the CI steps. But for this I'll want to continue
> improving the Maven build process and that should not be a problem for CI
> steps. For this I can try to help on fixing CI steps. If you remember I was
> asking here questions, and as well some messages from the CI was sent for
> steps 1,2 and 3 during some days when I tried to go over it, but with
> no success at all. I even create duplicates of CI steps on the CI to ensure
> I work over copies to avoid change things over main ones and lost old ones.
> Maybe Harbs, Yishay or others can try to fix it and see if they find it
> easy and reliable for the future. Their experience will be very valuable.
> My experience was not good, but maybe I'm wrong and other's experience is
> better. I think Piotr's was hard, since he spend almost 2 weeks in this
> try, but I think he finally was ok.
>
> Alex to respond to some other points in you email and conclude:
> * for "industrial" I mean a proven way that other software projects use to
> release. Almost all projects here at Apache seems to release in a
> standardized way and all uses Maven, so to me that's what I call an
> "industrialized build process" that ensures a results, stability and
> reliability as well as easy to update as changes in the project evolve over
> time
> * My perception of the problems other RMs had over time with building in
> its own machines, or upload artifacts to a.o and other issues was caused
> for our current not standardized (not industrial) build process that mix
> Maven and Ant. So by choosing 1) I expect those problems to be removed and
> release without effort from a normal machine.
>
> I'm as well only just "one vote" as you. We saw already what Harbs thinks.
> Maybe others should express as well, even if they are not PMC since I think
> this is important. As I said this is for me maybe the most important
> problem we have right now, and is clear its a problem since we didn't
> release since October, 2019. And right now, we can't because the CI steps
> are broken and maybe just you know how to fix it, and you already stated
> several times that you don't plan to do it. Chris and I can try, but in
> other different way that we think is more "standard" or "industrial". So
> others must pronounce to see as a community what we should do, taking into
> account that we need something that needs to be reliable over time and not
> break with each improvements we want to do to build scripts (Maven or Ant),
> and make easy for a RM to do the task without spending a several days on
> it.
>
> to conclude, if people finally want to go with CI process (2), I think I'll
> try to ask Chris for doing the maven improvements, we wanted as soon as we
> can, so then others can try to go over CI steps and see if they are more
> lucky than me on trying it, just to avoid fix, change maven, and need again
> to fix.
>
> Thanks
>
>
>
>
>
>
> El mar., 17 mar. 2020 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > HI Carlos,
> >
> > I only have one vote. But we've spent a lot of time on this issue
> already
> > and the answer has always been the same: use Maven for Maven artifacts,
> use
> > Ant for Ant artifacts. I would much rather you spend your energy on
> fixing
> > what was a working release process. Of course it didn't work perfectly
> for
> > Piotr at first because it is a complex process, but eventually it did
> > work. If we did change to some new process that you want should we have
> > the same strict criteria that if it doesn't work the first time it must
> > therefore be no good? I'm sure you would not agree to that.
> >
> > I don't know what you mean by "industrial", but I'm quite certain these
> > days that we can't use the "expected" solution. This is a key point.
> You
> > and Chris have not been through the release process so you don't know the
> > kinds of issues that have to be resolved. I explained these issues in my
> > earlier response. I used a much more "expected" solution for the first
> > Royale releases and we found out that nobody else except me could use
> > them. So we were forced to try this CI multi-step process and finally,
> we
> > had someone be a successful RM other than me. So, any solution that
> might
> > work for you and Chris that uses Maven in the "expected" way on your
> > computer is likely to fail to work for other people. That's just our
> > reality.
> >
> > I do not recall seeing any questions about the CI steps since the new
> > Maven build seemed to stabilize, so I don't understand why you chose to
> > spend so much time on fixing them without asking a question on our lists.
> > I will try to answer questions if you have them. The steps are pretty
> > simple: Whatever steps you would normally run on the command-line to
> > create a release are captured in these steps. At some point, the steps
> > generate something that needs to be committed (like a branch, or updated
> > poms) or signed, and so that Jenkins job ends so the RM can log into the
> CI
> > server and commit the changes, then another step continues on until the
> > next commit or signing is needed.
> >
> > I will try to find time to understand how the Maven build now works, but
> I
> > am going to try really hard not to be the person who goes and fixes these
> > release steps. Not only did I not break them, but it would be better for
> > others to understand more about how they work. There is certainly room
> for
> > improvement in the steps, but fundamentally, we have to have a process
> > where some shared computer with a known good configuration does some
> work,
> > the RM then does a commit or sign, and so on.
> >
> > There are no restrictions I can think of on what Maven can be tasked to
> do
> > within a step, the only restriction occurs when something needs to be
> > committed or signed. And we need reproducible binaries in order to
> > validate the artifacts. Once you have local computer validation it makes
> > sense to me to use Maven's Wagon to upload to repository.a.o instead of
> the
> > Maven release plugin, but there might be a better way.
> >
> > In the end, though, Maven will build the Maven artifacts and Ant will
> > build the Ant artifacts. That way we validate as we build the artifacts.
> >
> > My 2 cents,
> > -Alex
> >
> >
> >
> >
> >
> > On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Alex,
> >
> > I don't think you should be upset, don't think that to be a positive
> > way to
> > discuss this task, since in that way you force a solution and maybe
> > not all
> > of us think the same way as you. So although it could cause some
> > tiring to
> > all of us (me included) I think we need to put all our effort to get
> to
> > some point where we all be satisfied.
> >
> > This is probably the most problematic task we have in Royale, and
> > since is
> > difficult to solve and seems there are at least two groups of people
> > thinking in different ways, we need to get what's the better way to
> > solve
> > it. No one way of thinking is better that other you have valid points
> > (but
> > in the same way I can find arguments against them), but don't think
> > that is
> > a productive route. I want to spend our times in get a real solution.
> >
> > The CI steps you did was a great effort and very appreciated. I was
> > very
> > happy when you made it, since from outside it all sound very
> promising.
> > Then IIRC Piotr's release doesn't was as straight as expected. So I
> > think
> > that was a point we should all take into account. Then my experience
> > updating maven and broken some steps was as well something from what
> we
> > should learn and think about it. I tried to fix them without exit. I
> > still
> > want to improve Maven even more in the future. One of the problem I
> > see is:
> > If we fix CI steps, will broke again when new changes in maven will
> be
> > done? probably...and will the fix as difficult as now? In my
> > experience,
> > probably too.
> >
> > Don't think as well that is good for this discussion impose a way to
> > act.
> > I'll be fixing CI steps if I could, but I repeat that I tried during
> > some
> > days without exit. Spend many hours over it. So is not something I'd
> > not
> > do, is just that the process is very fragile and is not what I expect
> > it
> > will bring to us. Each thing we change can break it and that's a huge
> > problem ahead. Or is just me the only one that see a huge problem on
> > this?.
> >
> > Instead, I can offer my work in fixing in other way that I think is
> > more
> > "industrial" or proven, but you don't like it, due to the points you
> > express (that I repeat can be valid, but I see that all are totally
> > surmountable If we work in a more industrial way to solve it. Don't
> > think
> > we are more special that other hundreds of projects out there, and
> all
> > of
> > that projects just use maven for release.
> >
> > Maven SDK could still not be 100%, that's right, but is one of the
> > things
> > we need to fix in the actual process I offer. For sure. And releasing
> > that
> > way, you still can build with ANT and check it was all right. We
> don't
> > need
> > to do at the same time that releasing. I think that's a valid point.
> >
> > I think that if you defend the CI steps in such fixed way, the rest
> of
> > us
> > thinking that's not the way to go can just not oppose, but you can't
> > ask us
> > to be responsible of trying to solve something that is very (very)
> > difficult to solve, since maybe we just can't do it. You must take
> into
> > account that new changes could come (to ant, to maven), and working
> > that
> > way should be your responsibility or the any others here that think
> in
> > that
> > way. I can help or support in the way I can, but maybe limited in
> some
> > way.
> > And of course, we should all know that new optimizations to build
> > systems
> > can't be stopped to defend a concrete way to release. IOW, release
> is a
> > process to "publish for other", and we can't block progress in the
> > project
> > or in the way we build to support a concrete way of release.
> >
> > just my 2
> >
> > Carlos
> >
> >
> >
> >
> >
> > El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>)
> > escribió:
> >
> > > +1
> > >
> > > Harbs
> > >
> > > > On Mar 17, 2020, at 8:10 PM, Alex Harui <aharui@adobe.com.INVALID
> >
> > > wrote:
> > > >
> > > > I’m sorry, but these repeated attempts to try to use Maven too
> > much just
> > > make me very upset. This was a concern of mine when two people who
> > have
> > > never produced a release went off to refactor the process. There
> is
> > theory
> > > and reality. The reality is that Maven cannot and should not be
> > used to
> > > streamline our release process because:
> > > >
> > > > - We've learned over the years that RMs have trouble getting set
> up
> > > correctly.
> > > > - We've learned over the years that RMs have trouble uploading
> > Maven
> > > artifacts to repository.a.o.
> > > > - We should know that the only way to validate the Ant Task in
> the
> > > release artifacts is to use Ant to verify it.
> > > >
> > > > Those are the three main reasons there are multiple release steps
> > on the
> > > CI server. I am hopeful that the new Maven builds can cut down on
> > one or
> > > two steps, or maybe just make those steps more straightforward, but
> > the
> > > process simply cannot just run Maven's release steps on the RM's
> > local
> > > computer. It must run on the CI server, and that requires stopping
> > from
> > > time to time to verify and sign stuff.
> > > >
> > > > A fourth reason was that the Ant script had proven to be able to
> > build
> > > an IDE-compatible artifact. I am not 100% convinced that the Maven
> > > distribution build can exactly replicate that artifact. But again,
> > if an
> > > Ant user wants to use Ant to create artifacts for some IDE to test
> > local
> > > changes, then we need to prove in each release that Ant can produce
> > that
> > > set of artifacts for the IDE. So now that Maven can supposedly do
> > the
> > > same, it actually adds more work to the verification process. The
> > Maven
> > > artifacts for an IDE will need to be compared against the
> > Ant-produced
> > > artifacts for an IDE.
> > > >
> > > > In short, we should use Maven to produce Maven artifacts, and Ant
> > to
> > > produce Ant artifacts so that the RM is verifying the artifacts
> long
> > before
> > > the voters have to. And make it all work on a CI server so that
> > RM's don't
> > > have to deal with system setup, and not have upload issues blow up
> > the
> > > process.
> > > >
> > > > I also am not a fan of using Maven to do scripting, especially if
> > it
> > > involves custom mojos/plugins. That's what scripting tools like
> Ant
> > are
> > > for. The goal should be to make the release system maintainable by
> > > everyone, not just by experts in Maven. Similarly, the Ant steps
> do
> > not
> > > use custom plugins/tasks for the same reason.
> > > >
> > > > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> > > artifacts and sequence the steps. Use the CI server. Verify and
> > sign
> > > locally. These are the requirements. It was all working and we
> > could have
> > > released every month. I think it is your responsibility to make it
> > work
> > > again within those constraints.
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org
> > <mailto:
> > > carlosrovira@apache.org>> wrote:
> > > >
> > > > Hi
> > > >
> > > > this morning in the slack Apache Royale official channel Chris
> > Dutz
> > > asked
> > > > about plans for release 0.9.7. If you see Greg and I help him
> to
> > > create an
> > > > Apache Royale interface for pulling data from a Consumer in an
> > IoT
> > > Apache
> > > > PLC4X app. Something very cool :). He published a tweet with a
> > video
> > > > showing it.
> > > >
> > > > So regarding the release, I explain that I spent many days
> some
> > > months ago
> > > > trying to fix the CI release steps to release, but I was
> unable
> > to do
> > > it. I
> > > > think making changes to the Maven o Ant make the 13 steps very
> > > fragile and
> > > > difficult to fix. And we need to evolve continually Maven and
> > Ant, so
> > > that
> > > > means a huge task that will require an huge amount of time
> that
> > almost
> > > > nobody here has. So I must say that although the work done on
> > that
> > > front
> > > > was amazing and huge maybe we need to streamline it to an
> > standard. I
> > > know
> > > > is difficult, but although we had many expectations put on the
> > 13 step
> > > > release process, after try it seems that we finally are not
> > getting
> > > what we
> > > > wanted, that is streamline the release process.
> > > >
> > > > This is one of the critical points that hold us to release
> 1.0,
> > since
> > > not
> > > > having an easy way to release means as we push 1.0 and people
> > tries
> > > us,
> > > > we'll need to be faster on releasing, and we can't wait 6
> month
> > or a
> > > year,
> > > > since that we'll mean user will not want that kind of release
> > cycle.
> > > >
> > > > So here is my proposal to work on a release process that allow
> > us to
> > > > release more often and more easily. Hope you all can consider
> > it:
> > > >
> > > > First: We all know we want build with ANT and MAVEN. And when
> I
> > refer
> > > to
> > > > "all" I really mean "all". Although I'm a Maven advocate, I
> > really
> > > > appreciate the point to have ANT on place so having 2 build
> > systems
> > > that
> > > > completely works mean advantage. In fact although I use maven
> I
> > build
> > > with
> > > > both system daily.
> > > >
> > > > Second: Build does not mean Release. I think other times we
> > discussed
> > > > Release as a way to impose Maven over Ant. Or maybe that was
> the
> > > perception
> > > > for others, but not my intention (and maybe not the intention
> of
> > > others).
> > > > But that's not the objective. Release [1] means to us just
> > > "publication
> > > > outside the development community, defined as individuals
> > actively
> > > > participating in development or following the dev list."
> > > >
> > > > That means that we don't need to release using Maven and Ant
> at
> > the
> > > same
> > > > time, we can streamline greatly the process to just releasing
> > with
> > > Maven so
> > > > we can ensure a simple process the same as any other Apache
> > project.
> > > >
> > > > It means that people trying the release need to check it with
> > Maven,
> > > but
> > > > community users can continue using ANT or Maven to build or
> > even just
> > > > download the SDK and use it on his IDE of choice and don't use
> > ANT or
> > > Maven
> > > > at all.
> > > >
> > > > Third: The fact is the rest of projects I know all use
> releases
> > and CI
> > > > based on Maven, and that should point us that maybe we're
> > trying to
> > > > force something that is not standard in our industry, so if we
> > want
> > > to make
> > > > it more reliable and easy process, is normal to embrace how
> > others are
> > > > doing, since that does not mean we're throwing away a build
> > system,
> > > since
> > > > per previous point we don't want to remove ANT.
> > > >
> > > > Finally, Chris and I offer our time to make the easiest
> release
> > > process we can
> > > > that let all of us release easily and often (maybe each 1-2
> > month?)
> > > >
> > > > Thanks
> > > >
> > > >
> > > > [1]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=PP%2Bq0O86F%2FguQtSIDzpGOa3CIM4qTiKmf%2FlmUVS7%2B%2Bo%3D&reserved=0
> > > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi All,
When I get back to my RM experience I can say that all of my problems was
not because process was bad or ant stops me doing anything. Just the
opposite, when I do started to understand how many steps thanks to that
process I can avoid, which I would have to do on my PC - I have finally
started appreciate all work done to have that process.
At the time when I wanted to be RM I did get from my contractors payed time
to make release happen, but that time was very limited. This pushes me to
make more mistakes and wanted to be quick in stuff instead learn and goes
through the process. - I believe this was the only real reason why I have
failed first time and why I had problems for the second attempt.
I remember that Alex did maybe 2-3 fixes during all my experience cause I
found some unusual cases over the process - Nothing more and special
actually.
At the end when I understanded stuff I could prepare RC in about 2-3h - I
could be much faster, but server is building stuff, preparing branches,
making for you all magic things which you will have to do regardless you
are using Maven or Ant on YOUR machine! - However I didn't have to do that,
steps did that for me.
The only work outside machine was Build framework on my sight, scripts
compared artifacts for me. Next I had to push RC to SVN repository - I did
that manually, but script can do that for you as well. - This part can be
tricky, but having in mind that 80% of work before THAT was done during the
steps - I can live with couple of manual things.
Summary:
I'm a big fan of MAVEN. I do propagate that build system in Prominic, we
have currently couple of apps in Royale, one is pretty big and it's growing
every day - We are using MAVEN and I cannot imagine to go with any other
system. ANT is not clear, ant can be messy, cause this system allows you to
be messy.
I huge +1 to have Maven as Royale build system for users, A huge +1 to have
Maven as the way of release Royale BUT at the same time a huge +1 to FIX
all of our steps which currently exists and helps us release framework.
After more than 2 years we had for the first time smooth release process
and it was broken, because someone wanted to have Maven do all that stuff
what is being done by the steps. - Make it so, but take care of what we
currently have!
Carlos I do strongly agree with Alex, that you should first be RM using
steps and next based on that experience think whether you really wanted to
throw on all active committers needs of learn new way of release. As you
can see at the beginning of my email - that learning curve may costs Time
and Money.
I really suggest you to:
1. Fix current steps
2. Release 0.9.7 using them
3. Start work on your Mavenization plan if you still really wanted to do
that after what you learn and see during that process.
Thanks,
Piotr
śr., 18 mar 2020 o 07:10 Yishay Weiss <yi...@hotmail.com> napisał(a):
> If I recall correctly, one the goals of using the CI was to enable
> incremental release so more than one contributor could work on a single
> release. I really hope that can be achieved whatever path is chosen.
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Wednesday, March 18, 2020 2:09 AM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: About release 0.9.7 and how to fix and streamline the process
>
> Hi Alex,
>
> as I see it we have mostly two ways to choose:
>
> 1) Left Chris and I try to fix Maven distribution SDK (compilation with IDE
> is the only thing broken). And try what we defend. Maybe we can be wrong. I
> don't mind to recognize it if we reach a wrong path (Maybe in this process
> we find some low level issues that we didn't know and fail in the attempt.
> It's clear that we don't know as you all the involved things in the
> process, and if that happens, will be easy to say, "Hey! the proposal was
> not ok since we found X and Y, so that can't be done").
> In the other hand, if we succed...We (all) can get from this effort a more
> easy way to release. We know we need to ensure Maven and Ant continue to
> work as a build and can be reproducible. I think that must be the main
> point for all of us and not any other thing. Just that. If we get success
> along the way we get some improvements and streamline the process, I think
> we all will benefit from that and Apache Royale as a project will benefit
> of all the improvements done with that effort. All of this of course taking
> into account that I can get Chris help to do this.
>
> Note for Harbs: If we can ensure ANT build is working right (I assume that
> is what you should care since is the build system you use), where is the
> point on imposing us the need to complicate a release with doing such
> intricate process?
>
> 2) We continue with the CI steps. But for this I'll want to continue
> improving the Maven build process and that should not be a problem for CI
> steps. For this I can try to help on fixing CI steps. If you remember I was
> asking here questions, and as well some messages from the CI was sent for
> steps 1,2 and 3 during some days when I tried to go over it, but with
> no success at all. I even create duplicates of CI steps on the CI to ensure
> I work over copies to avoid change things over main ones and lost old ones.
> Maybe Harbs, Yishay or others can try to fix it and see if they find it
> easy and reliable for the future. Their experience will be very valuable.
> My experience was not good, but maybe I'm wrong and other's experience is
> better. I think Piotr's was hard, since he spend almost 2 weeks in this
> try, but I think he finally was ok.
>
> Alex to respond to some other points in you email and conclude:
> * for "industrial" I mean a proven way that other software projects use to
> release. Almost all projects here at Apache seems to release in a
> standardized way and all uses Maven, so to me that's what I call an
> "industrialized build process" that ensures a results, stability and
> reliability as well as easy to update as changes in the project evolve over
> time
> * My perception of the problems other RMs had over time with building in
> its own machines, or upload artifacts to a.o and other issues was caused
> for our current not standardized (not industrial) build process that mix
> Maven and Ant. So by choosing 1) I expect those problems to be removed and
> release without effort from a normal machine.
>
> I'm as well only just "one vote" as you. We saw already what Harbs thinks.
> Maybe others should express as well, even if they are not PMC since I think
> this is important. As I said this is for me maybe the most important
> problem we have right now, and is clear its a problem since we didn't
> release since October, 2019. And right now, we can't because the CI steps
> are broken and maybe just you know how to fix it, and you already stated
> several times that you don't plan to do it. Chris and I can try, but in
> other different way that we think is more "standard" or "industrial". So
> others must pronounce to see as a community what we should do, taking into
> account that we need something that needs to be reliable over time and not
> break with each improvements we want to do to build scripts (Maven or Ant),
> and make easy for a RM to do the task without spending a several days on
> it.
>
> to conclude, if people finally want to go with CI process (2), I think I'll
> try to ask Chris for doing the maven improvements, we wanted as soon as we
> can, so then others can try to go over CI steps and see if they are more
> lucky than me on trying it, just to avoid fix, change maven, and need again
> to fix.
>
> Thanks
>
>
>
>
>
>
> El mar., 17 mar. 2020 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > HI Carlos,
> >
> > I only have one vote. But we've spent a lot of time on this issue
> already
> > and the answer has always been the same: use Maven for Maven artifacts,
> use
> > Ant for Ant artifacts. I would much rather you spend your energy on
> fixing
> > what was a working release process. Of course it didn't work perfectly
> for
> > Piotr at first because it is a complex process, but eventually it did
> > work. If we did change to some new process that you want should we have
> > the same strict criteria that if it doesn't work the first time it must
> > therefore be no good? I'm sure you would not agree to that.
> >
> > I don't know what you mean by "industrial", but I'm quite certain these
> > days that we can't use the "expected" solution. This is a key point.
> You
> > and Chris have not been through the release process so you don't know the
> > kinds of issues that have to be resolved. I explained these issues in my
> > earlier response. I used a much more "expected" solution for the first
> > Royale releases and we found out that nobody else except me could use
> > them. So we were forced to try this CI multi-step process and finally,
> we
> > had someone be a successful RM other than me. So, any solution that
> might
> > work for you and Chris that uses Maven in the "expected" way on your
> > computer is likely to fail to work for other people. That's just our
> > reality.
> >
> > I do not recall seeing any questions about the CI steps since the new
> > Maven build seemed to stabilize, so I don't understand why you chose to
> > spend so much time on fixing them without asking a question on our lists.
> > I will try to answer questions if you have them. The steps are pretty
> > simple: Whatever steps you would normally run on the command-line to
> > create a release are captured in these steps. At some point, the steps
> > generate something that needs to be committed (like a branch, or updated
> > poms) or signed, and so that Jenkins job ends so the RM can log into the
> CI
> > server and commit the changes, then another step continues on until the
> > next commit or signing is needed.
> >
> > I will try to find time to understand how the Maven build now works, but
> I
> > am going to try really hard not to be the person who goes and fixes these
> > release steps. Not only did I not break them, but it would be better for
> > others to understand more about how they work. There is certainly room
> for
> > improvement in the steps, but fundamentally, we have to have a process
> > where some shared computer with a known good configuration does some
> work,
> > the RM then does a commit or sign, and so on.
> >
> > There are no restrictions I can think of on what Maven can be tasked to
> do
> > within a step, the only restriction occurs when something needs to be
> > committed or signed. And we need reproducible binaries in order to
> > validate the artifacts. Once you have local computer validation it makes
> > sense to me to use Maven's Wagon to upload to repository.a.o instead of
> the
> > Maven release plugin, but there might be a better way.
> >
> > In the end, though, Maven will build the Maven artifacts and Ant will
> > build the Ant artifacts. That way we validate as we build the artifacts.
> >
> > My 2 cents,
> > -Alex
> >
> >
> >
> >
> >
> > On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Alex,
> >
> > I don't think you should be upset, don't think that to be a positive
> > way to
> > discuss this task, since in that way you force a solution and maybe
> > not all
> > of us think the same way as you. So although it could cause some
> > tiring to
> > all of us (me included) I think we need to put all our effort to get
> to
> > some point where we all be satisfied.
> >
> > This is probably the most problematic task we have in Royale, and
> > since is
> > difficult to solve and seems there are at least two groups of people
> > thinking in different ways, we need to get what's the better way to
> > solve
> > it. No one way of thinking is better that other you have valid points
> > (but
> > in the same way I can find arguments against them), but don't think
> > that is
> > a productive route. I want to spend our times in get a real solution.
> >
> > The CI steps you did was a great effort and very appreciated. I was
> > very
> > happy when you made it, since from outside it all sound very
> promising.
> > Then IIRC Piotr's release doesn't was as straight as expected. So I
> > think
> > that was a point we should all take into account. Then my experience
> > updating maven and broken some steps was as well something from what
> we
> > should learn and think about it. I tried to fix them without exit. I
> > still
> > want to improve Maven even more in the future. One of the problem I
> > see is:
> > If we fix CI steps, will broke again when new changes in maven will
> be
> > done? probably...and will the fix as difficult as now? In my
> > experience,
> > probably too.
> >
> > Don't think as well that is good for this discussion impose a way to
> > act.
> > I'll be fixing CI steps if I could, but I repeat that I tried during
> > some
> > days without exit. Spend many hours over it. So is not something I'd
> > not
> > do, is just that the process is very fragile and is not what I expect
> > it
> > will bring to us. Each thing we change can break it and that's a huge
> > problem ahead. Or is just me the only one that see a huge problem on
> > this?.
> >
> > Instead, I can offer my work in fixing in other way that I think is
> > more
> > "industrial" or proven, but you don't like it, due to the points you
> > express (that I repeat can be valid, but I see that all are totally
> > surmountable If we work in a more industrial way to solve it. Don't
> > think
> > we are more special that other hundreds of projects out there, and
> all
> > of
> > that projects just use maven for release.
> >
> > Maven SDK could still not be 100%, that's right, but is one of the
> > things
> > we need to fix in the actual process I offer. For sure. And releasing
> > that
> > way, you still can build with ANT and check it was all right. We
> don't
> > need
> > to do at the same time that releasing. I think that's a valid point.
> >
> > I think that if you defend the CI steps in such fixed way, the rest
> of
> > us
> > thinking that's not the way to go can just not oppose, but you can't
> > ask us
> > to be responsible of trying to solve something that is very (very)
> > difficult to solve, since maybe we just can't do it. You must take
> into
> > account that new changes could come (to ant, to maven), and working
> > that
> > way should be your responsibility or the any others here that think
> in
> > that
> > way. I can help or support in the way I can, but maybe limited in
> some
> > way.
> > And of course, we should all know that new optimizations to build
> > systems
> > can't be stopped to defend a concrete way to release. IOW, release
> is a
> > process to "publish for other", and we can't block progress in the
> > project
> > or in the way we build to support a concrete way of release.
> >
> > just my 2
> >
> > Carlos
> >
> >
> >
> >
> >
> > El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>)
> > escribió:
> >
> > > +1
> > >
> > > Harbs
> > >
> > > > On Mar 17, 2020, at 8:10 PM, Alex Harui <aharui@adobe.com.INVALID
> >
> > > wrote:
> > > >
> > > > I’m sorry, but these repeated attempts to try to use Maven too
> > much just
> > > make me very upset. This was a concern of mine when two people who
> > have
> > > never produced a release went off to refactor the process. There
> is
> > theory
> > > and reality. The reality is that Maven cannot and should not be
> > used to
> > > streamline our release process because:
> > > >
> > > > - We've learned over the years that RMs have trouble getting set
> up
> > > correctly.
> > > > - We've learned over the years that RMs have trouble uploading
> > Maven
> > > artifacts to repository.a.o.
> > > > - We should know that the only way to validate the Ant Task in
> the
> > > release artifacts is to use Ant to verify it.
> > > >
> > > > Those are the three main reasons there are multiple release steps
> > on the
> > > CI server. I am hopeful that the new Maven builds can cut down on
> > one or
> > > two steps, or maybe just make those steps more straightforward, but
> > the
> > > process simply cannot just run Maven's release steps on the RM's
> > local
> > > computer. It must run on the CI server, and that requires stopping
> > from
> > > time to time to verify and sign stuff.
> > > >
> > > > A fourth reason was that the Ant script had proven to be able to
> > build
> > > an IDE-compatible artifact. I am not 100% convinced that the Maven
> > > distribution build can exactly replicate that artifact. But again,
> > if an
> > > Ant user wants to use Ant to create artifacts for some IDE to test
> > local
> > > changes, then we need to prove in each release that Ant can produce
> > that
> > > set of artifacts for the IDE. So now that Maven can supposedly do
> > the
> > > same, it actually adds more work to the verification process. The
> > Maven
> > > artifacts for an IDE will need to be compared against the
> > Ant-produced
> > > artifacts for an IDE.
> > > >
> > > > In short, we should use Maven to produce Maven artifacts, and Ant
> > to
> > > produce Ant artifacts so that the RM is verifying the artifacts
> long
> > before
> > > the voters have to. And make it all work on a CI server so that
> > RM's don't
> > > have to deal with system setup, and not have upload issues blow up
> > the
> > > process.
> > > >
> > > > I also am not a fan of using Maven to do scripting, especially if
> > it
> > > involves custom mojos/plugins. That's what scripting tools like
> Ant
> > are
> > > for. The goal should be to make the release system maintainable by
> > > everyone, not just by experts in Maven. Similarly, the Ant steps
> do
> > not
> > > use custom plugins/tasks for the same reason.
> > > >
> > > > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> > > artifacts and sequence the steps. Use the CI server. Verify and
> > sign
> > > locally. These are the requirements. It was all working and we
> > could have
> > > released every month. I think it is your responsibility to make it
> > work
> > > again within those constraints.
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org
> > <mailto:
> > > carlosrovira@apache.org>> wrote:
> > > >
> > > > Hi
> > > >
> > > > this morning in the slack Apache Royale official channel Chris
> > Dutz
> > > asked
> > > > about plans for release 0.9.7. If you see Greg and I help him
> to
> > > create an
> > > > Apache Royale interface for pulling data from a Consumer in an
> > IoT
> > > Apache
> > > > PLC4X app. Something very cool :). He published a tweet with a
> > video
> > > > showing it.
> > > >
> > > > So regarding the release, I explain that I spent many days
> some
> > > months ago
> > > > trying to fix the CI release steps to release, but I was
> unable
> > to do
> > > it. I
> > > > think making changes to the Maven o Ant make the 13 steps very
> > > fragile and
> > > > difficult to fix. And we need to evolve continually Maven and
> > Ant, so
> > > that
> > > > means a huge task that will require an huge amount of time
> that
> > almost
> > > > nobody here has. So I must say that although the work done on
> > that
> > > front
> > > > was amazing and huge maybe we need to streamline it to an
> > standard. I
> > > know
> > > > is difficult, but although we had many expectations put on the
> > 13 step
> > > > release process, after try it seems that we finally are not
> > getting
> > > what we
> > > > wanted, that is streamline the release process.
> > > >
> > > > This is one of the critical points that hold us to release
> 1.0,
> > since
> > > not
> > > > having an easy way to release means as we push 1.0 and people
> > tries
> > > us,
> > > > we'll need to be faster on releasing, and we can't wait 6
> month
> > or a
> > > year,
> > > > since that we'll mean user will not want that kind of release
> > cycle.
> > > >
> > > > So here is my proposal to work on a release process that allow
> > us to
> > > > release more often and more easily. Hope you all can consider
> > it:
> > > >
> > > > First: We all know we want build with ANT and MAVEN. And when
> I
> > refer
> > > to
> > > > "all" I really mean "all". Although I'm a Maven advocate, I
> > really
> > > > appreciate the point to have ANT on place so having 2 build
> > systems
> > > that
> > > > completely works mean advantage. In fact although I use maven
> I
> > build
> > > with
> > > > both system daily.
> > > >
> > > > Second: Build does not mean Release. I think other times we
> > discussed
> > > > Release as a way to impose Maven over Ant. Or maybe that was
> the
> > > perception
> > > > for others, but not my intention (and maybe not the intention
> of
> > > others).
> > > > But that's not the objective. Release [1] means to us just
> > > "publication
> > > > outside the development community, defined as individuals
> > actively
> > > > participating in development or following the dev list."
> > > >
> > > > That means that we don't need to release using Maven and Ant
> at
> > the
> > > same
> > > > time, we can streamline greatly the process to just releasing
> > with
> > > Maven so
> > > > we can ensure a simple process the same as any other Apache
> > project.
> > > >
> > > > It means that people trying the release need to check it with
> > Maven,
> > > but
> > > > community users can continue using ANT or Maven to build or
> > even just
> > > > download the SDK and use it on his IDE of choice and don't use
> > ANT or
> > > Maven
> > > > at all.
> > > >
> > > > Third: The fact is the rest of projects I know all use
> releases
> > and CI
> > > > based on Maven, and that should point us that maybe we're
> > trying to
> > > > force something that is not standard in our industry, so if we
> > want
> > > to make
> > > > it more reliable and easy process, is normal to embrace how
> > others are
> > > > doing, since that does not mean we're throwing away a build
> > system,
> > > since
> > > > per previous point we don't want to remove ANT.
> > > >
> > > > Finally, Chris and I offer our time to make the easiest
> release
> > > process we can
> > > > that let all of us release easily and often (maybe each 1-2
> > month?)
> > > >
> > > > Thanks
> > > >
> > > >
> > > > [1]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=PP%2Bq0O86F%2FguQtSIDzpGOa3CIM4qTiKmf%2FlmUVS7%2B%2Bo%3D&reserved=0
> > > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
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:04, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> You are also essentially saying that because you removed code and the
> algorithm is now broken, it is time to go back to the prior algorithm which
> did not work.
No. I'm saying that we tried to work from a setup and workflow that has
many issues to deal with, I'm NOT proposing to back to the previous way and
continue (in that case I prefer to continue with CI steps).
What I'm proposing is to create a whole release process from scratch that
ensures all the points we want to pursue with all the advantages I pointed
in previous emails.
(not annotating before this since the arguments are based on the previous
premise, that is not what I'm proposing)
Thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Carlos,
IMO, your arguments are flawed. You are saying because there was a bug or two before we got the CI process working, we have to throw out that process and start over.
You are also essentially saying that because you removed code and the algorithm is now broken, it is time to go back to the prior algorithm which did not work. Look at the commits. The Maven changes removed the flags I added to allow the CI steps to work. If you had looked at the ramifications of removing the Maven options, and why the options were added in the first place, or even asked why on the list, you would hopefully have preserved the options and then the CI steps would have worked. But I see no evidence that was done. Instead, it looks like options were just removed. Sometimes that happens unintentionally in a refactor, but then you go back and look at commit history to try to understand why, or ask questions on the list.
We used to use standards. I have now written this 3 times at least. The standards worked for me, but did not work for others. Having a set of steps on CI gives us a single known good configuration to work on that we can all access, instead of wondering why the RM's computer isn't doing the right thing.
Fixing the CI should be as simple as re-introducing the noPush and skipGPG options, assuming nothing else was touched regarding creating the reproducible binaries. It is entirely possible that in the time spent on this thread so far, you could have made significant progress on the CI steps.
-Alex
On 3/18/20, 8:32 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Piotr,
if you check CI server, I duplicated 1,2 and 3 steps (to avoid removing
anything from the original steps from Alex), and worked over there.
I was trying lots of things, and in the process I did get to pass those
ones. Even I can't ensure but seems to me that not always the process was
doing the same since some times I had hanging problems that exasperated me.
Its clear that the work done for Alex was intense and amazing, and never
compared by the few time I take to try to fix it. But it's not that the
problem. I just thing we need take the whole problem with another
perspective to take the opportunity of remove most of the current problems
or we'll be doing the same ones one time and again. This is not about
talking about the serious work done. I applauded that effort many times
here. It's that as Yishay, I don't see the final results get what we all
wanted. But as we said, is just my opinion and my vote and is clear that I
can't start such huge effort and ask Chris to invest in it if I don't get a
back on you all to do it.
El mié., 18 mar. 2020 a las 12:42, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> 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%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=d6lrb8AjhzVvIOjaL7bStowSJMG4IsIWpv6EaQPWG04%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%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=SGsBKW4Qg%2Bu5lb7TppHyBg0VaENwQaFdCb11KvHbjkw%3D&reserved=0
> >> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=SGsBKW4Qg%2Bu5lb7TppHyBg0VaENwQaFdCb11KvHbjkw%3D&reserved=0>*
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=d6lrb8AjhzVvIOjaL7bStowSJMG4IsIWpv6EaQPWG04%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%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=SGsBKW4Qg%2Bu5lb7TppHyBg0VaENwQaFdCb11KvHbjkw%3D&reserved=0
> > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=SGsBKW4Qg%2Bu5lb7TppHyBg0VaENwQaFdCb11KvHbjkw%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%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589581093&sdata=SGsBKW4Qg%2Bu5lb7TppHyBg0VaENwQaFdCb11KvHbjkw%3D&reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589591083&sdata=zx8%2Bw0r75sYsdeAY2MTYNpirklE0SS5f8AiegQSMNlQ%3D&reserved=0>*
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C62313a2951e04905eebb08d7cb5196aa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637201423589591083&sdata=FuwtzrOf1EGE9hhvyTpfLLrJ7KTlInxENapPLG5jlnQ%3D&reserved=0
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
if you check CI server, I duplicated 1,2 and 3 steps (to avoid removing
anything from the original steps from Alex), and worked over there.
I was trying lots of things, and in the process I did get to pass those
ones. Even I can't ensure but seems to me that not always the process was
doing the same since some times I had hanging problems that exasperated me.
Its clear that the work done for Alex was intense and amazing, and never
compared by the few time I take to try to fix it. But it's not that the
problem. I just thing we need take the whole problem with another
perspective to take the opportunity of remove most of the current problems
or we'll be doing the same ones one time and again. This is not about
talking about the serious work done. I applauded that effort many times
here. It's that as Yishay, I don't see the final results get what we all
wanted. But as we said, is just my opinion and my vote and is clear that I
can't start such huge effort and ask Chris to invest in it if I don't get a
back on you all to do it.
El mié., 18 mar. 2020 a las 12:42, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> 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: About release 0.9.7 and how to fix and streamline the process
Posted by 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: About release 0.9.7 and how to fix and streamline the process
Posted by Piotr Zarzycki <pi...@gmail.com>.
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>*
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Carlos Rovira <ca...@apache.org>.
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
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 (<ah...@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>*
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@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
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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
Re: About release 0.9.7 and how to fix and streamline the process
Posted by OmPrakash Muppirala <bi...@gmail.com>.
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?
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.
Thanks,
Om
On Tue, Mar 17, 2020 at 11:10 PM Yishay Weiss <yi...@hotmail.com>
wrote:
> If I recall correctly, one the goals of using the CI was to enable
> incremental release so more than one contributor could work on a single
> release. I really hope that can be achieved whatever path is chosen.
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Wednesday, March 18, 2020 2:09 AM
> To: Apache Royale Development<ma...@royale.apache.org>
> Subject: Re: About release 0.9.7 and how to fix and streamline the process
>
> Hi Alex,
>
> as I see it we have mostly two ways to choose:
>
> 1) Left Chris and I try to fix Maven distribution SDK (compilation with IDE
> is the only thing broken). And try what we defend. Maybe we can be wrong. I
> don't mind to recognize it if we reach a wrong path (Maybe in this process
> we find some low level issues that we didn't know and fail in the attempt.
> It's clear that we don't know as you all the involved things in the
> process, and if that happens, will be easy to say, "Hey! the proposal was
> not ok since we found X and Y, so that can't be done").
> In the other hand, if we succed...We (all) can get from this effort a more
> easy way to release. We know we need to ensure Maven and Ant continue to
> work as a build and can be reproducible. I think that must be the main
> point for all of us and not any other thing. Just that. If we get success
> along the way we get some improvements and streamline the process, I think
> we all will benefit from that and Apache Royale as a project will benefit
> of all the improvements done with that effort. All of this of course taking
> into account that I can get Chris help to do this.
>
> Note for Harbs: If we can ensure ANT build is working right (I assume that
> is what you should care since is the build system you use), where is the
> point on imposing us the need to complicate a release with doing such
> intricate process?
>
> 2) We continue with the CI steps. But for this I'll want to continue
> improving the Maven build process and that should not be a problem for CI
> steps. For this I can try to help on fixing CI steps. If you remember I was
> asking here questions, and as well some messages from the CI was sent for
> steps 1,2 and 3 during some days when I tried to go over it, but with
> no success at all. I even create duplicates of CI steps on the CI to ensure
> I work over copies to avoid change things over main ones and lost old ones.
> Maybe Harbs, Yishay or others can try to fix it and see if they find it
> easy and reliable for the future. Their experience will be very valuable.
> My experience was not good, but maybe I'm wrong and other's experience is
> better. I think Piotr's was hard, since he spend almost 2 weeks in this
> try, but I think he finally was ok.
>
> Alex to respond to some other points in you email and conclude:
> * for "industrial" I mean a proven way that other software projects use to
> release. Almost all projects here at Apache seems to release in a
> standardized way and all uses Maven, so to me that's what I call an
> "industrialized build process" that ensures a results, stability and
> reliability as well as easy to update as changes in the project evolve over
> time
> * My perception of the problems other RMs had over time with building in
> its own machines, or upload artifacts to a.o and other issues was caused
> for our current not standardized (not industrial) build process that mix
> Maven and Ant. So by choosing 1) I expect those problems to be removed and
> release without effort from a normal machine.
>
> I'm as well only just "one vote" as you. We saw already what Harbs thinks.
> Maybe others should express as well, even if they are not PMC since I think
> this is important. As I said this is for me maybe the most important
> problem we have right now, and is clear its a problem since we didn't
> release since October, 2019. And right now, we can't because the CI steps
> are broken and maybe just you know how to fix it, and you already stated
> several times that you don't plan to do it. Chris and I can try, but in
> other different way that we think is more "standard" or "industrial". So
> others must pronounce to see as a community what we should do, taking into
> account that we need something that needs to be reliable over time and not
> break with each improvements we want to do to build scripts (Maven or Ant),
> and make easy for a RM to do the task without spending a several days on
> it.
>
> to conclude, if people finally want to go with CI process (2), I think I'll
> try to ask Chris for doing the maven improvements, we wanted as soon as we
> can, so then others can try to go over CI steps and see if they are more
> lucky than me on trying it, just to avoid fix, change maven, and need again
> to fix.
>
> Thanks
>
>
>
>
>
>
> El mar., 17 mar. 2020 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > HI Carlos,
> >
> > I only have one vote. But we've spent a lot of time on this issue
> already
> > and the answer has always been the same: use Maven for Maven artifacts,
> use
> > Ant for Ant artifacts. I would much rather you spend your energy on
> fixing
> > what was a working release process. Of course it didn't work perfectly
> for
> > Piotr at first because it is a complex process, but eventually it did
> > work. If we did change to some new process that you want should we have
> > the same strict criteria that if it doesn't work the first time it must
> > therefore be no good? I'm sure you would not agree to that.
> >
> > I don't know what you mean by "industrial", but I'm quite certain these
> > days that we can't use the "expected" solution. This is a key point.
> You
> > and Chris have not been through the release process so you don't know the
> > kinds of issues that have to be resolved. I explained these issues in my
> > earlier response. I used a much more "expected" solution for the first
> > Royale releases and we found out that nobody else except me could use
> > them. So we were forced to try this CI multi-step process and finally,
> we
> > had someone be a successful RM other than me. So, any solution that
> might
> > work for you and Chris that uses Maven in the "expected" way on your
> > computer is likely to fail to work for other people. That's just our
> > reality.
> >
> > I do not recall seeing any questions about the CI steps since the new
> > Maven build seemed to stabilize, so I don't understand why you chose to
> > spend so much time on fixing them without asking a question on our lists.
> > I will try to answer questions if you have them. The steps are pretty
> > simple: Whatever steps you would normally run on the command-line to
> > create a release are captured in these steps. At some point, the steps
> > generate something that needs to be committed (like a branch, or updated
> > poms) or signed, and so that Jenkins job ends so the RM can log into the
> CI
> > server and commit the changes, then another step continues on until the
> > next commit or signing is needed.
> >
> > I will try to find time to understand how the Maven build now works, but
> I
> > am going to try really hard not to be the person who goes and fixes these
> > release steps. Not only did I not break them, but it would be better for
> > others to understand more about how they work. There is certainly room
> for
> > improvement in the steps, but fundamentally, we have to have a process
> > where some shared computer with a known good configuration does some
> work,
> > the RM then does a commit or sign, and so on.
> >
> > There are no restrictions I can think of on what Maven can be tasked to
> do
> > within a step, the only restriction occurs when something needs to be
> > committed or signed. And we need reproducible binaries in order to
> > validate the artifacts. Once you have local computer validation it makes
> > sense to me to use Maven's Wagon to upload to repository.a.o instead of
> the
> > Maven release plugin, but there might be a better way.
> >
> > In the end, though, Maven will build the Maven artifacts and Ant will
> > build the Ant artifacts. That way we validate as we build the artifacts.
> >
> > My 2 cents,
> > -Alex
> >
> >
> >
> >
> >
> > On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Alex,
> >
> > I don't think you should be upset, don't think that to be a positive
> > way to
> > discuss this task, since in that way you force a solution and maybe
> > not all
> > of us think the same way as you. So although it could cause some
> > tiring to
> > all of us (me included) I think we need to put all our effort to get
> to
> > some point where we all be satisfied.
> >
> > This is probably the most problematic task we have in Royale, and
> > since is
> > difficult to solve and seems there are at least two groups of people
> > thinking in different ways, we need to get what's the better way to
> > solve
> > it. No one way of thinking is better that other you have valid points
> > (but
> > in the same way I can find arguments against them), but don't think
> > that is
> > a productive route. I want to spend our times in get a real solution.
> >
> > The CI steps you did was a great effort and very appreciated. I was
> > very
> > happy when you made it, since from outside it all sound very
> promising.
> > Then IIRC Piotr's release doesn't was as straight as expected. So I
> > think
> > that was a point we should all take into account. Then my experience
> > updating maven and broken some steps was as well something from what
> we
> > should learn and think about it. I tried to fix them without exit. I
> > still
> > want to improve Maven even more in the future. One of the problem I
> > see is:
> > If we fix CI steps, will broke again when new changes in maven will
> be
> > done? probably...and will the fix as difficult as now? In my
> > experience,
> > probably too.
> >
> > Don't think as well that is good for this discussion impose a way to
> > act.
> > I'll be fixing CI steps if I could, but I repeat that I tried during
> > some
> > days without exit. Spend many hours over it. So is not something I'd
> > not
> > do, is just that the process is very fragile and is not what I expect
> > it
> > will bring to us. Each thing we change can break it and that's a huge
> > problem ahead. Or is just me the only one that see a huge problem on
> > this?.
> >
> > Instead, I can offer my work in fixing in other way that I think is
> > more
> > "industrial" or proven, but you don't like it, due to the points you
> > express (that I repeat can be valid, but I see that all are totally
> > surmountable If we work in a more industrial way to solve it. Don't
> > think
> > we are more special that other hundreds of projects out there, and
> all
> > of
> > that projects just use maven for release.
> >
> > Maven SDK could still not be 100%, that's right, but is one of the
> > things
> > we need to fix in the actual process I offer. For sure. And releasing
> > that
> > way, you still can build with ANT and check it was all right. We
> don't
> > need
> > to do at the same time that releasing. I think that's a valid point.
> >
> > I think that if you defend the CI steps in such fixed way, the rest
> of
> > us
> > thinking that's not the way to go can just not oppose, but you can't
> > ask us
> > to be responsible of trying to solve something that is very (very)
> > difficult to solve, since maybe we just can't do it. You must take
> into
> > account that new changes could come (to ant, to maven), and working
> > that
> > way should be your responsibility or the any others here that think
> in
> > that
> > way. I can help or support in the way I can, but maybe limited in
> some
> > way.
> > And of course, we should all know that new optimizations to build
> > systems
> > can't be stopped to defend a concrete way to release. IOW, release
> is a
> > process to "publish for other", and we can't block progress in the
> > project
> > or in the way we build to support a concrete way of release.
> >
> > just my 2
> >
> > Carlos
> >
> >
> >
> >
> >
> > El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>)
> > escribió:
> >
> > > +1
> > >
> > > Harbs
> > >
> > > > On Mar 17, 2020, at 8:10 PM, Alex Harui <aharui@adobe.com.INVALID
> >
> > > wrote:
> > > >
> > > > I’m sorry, but these repeated attempts to try to use Maven too
> > much just
> > > make me very upset. This was a concern of mine when two people who
> > have
> > > never produced a release went off to refactor the process. There
> is
> > theory
> > > and reality. The reality is that Maven cannot and should not be
> > used to
> > > streamline our release process because:
> > > >
> > > > - We've learned over the years that RMs have trouble getting set
> up
> > > correctly.
> > > > - We've learned over the years that RMs have trouble uploading
> > Maven
> > > artifacts to repository.a.o.
> > > > - We should know that the only way to validate the Ant Task in
> the
> > > release artifacts is to use Ant to verify it.
> > > >
> > > > Those are the three main reasons there are multiple release steps
> > on the
> > > CI server. I am hopeful that the new Maven builds can cut down on
> > one or
> > > two steps, or maybe just make those steps more straightforward, but
> > the
> > > process simply cannot just run Maven's release steps on the RM's
> > local
> > > computer. It must run on the CI server, and that requires stopping
> > from
> > > time to time to verify and sign stuff.
> > > >
> > > > A fourth reason was that the Ant script had proven to be able to
> > build
> > > an IDE-compatible artifact. I am not 100% convinced that the Maven
> > > distribution build can exactly replicate that artifact. But again,
> > if an
> > > Ant user wants to use Ant to create artifacts for some IDE to test
> > local
> > > changes, then we need to prove in each release that Ant can produce
> > that
> > > set of artifacts for the IDE. So now that Maven can supposedly do
> > the
> > > same, it actually adds more work to the verification process. The
> > Maven
> > > artifacts for an IDE will need to be compared against the
> > Ant-produced
> > > artifacts for an IDE.
> > > >
> > > > In short, we should use Maven to produce Maven artifacts, and Ant
> > to
> > > produce Ant artifacts so that the RM is verifying the artifacts
> long
> > before
> > > the voters have to. And make it all work on a CI server so that
> > RM's don't
> > > have to deal with system setup, and not have upload issues blow up
> > the
> > > process.
> > > >
> > > > I also am not a fan of using Maven to do scripting, especially if
> > it
> > > involves custom mojos/plugins. That's what scripting tools like
> Ant
> > are
> > > for. The goal should be to make the release system maintainable by
> > > everyone, not just by experts in Maven. Similarly, the Ant steps
> do
> > not
> > > use custom plugins/tasks for the same reason.
> > > >
> > > > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> > > artifacts and sequence the steps. Use the CI server. Verify and
> > sign
> > > locally. These are the requirements. It was all working and we
> > could have
> > > released every month. I think it is your responsibility to make it
> > work
> > > again within those constraints.
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org
> > <mailto:
> > > carlosrovira@apache.org>> wrote:
> > > >
> > > > Hi
> > > >
> > > > this morning in the slack Apache Royale official channel Chris
> > Dutz
> > > asked
> > > > about plans for release 0.9.7. If you see Greg and I help him
> to
> > > create an
> > > > Apache Royale interface for pulling data from a Consumer in an
> > IoT
> > > Apache
> > > > PLC4X app. Something very cool :). He published a tweet with a
> > video
> > > > showing it.
> > > >
> > > > So regarding the release, I explain that I spent many days
> some
> > > months ago
> > > > trying to fix the CI release steps to release, but I was
> unable
> > to do
> > > it. I
> > > > think making changes to the Maven o Ant make the 13 steps very
> > > fragile and
> > > > difficult to fix. And we need to evolve continually Maven and
> > Ant, so
> > > that
> > > > means a huge task that will require an huge amount of time
> that
> > almost
> > > > nobody here has. So I must say that although the work done on
> > that
> > > front
> > > > was amazing and huge maybe we need to streamline it to an
> > standard. I
> > > know
> > > > is difficult, but although we had many expectations put on the
> > 13 step
> > > > release process, after try it seems that we finally are not
> > getting
> > > what we
> > > > wanted, that is streamline the release process.
> > > >
> > > > This is one of the critical points that hold us to release
> 1.0,
> > since
> > > not
> > > > having an easy way to release means as we push 1.0 and people
> > tries
> > > us,
> > > > we'll need to be faster on releasing, and we can't wait 6
> month
> > or a
> > > year,
> > > > since that we'll mean user will not want that kind of release
> > cycle.
> > > >
> > > > So here is my proposal to work on a release process that allow
> > us to
> > > > release more often and more easily. Hope you all can consider
> > it:
> > > >
> > > > First: We all know we want build with ANT and MAVEN. And when
> I
> > refer
> > > to
> > > > "all" I really mean "all". Although I'm a Maven advocate, I
> > really
> > > > appreciate the point to have ANT on place so having 2 build
> > systems
> > > that
> > > > completely works mean advantage. In fact although I use maven
> I
> > build
> > > with
> > > > both system daily.
> > > >
> > > > Second: Build does not mean Release. I think other times we
> > discussed
> > > > Release as a way to impose Maven over Ant. Or maybe that was
> the
> > > perception
> > > > for others, but not my intention (and maybe not the intention
> of
> > > others).
> > > > But that's not the objective. Release [1] means to us just
> > > "publication
> > > > outside the development community, defined as individuals
> > actively
> > > > participating in development or following the dev list."
> > > >
> > > > That means that we don't need to release using Maven and Ant
> at
> > the
> > > same
> > > > time, we can streamline greatly the process to just releasing
> > with
> > > Maven so
> > > > we can ensure a simple process the same as any other Apache
> > project.
> > > >
> > > > It means that people trying the release need to check it with
> > Maven,
> > > but
> > > > community users can continue using ANT or Maven to build or
> > even just
> > > > download the SDK and use it on his IDE of choice and don't use
> > ANT or
> > > Maven
> > > > at all.
> > > >
> > > > Third: The fact is the rest of projects I know all use
> releases
> > and CI
> > > > based on Maven, and that should point us that maybe we're
> > trying to
> > > > force something that is not standard in our industry, so if we
> > want
> > > to make
> > > > it more reliable and easy process, is normal to embrace how
> > others are
> > > > doing, since that does not mean we're throwing away a build
> > system,
> > > since
> > > > per previous point we don't want to remove ANT.
> > > >
> > > > Finally, Chris and I offer our time to make the easiest
> release
> > > process we can
> > > > that let all of us release easily and often (maybe each 1-2
> > month?)
> > > >
> > > > Thanks
> > > >
> > > >
> > > > [1]
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=PP%2Bq0O86F%2FguQtSIDzpGOa3CIM4qTiKmf%2FlmUVS7%2B%2Bo%3D&reserved=0
> > > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
RE: About release 0.9.7 and how to fix and streamline the process
Posted by Yishay Weiss <yi...@hotmail.com>.
If I recall correctly, one the goals of using the CI was to enable incremental release so more than one contributor could work on a single release. I really hope that can be achieved whatever path is chosen.
From: Carlos Rovira<ma...@apache.org>
Sent: Wednesday, March 18, 2020 2:09 AM
To: Apache Royale Development<ma...@royale.apache.org>
Subject: Re: About release 0.9.7 and how to fix and streamline the process
Hi Alex,
as I see it we have mostly two ways to choose:
1) Left Chris and I try to fix Maven distribution SDK (compilation with IDE
is the only thing broken). And try what we defend. Maybe we can be wrong. I
don't mind to recognize it if we reach a wrong path (Maybe in this process
we find some low level issues that we didn't know and fail in the attempt.
It's clear that we don't know as you all the involved things in the
process, and if that happens, will be easy to say, "Hey! the proposal was
not ok since we found X and Y, so that can't be done").
In the other hand, if we succed...We (all) can get from this effort a more
easy way to release. We know we need to ensure Maven and Ant continue to
work as a build and can be reproducible. I think that must be the main
point for all of us and not any other thing. Just that. If we get success
along the way we get some improvements and streamline the process, I think
we all will benefit from that and Apache Royale as a project will benefit
of all the improvements done with that effort. All of this of course taking
into account that I can get Chris help to do this.
Note for Harbs: If we can ensure ANT build is working right (I assume that
is what you should care since is the build system you use), where is the
point on imposing us the need to complicate a release with doing such
intricate process?
2) We continue with the CI steps. But for this I'll want to continue
improving the Maven build process and that should not be a problem for CI
steps. For this I can try to help on fixing CI steps. If you remember I was
asking here questions, and as well some messages from the CI was sent for
steps 1,2 and 3 during some days when I tried to go over it, but with
no success at all. I even create duplicates of CI steps on the CI to ensure
I work over copies to avoid change things over main ones and lost old ones.
Maybe Harbs, Yishay or others can try to fix it and see if they find it
easy and reliable for the future. Their experience will be very valuable.
My experience was not good, but maybe I'm wrong and other's experience is
better. I think Piotr's was hard, since he spend almost 2 weeks in this
try, but I think he finally was ok.
Alex to respond to some other points in you email and conclude:
* for "industrial" I mean a proven way that other software projects use to
release. Almost all projects here at Apache seems to release in a
standardized way and all uses Maven, so to me that's what I call an
"industrialized build process" that ensures a results, stability and
reliability as well as easy to update as changes in the project evolve over
time
* My perception of the problems other RMs had over time with building in
its own machines, or upload artifacts to a.o and other issues was caused
for our current not standardized (not industrial) build process that mix
Maven and Ant. So by choosing 1) I expect those problems to be removed and
release without effort from a normal machine.
I'm as well only just "one vote" as you. We saw already what Harbs thinks.
Maybe others should express as well, even if they are not PMC since I think
this is important. As I said this is for me maybe the most important
problem we have right now, and is clear its a problem since we didn't
release since October, 2019. And right now, we can't because the CI steps
are broken and maybe just you know how to fix it, and you already stated
several times that you don't plan to do it. Chris and I can try, but in
other different way that we think is more "standard" or "industrial". So
others must pronounce to see as a community what we should do, taking into
account that we need something that needs to be reliable over time and not
break with each improvements we want to do to build scripts (Maven or Ant),
and make easy for a RM to do the task without spending a several days on it.
to conclude, if people finally want to go with CI process (2), I think I'll
try to ask Chris for doing the maven improvements, we wanted as soon as we
can, so then others can try to go over CI steps and see if they are more
lucky than me on trying it, just to avoid fix, change maven, and need again
to fix.
Thanks
El mar., 17 mar. 2020 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> HI Carlos,
>
> I only have one vote. But we've spent a lot of time on this issue already
> and the answer has always been the same: use Maven for Maven artifacts, use
> Ant for Ant artifacts. I would much rather you spend your energy on fixing
> what was a working release process. Of course it didn't work perfectly for
> Piotr at first because it is a complex process, but eventually it did
> work. If we did change to some new process that you want should we have
> the same strict criteria that if it doesn't work the first time it must
> therefore be no good? I'm sure you would not agree to that.
>
> I don't know what you mean by "industrial", but I'm quite certain these
> days that we can't use the "expected" solution. This is a key point. You
> and Chris have not been through the release process so you don't know the
> kinds of issues that have to be resolved. I explained these issues in my
> earlier response. I used a much more "expected" solution for the first
> Royale releases and we found out that nobody else except me could use
> them. So we were forced to try this CI multi-step process and finally, we
> had someone be a successful RM other than me. So, any solution that might
> work for you and Chris that uses Maven in the "expected" way on your
> computer is likely to fail to work for other people. That's just our
> reality.
>
> I do not recall seeing any questions about the CI steps since the new
> Maven build seemed to stabilize, so I don't understand why you chose to
> spend so much time on fixing them without asking a question on our lists.
> I will try to answer questions if you have them. The steps are pretty
> simple: Whatever steps you would normally run on the command-line to
> create a release are captured in these steps. At some point, the steps
> generate something that needs to be committed (like a branch, or updated
> poms) or signed, and so that Jenkins job ends so the RM can log into the CI
> server and commit the changes, then another step continues on until the
> next commit or signing is needed.
>
> I will try to find time to understand how the Maven build now works, but I
> am going to try really hard not to be the person who goes and fixes these
> release steps. Not only did I not break them, but it would be better for
> others to understand more about how they work. There is certainly room for
> improvement in the steps, but fundamentally, we have to have a process
> where some shared computer with a known good configuration does some work,
> the RM then does a commit or sign, and so on.
>
> There are no restrictions I can think of on what Maven can be tasked to do
> within a step, the only restriction occurs when something needs to be
> committed or signed. And we need reproducible binaries in order to
> validate the artifacts. Once you have local computer validation it makes
> sense to me to use Maven's Wagon to upload to repository.a.o instead of the
> Maven release plugin, but there might be a better way.
>
> In the end, though, Maven will build the Maven artifacts and Ant will
> build the Ant artifacts. That way we validate as we build the artifacts.
>
> My 2 cents,
> -Alex
>
>
>
>
>
> On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I don't think you should be upset, don't think that to be a positive
> way to
> discuss this task, since in that way you force a solution and maybe
> not all
> of us think the same way as you. So although it could cause some
> tiring to
> all of us (me included) I think we need to put all our effort to get to
> some point where we all be satisfied.
>
> This is probably the most problematic task we have in Royale, and
> since is
> difficult to solve and seems there are at least two groups of people
> thinking in different ways, we need to get what's the better way to
> solve
> it. No one way of thinking is better that other you have valid points
> (but
> in the same way I can find arguments against them), but don't think
> that is
> a productive route. I want to spend our times in get a real solution.
>
> The CI steps you did was a great effort and very appreciated. I was
> very
> happy when you made it, since from outside it all sound very promising.
> Then IIRC Piotr's release doesn't was as straight as expected. So I
> think
> that was a point we should all take into account. Then my experience
> updating maven and broken some steps was as well something from what we
> should learn and think about it. I tried to fix them without exit. I
> still
> want to improve Maven even more in the future. One of the problem I
> see is:
> If we fix CI steps, will broke again when new changes in maven will be
> done? probably...and will the fix as difficult as now? In my
> experience,
> probably too.
>
> Don't think as well that is good for this discussion impose a way to
> act.
> I'll be fixing CI steps if I could, but I repeat that I tried during
> some
> days without exit. Spend many hours over it. So is not something I'd
> not
> do, is just that the process is very fragile and is not what I expect
> it
> will bring to us. Each thing we change can break it and that's a huge
> problem ahead. Or is just me the only one that see a huge problem on
> this?.
>
> Instead, I can offer my work in fixing in other way that I think is
> more
> "industrial" or proven, but you don't like it, due to the points you
> express (that I repeat can be valid, but I see that all are totally
> surmountable If we work in a more industrial way to solve it. Don't
> think
> we are more special that other hundreds of projects out there, and all
> of
> that projects just use maven for release.
>
> Maven SDK could still not be 100%, that's right, but is one of the
> things
> we need to fix in the actual process I offer. For sure. And releasing
> that
> way, you still can build with ANT and check it was all right. We don't
> need
> to do at the same time that releasing. I think that's a valid point.
>
> I think that if you defend the CI steps in such fixed way, the rest of
> us
> thinking that's not the way to go can just not oppose, but you can't
> ask us
> to be responsible of trying to solve something that is very (very)
> difficult to solve, since maybe we just can't do it. You must take into
> account that new changes could come (to ant, to maven), and working
> that
> way should be your responsibility or the any others here that think in
> that
> way. I can help or support in the way I can, but maybe limited in some
> way.
> And of course, we should all know that new optimizations to build
> systems
> can't be stopped to defend a concrete way to release. IOW, release is a
> process to "publish for other", and we can't block progress in the
> project
> or in the way we build to support a concrete way of release.
>
> just my 2
>
> Carlos
>
>
>
>
>
> El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > +1
> >
> > Harbs
> >
> > > On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID>
> > wrote:
> > >
> > > I’m sorry, but these repeated attempts to try to use Maven too
> much just
> > make me very upset. This was a concern of mine when two people who
> have
> > never produced a release went off to refactor the process. There is
> theory
> > and reality. The reality is that Maven cannot and should not be
> used to
> > streamline our release process because:
> > >
> > > - We've learned over the years that RMs have trouble getting set up
> > correctly.
> > > - We've learned over the years that RMs have trouble uploading
> Maven
> > artifacts to repository.a.o.
> > > - We should know that the only way to validate the Ant Task in the
> > release artifacts is to use Ant to verify it.
> > >
> > > Those are the three main reasons there are multiple release steps
> on the
> > CI server. I am hopeful that the new Maven builds can cut down on
> one or
> > two steps, or maybe just make those steps more straightforward, but
> the
> > process simply cannot just run Maven's release steps on the RM's
> local
> > computer. It must run on the CI server, and that requires stopping
> from
> > time to time to verify and sign stuff.
> > >
> > > A fourth reason was that the Ant script had proven to be able to
> build
> > an IDE-compatible artifact. I am not 100% convinced that the Maven
> > distribution build can exactly replicate that artifact. But again,
> if an
> > Ant user wants to use Ant to create artifacts for some IDE to test
> local
> > changes, then we need to prove in each release that Ant can produce
> that
> > set of artifacts for the IDE. So now that Maven can supposedly do
> the
> > same, it actually adds more work to the verification process. The
> Maven
> > artifacts for an IDE will need to be compared against the
> Ant-produced
> > artifacts for an IDE.
> > >
> > > In short, we should use Maven to produce Maven artifacts, and Ant
> to
> > produce Ant artifacts so that the RM is verifying the artifacts long
> before
> > the voters have to. And make it all work on a CI server so that
> RM's don't
> > have to deal with system setup, and not have upload issues blow up
> the
> > process.
> > >
> > > I also am not a fan of using Maven to do scripting, especially if
> it
> > involves custom mojos/plugins. That's what scripting tools like Ant
> are
> > for. The goal should be to make the release system maintainable by
> > everyone, not just by experts in Maven. Similarly, the Ant steps do
> not
> > use custom plugins/tasks for the same reason.
> > >
> > > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> > artifacts and sequence the steps. Use the CI server. Verify and
> sign
> > locally. These are the requirements. It was all working and we
> could have
> > released every month. I think it is your responsibility to make it
> work
> > again within those constraints.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org
> <mailto:
> > carlosrovira@apache.org>> wrote:
> > >
> > > Hi
> > >
> > > this morning in the slack Apache Royale official channel Chris
> Dutz
> > asked
> > > about plans for release 0.9.7. If you see Greg and I help him to
> > create an
> > > Apache Royale interface for pulling data from a Consumer in an
> IoT
> > Apache
> > > PLC4X app. Something very cool :). He published a tweet with a
> video
> > > showing it.
> > >
> > > So regarding the release, I explain that I spent many days some
> > months ago
> > > trying to fix the CI release steps to release, but I was unable
> to do
> > it. I
> > > think making changes to the Maven o Ant make the 13 steps very
> > fragile and
> > > difficult to fix. And we need to evolve continually Maven and
> Ant, so
> > that
> > > means a huge task that will require an huge amount of time that
> almost
> > > nobody here has. So I must say that although the work done on
> that
> > front
> > > was amazing and huge maybe we need to streamline it to an
> standard. I
> > know
> > > is difficult, but although we had many expectations put on the
> 13 step
> > > release process, after try it seems that we finally are not
> getting
> > what we
> > > wanted, that is streamline the release process.
> > >
> > > This is one of the critical points that hold us to release 1.0,
> since
> > not
> > > having an easy way to release means as we push 1.0 and people
> tries
> > us,
> > > we'll need to be faster on releasing, and we can't wait 6 month
> or a
> > year,
> > > since that we'll mean user will not want that kind of release
> cycle.
> > >
> > > So here is my proposal to work on a release process that allow
> us to
> > > release more often and more easily. Hope you all can consider
> it:
> > >
> > > First: We all know we want build with ANT and MAVEN. And when I
> refer
> > to
> > > "all" I really mean "all". Although I'm a Maven advocate, I
> really
> > > appreciate the point to have ANT on place so having 2 build
> systems
> > that
> > > completely works mean advantage. In fact although I use maven I
> build
> > with
> > > both system daily.
> > >
> > > Second: Build does not mean Release. I think other times we
> discussed
> > > Release as a way to impose Maven over Ant. Or maybe that was the
> > perception
> > > for others, but not my intention (and maybe not the intention of
> > others).
> > > But that's not the objective. Release [1] means to us just
> > "publication
> > > outside the development community, defined as individuals
> actively
> > > participating in development or following the dev list."
> > >
> > > That means that we don't need to release using Maven and Ant at
> the
> > same
> > > time, we can streamline greatly the process to just releasing
> with
> > Maven so
> > > we can ensure a simple process the same as any other Apache
> project.
> > >
> > > It means that people trying the release need to check it with
> Maven,
> > but
> > > community users can continue using ANT or Maven to build or
> even just
> > > download the SDK and use it on his IDE of choice and don't use
> ANT or
> > Maven
> > > at all.
> > >
> > > Third: The fact is the rest of projects I know all use releases
> and CI
> > > based on Maven, and that should point us that maybe we're
> trying to
> > > force something that is not standard in our industry, so if we
> want
> > to make
> > > it more reliable and easy process, is normal to embrace how
> others are
> > > doing, since that does not mean we're throwing away a build
> system,
> > since
> > > per previous point we don't want to remove ANT.
> > >
> > > Finally, Chris and I offer our time to make the easiest release
> > process we can
> > > that let all of us release easily and often (maybe each 1-2
> month?)
> > >
> > > Thanks
> > >
> > >
> > > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=PP%2Bq0O86F%2FguQtSIDzpGOa3CIM4qTiKmf%2FlmUVS7%2B%2Bo%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> > >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Carlos, IMO, we have to go with #2. We don't have enough time and people to repeat history. You weren't in the trenches doing the releases so your theories are not based on experience and data. The facts are that I was able to release the Maven artifacts using the standard/industrial Maven release plugin, but nobody else could. Unless Om and Piotr and Yishay have the time to experiment with the standard mechanism that failed before, we should just not bother. That's why we went with the CI steps.
If anyone tries to refactor someone else's work, they should understand the requirements before refactoring. I had hoped that you and Chris has looked at the CI steps to try to understand them, and paid attention to or reviewed past threads about failed RM attempts before doing this refactor. I just went back and reviewed the questions you asked about the CI steps. I believe I answered your questions, but it was apparent that neither you or Chris took the time to understand the current requirements. Instead, the requirements were tossed in favor of going back to the standard release plugin process we had just abandoned due to what we had learned the hard way.
I tried to summarize the requirements in this thread. Because the steps must run on the CI server, they have to stop periodically for a commit, and can't do things like sign artifacts. That has to be a separate step done by the RM after verification. And then another step starts up. It really shouldn't matter what the steps are, they just have to be broken into smaller chunks for the CI steps.
Where is the current "recipe" for the Maven build? Has it been updated in the README?
-Alex
On 3/17/20, 5:09 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
as I see it we have mostly two ways to choose:
1) Left Chris and I try to fix Maven distribution SDK (compilation with IDE
is the only thing broken). And try what we defend. Maybe we can be wrong. I
don't mind to recognize it if we reach a wrong path (Maybe in this process
we find some low level issues that we didn't know and fail in the attempt.
It's clear that we don't know as you all the involved things in the
process, and if that happens, will be easy to say, "Hey! the proposal was
not ok since we found X and Y, so that can't be done").
In the other hand, if we succed...We (all) can get from this effort a more
easy way to release. We know we need to ensure Maven and Ant continue to
work as a build and can be reproducible. I think that must be the main
point for all of us and not any other thing. Just that. If we get success
along the way we get some improvements and streamline the process, I think
we all will benefit from that and Apache Royale as a project will benefit
of all the improvements done with that effort. All of this of course taking
into account that I can get Chris help to do this.
Note for Harbs: If we can ensure ANT build is working right (I assume that
is what you should care since is the build system you use), where is the
point on imposing us the need to complicate a release with doing such
intricate process?
2) We continue with the CI steps. But for this I'll want to continue
improving the Maven build process and that should not be a problem for CI
steps. For this I can try to help on fixing CI steps. If you remember I was
asking here questions, and as well some messages from the CI was sent for
steps 1,2 and 3 during some days when I tried to go over it, but with
no success at all. I even create duplicates of CI steps on the CI to ensure
I work over copies to avoid change things over main ones and lost old ones.
Maybe Harbs, Yishay or others can try to fix it and see if they find it
easy and reliable for the future. Their experience will be very valuable.
My experience was not good, but maybe I'm wrong and other's experience is
better. I think Piotr's was hard, since he spend almost 2 weeks in this
try, but I think he finally was ok.
Alex to respond to some other points in you email and conclude:
* for "industrial" I mean a proven way that other software projects use to
release. Almost all projects here at Apache seems to release in a
standardized way and all uses Maven, so to me that's what I call an
"industrialized build process" that ensures a results, stability and
reliability as well as easy to update as changes in the project evolve over
time
* My perception of the problems other RMs had over time with building in
its own machines, or upload artifacts to a.o and other issues was caused
for our current not standardized (not industrial) build process that mix
Maven and Ant. So by choosing 1) I expect those problems to be removed and
release without effort from a normal machine.
I'm as well only just "one vote" as you. We saw already what Harbs thinks.
Maybe others should express as well, even if they are not PMC since I think
this is important. As I said this is for me maybe the most important
problem we have right now, and is clear its a problem since we didn't
release since October, 2019. And right now, we can't because the CI steps
are broken and maybe just you know how to fix it, and you already stated
several times that you don't plan to do it. Chris and I can try, but in
other different way that we think is more "standard" or "industrial". So
others must pronounce to see as a community what we should do, taking into
account that we need something that needs to be reliable over time and not
break with each improvements we want to do to build scripts (Maven or Ant),
and make easy for a RM to do the task without spending a several days on it.
to conclude, if people finally want to go with CI process (2), I think I'll
try to ask Chris for doing the maven improvements, we wanted as soon as we
can, so then others can try to go over CI steps and see if they are more
lucky than me on trying it, just to avoid fix, change maven, and need again
to fix.
Thanks
El mar., 17 mar. 2020 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> HI Carlos,
>
> I only have one vote. But we've spent a lot of time on this issue already
> and the answer has always been the same: use Maven for Maven artifacts, use
> Ant for Ant artifacts. I would much rather you spend your energy on fixing
> what was a working release process. Of course it didn't work perfectly for
> Piotr at first because it is a complex process, but eventually it did
> work. If we did change to some new process that you want should we have
> the same strict criteria that if it doesn't work the first time it must
> therefore be no good? I'm sure you would not agree to that.
>
> I don't know what you mean by "industrial", but I'm quite certain these
> days that we can't use the "expected" solution. This is a key point. You
> and Chris have not been through the release process so you don't know the
> kinds of issues that have to be resolved. I explained these issues in my
> earlier response. I used a much more "expected" solution for the first
> Royale releases and we found out that nobody else except me could use
> them. So we were forced to try this CI multi-step process and finally, we
> had someone be a successful RM other than me. So, any solution that might
> work for you and Chris that uses Maven in the "expected" way on your
> computer is likely to fail to work for other people. That's just our
> reality.
>
> I do not recall seeing any questions about the CI steps since the new
> Maven build seemed to stabilize, so I don't understand why you chose to
> spend so much time on fixing them without asking a question on our lists.
> I will try to answer questions if you have them. The steps are pretty
> simple: Whatever steps you would normally run on the command-line to
> create a release are captured in these steps. At some point, the steps
> generate something that needs to be committed (like a branch, or updated
> poms) or signed, and so that Jenkins job ends so the RM can log into the CI
> server and commit the changes, then another step continues on until the
> next commit or signing is needed.
>
> I will try to find time to understand how the Maven build now works, but I
> am going to try really hard not to be the person who goes and fixes these
> release steps. Not only did I not break them, but it would be better for
> others to understand more about how they work. There is certainly room for
> improvement in the steps, but fundamentally, we have to have a process
> where some shared computer with a known good configuration does some work,
> the RM then does a commit or sign, and so on.
>
> There are no restrictions I can think of on what Maven can be tasked to do
> within a step, the only restriction occurs when something needs to be
> committed or signed. And we need reproducible binaries in order to
> validate the artifacts. Once you have local computer validation it makes
> sense to me to use Maven's Wagon to upload to repository.a.o instead of the
> Maven release plugin, but there might be a better way.
>
> In the end, though, Maven will build the Maven artifacts and Ant will
> build the Ant artifacts. That way we validate as we build the artifacts.
>
> My 2 cents,
> -Alex
>
>
>
>
>
> On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I don't think you should be upset, don't think that to be a positive
> way to
> discuss this task, since in that way you force a solution and maybe
> not all
> of us think the same way as you. So although it could cause some
> tiring to
> all of us (me included) I think we need to put all our effort to get to
> some point where we all be satisfied.
>
> This is probably the most problematic task we have in Royale, and
> since is
> difficult to solve and seems there are at least two groups of people
> thinking in different ways, we need to get what's the better way to
> solve
> it. No one way of thinking is better that other you have valid points
> (but
> in the same way I can find arguments against them), but don't think
> that is
> a productive route. I want to spend our times in get a real solution.
>
> The CI steps you did was a great effort and very appreciated. I was
> very
> happy when you made it, since from outside it all sound very promising.
> Then IIRC Piotr's release doesn't was as straight as expected. So I
> think
> that was a point we should all take into account. Then my experience
> updating maven and broken some steps was as well something from what we
> should learn and think about it. I tried to fix them without exit. I
> still
> want to improve Maven even more in the future. One of the problem I
> see is:
> If we fix CI steps, will broke again when new changes in maven will be
> done? probably...and will the fix as difficult as now? In my
> experience,
> probably too.
>
> Don't think as well that is good for this discussion impose a way to
> act.
> I'll be fixing CI steps if I could, but I repeat that I tried during
> some
> days without exit. Spend many hours over it. So is not something I'd
> not
> do, is just that the process is very fragile and is not what I expect
> it
> will bring to us. Each thing we change can break it and that's a huge
> problem ahead. Or is just me the only one that see a huge problem on
> this?.
>
> Instead, I can offer my work in fixing in other way that I think is
> more
> "industrial" or proven, but you don't like it, due to the points you
> express (that I repeat can be valid, but I see that all are totally
> surmountable If we work in a more industrial way to solve it. Don't
> think
> we are more special that other hundreds of projects out there, and all
> of
> that projects just use maven for release.
>
> Maven SDK could still not be 100%, that's right, but is one of the
> things
> we need to fix in the actual process I offer. For sure. And releasing
> that
> way, you still can build with ANT and check it was all right. We don't
> need
> to do at the same time that releasing. I think that's a valid point.
>
> I think that if you defend the CI steps in such fixed way, the rest of
> us
> thinking that's not the way to go can just not oppose, but you can't
> ask us
> to be responsible of trying to solve something that is very (very)
> difficult to solve, since maybe we just can't do it. You must take into
> account that new changes could come (to ant, to maven), and working
> that
> way should be your responsibility or the any others here that think in
> that
> way. I can help or support in the way I can, but maybe limited in some
> way.
> And of course, we should all know that new optimizations to build
> systems
> can't be stopped to defend a concrete way to release. IOW, release is a
> process to "publish for other", and we can't block progress in the
> project
> or in the way we build to support a concrete way of release.
>
> just my 2
>
> Carlos
>
>
>
>
>
> El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > +1
> >
> > Harbs
> >
> > > On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID>
> > wrote:
> > >
> > > I’m sorry, but these repeated attempts to try to use Maven too
> much just
> > make me very upset. This was a concern of mine when two people who
> have
> > never produced a release went off to refactor the process. There is
> theory
> > and reality. The reality is that Maven cannot and should not be
> used to
> > streamline our release process because:
> > >
> > > - We've learned over the years that RMs have trouble getting set up
> > correctly.
> > > - We've learned over the years that RMs have trouble uploading
> Maven
> > artifacts to repository.a.o.
> > > - We should know that the only way to validate the Ant Task in the
> > release artifacts is to use Ant to verify it.
> > >
> > > Those are the three main reasons there are multiple release steps
> on the
> > CI server. I am hopeful that the new Maven builds can cut down on
> one or
> > two steps, or maybe just make those steps more straightforward, but
> the
> > process simply cannot just run Maven's release steps on the RM's
> local
> > computer. It must run on the CI server, and that requires stopping
> from
> > time to time to verify and sign stuff.
> > >
> > > A fourth reason was that the Ant script had proven to be able to
> build
> > an IDE-compatible artifact. I am not 100% convinced that the Maven
> > distribution build can exactly replicate that artifact. But again,
> if an
> > Ant user wants to use Ant to create artifacts for some IDE to test
> local
> > changes, then we need to prove in each release that Ant can produce
> that
> > set of artifacts for the IDE. So now that Maven can supposedly do
> the
> > same, it actually adds more work to the verification process. The
> Maven
> > artifacts for an IDE will need to be compared against the
> Ant-produced
> > artifacts for an IDE.
> > >
> > > In short, we should use Maven to produce Maven artifacts, and Ant
> to
> > produce Ant artifacts so that the RM is verifying the artifacts long
> before
> > the voters have to. And make it all work on a CI server so that
> RM's don't
> > have to deal with system setup, and not have upload issues blow up
> the
> > process.
> > >
> > > I also am not a fan of using Maven to do scripting, especially if
> it
> > involves custom mojos/plugins. That's what scripting tools like Ant
> are
> > for. The goal should be to make the release system maintainable by
> > everyone, not just by experts in Maven. Similarly, the Ant steps do
> not
> > use custom plugins/tasks for the same reason.
> > >
> > > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> > artifacts and sequence the steps. Use the CI server. Verify and
> sign
> > locally. These are the requirements. It was all working and we
> could have
> > released every month. I think it is your responsibility to make it
> work
> > again within those constraints.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org
> <mailto:
> > carlosrovira@apache.org>> wrote:
> > >
> > > Hi
> > >
> > > this morning in the slack Apache Royale official channel Chris
> Dutz
> > asked
> > > about plans for release 0.9.7. If you see Greg and I help him to
> > create an
> > > Apache Royale interface for pulling data from a Consumer in an
> IoT
> > Apache
> > > PLC4X app. Something very cool :). He published a tweet with a
> video
> > > showing it.
> > >
> > > So regarding the release, I explain that I spent many days some
> > months ago
> > > trying to fix the CI release steps to release, but I was unable
> to do
> > it. I
> > > think making changes to the Maven o Ant make the 13 steps very
> > fragile and
> > > difficult to fix. And we need to evolve continually Maven and
> Ant, so
> > that
> > > means a huge task that will require an huge amount of time that
> almost
> > > nobody here has. So I must say that although the work done on
> that
> > front
> > > was amazing and huge maybe we need to streamline it to an
> standard. I
> > know
> > > is difficult, but although we had many expectations put on the
> 13 step
> > > release process, after try it seems that we finally are not
> getting
> > what we
> > > wanted, that is streamline the release process.
> > >
> > > This is one of the critical points that hold us to release 1.0,
> since
> > not
> > > having an easy way to release means as we push 1.0 and people
> tries
> > us,
> > > we'll need to be faster on releasing, and we can't wait 6 month
> or a
> > year,
> > > since that we'll mean user will not want that kind of release
> cycle.
> > >
> > > So here is my proposal to work on a release process that allow
> us to
> > > release more often and more easily. Hope you all can consider
> it:
> > >
> > > First: We all know we want build with ANT and MAVEN. And when I
> refer
> > to
> > > "all" I really mean "all". Although I'm a Maven advocate, I
> really
> > > appreciate the point to have ANT on place so having 2 build
> systems
> > that
> > > completely works mean advantage. In fact although I use maven I
> build
> > with
> > > both system daily.
> > >
> > > Second: Build does not mean Release. I think other times we
> discussed
> > > Release as a way to impose Maven over Ant. Or maybe that was the
> > perception
> > > for others, but not my intention (and maybe not the intention of
> > others).
> > > But that's not the objective. Release [1] means to us just
> > "publication
> > > outside the development community, defined as individuals
> actively
> > > participating in development or following the dev list."
> > >
> > > That means that we don't need to release using Maven and Ant at
> the
> > same
> > > time, we can streamline greatly the process to just releasing
> with
> > Maven so
> > > we can ensure a simple process the same as any other Apache
> project.
> > >
> > > It means that people trying the release need to check it with
> Maven,
> > but
> > > community users can continue using ANT or Maven to build or
> even just
> > > download the SDK and use it on his IDE of choice and don't use
> ANT or
> > Maven
> > > at all.
> > >
> > > Third: The fact is the rest of projects I know all use releases
> and CI
> > > based on Maven, and that should point us that maybe we're
> trying to
> > > force something that is not standard in our industry, so if we
> want
> > to make
> > > it more reliable and easy process, is normal to embrace how
> others are
> > > doing, since that does not mean we're throwing away a build
> system,
> > since
> > > per previous point we don't want to remove ANT.
> > >
> > > Finally, Chris and I offer our time to make the easiest release
> > process we can
> > > that let all of us release easily and often (maybe each 1-2
> month?)
> > >
> > > Thanks
> > >
> > >
> > > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ca60f735af3e94c85c10508d7cad09c90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200869642685997&sdata=SOfq0l%2BfMHXIIf50CC8skpRn%2BeL5QcIL0rfPsB4nOwo%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ca60f735af3e94c85c10508d7cad09c90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200869642685997&sdata=SOfq0l%2BfMHXIIf50CC8skpRn%2BeL5QcIL0rfPsB4nOwo%3D&reserved=0
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca60f735af3e94c85c10508d7cad09c90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200869642695990&sdata=Hp%2Bpy9EtMPWlaE5zAU8dIEWlSfbomGeV5QggllMUjbU%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca60f735af3e94c85c10508d7cad09c90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200869642695990&sdata=Hp%2Bpy9EtMPWlaE5zAU8dIEWlSfbomGeV5QggllMUjbU%3D&reserved=0
> > >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca60f735af3e94c85c10508d7cad09c90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200869642695990&sdata=Hp%2Bpy9EtMPWlaE5zAU8dIEWlSfbomGeV5QggllMUjbU%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca60f735af3e94c85c10508d7cad09c90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200869642695990&sdata=Hp%2Bpy9EtMPWlaE5zAU8dIEWlSfbomGeV5QggllMUjbU%3D&reserved=0
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
as I see it we have mostly two ways to choose:
1) Left Chris and I try to fix Maven distribution SDK (compilation with IDE
is the only thing broken). And try what we defend. Maybe we can be wrong. I
don't mind to recognize it if we reach a wrong path (Maybe in this process
we find some low level issues that we didn't know and fail in the attempt.
It's clear that we don't know as you all the involved things in the
process, and if that happens, will be easy to say, "Hey! the proposal was
not ok since we found X and Y, so that can't be done").
In the other hand, if we succed...We (all) can get from this effort a more
easy way to release. We know we need to ensure Maven and Ant continue to
work as a build and can be reproducible. I think that must be the main
point for all of us and not any other thing. Just that. If we get success
along the way we get some improvements and streamline the process, I think
we all will benefit from that and Apache Royale as a project will benefit
of all the improvements done with that effort. All of this of course taking
into account that I can get Chris help to do this.
Note for Harbs: If we can ensure ANT build is working right (I assume that
is what you should care since is the build system you use), where is the
point on imposing us the need to complicate a release with doing such
intricate process?
2) We continue with the CI steps. But for this I'll want to continue
improving the Maven build process and that should not be a problem for CI
steps. For this I can try to help on fixing CI steps. If you remember I was
asking here questions, and as well some messages from the CI was sent for
steps 1,2 and 3 during some days when I tried to go over it, but with
no success at all. I even create duplicates of CI steps on the CI to ensure
I work over copies to avoid change things over main ones and lost old ones.
Maybe Harbs, Yishay or others can try to fix it and see if they find it
easy and reliable for the future. Their experience will be very valuable.
My experience was not good, but maybe I'm wrong and other's experience is
better. I think Piotr's was hard, since he spend almost 2 weeks in this
try, but I think he finally was ok.
Alex to respond to some other points in you email and conclude:
* for "industrial" I mean a proven way that other software projects use to
release. Almost all projects here at Apache seems to release in a
standardized way and all uses Maven, so to me that's what I call an
"industrialized build process" that ensures a results, stability and
reliability as well as easy to update as changes in the project evolve over
time
* My perception of the problems other RMs had over time with building in
its own machines, or upload artifacts to a.o and other issues was caused
for our current not standardized (not industrial) build process that mix
Maven and Ant. So by choosing 1) I expect those problems to be removed and
release without effort from a normal machine.
I'm as well only just "one vote" as you. We saw already what Harbs thinks.
Maybe others should express as well, even if they are not PMC since I think
this is important. As I said this is for me maybe the most important
problem we have right now, and is clear its a problem since we didn't
release since October, 2019. And right now, we can't because the CI steps
are broken and maybe just you know how to fix it, and you already stated
several times that you don't plan to do it. Chris and I can try, but in
other different way that we think is more "standard" or "industrial". So
others must pronounce to see as a community what we should do, taking into
account that we need something that needs to be reliable over time and not
break with each improvements we want to do to build scripts (Maven or Ant),
and make easy for a RM to do the task without spending a several days on it.
to conclude, if people finally want to go with CI process (2), I think I'll
try to ask Chris for doing the maven improvements, we wanted as soon as we
can, so then others can try to go over CI steps and see if they are more
lucky than me on trying it, just to avoid fix, change maven, and need again
to fix.
Thanks
El mar., 17 mar. 2020 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> HI Carlos,
>
> I only have one vote. But we've spent a lot of time on this issue already
> and the answer has always been the same: use Maven for Maven artifacts, use
> Ant for Ant artifacts. I would much rather you spend your energy on fixing
> what was a working release process. Of course it didn't work perfectly for
> Piotr at first because it is a complex process, but eventually it did
> work. If we did change to some new process that you want should we have
> the same strict criteria that if it doesn't work the first time it must
> therefore be no good? I'm sure you would not agree to that.
>
> I don't know what you mean by "industrial", but I'm quite certain these
> days that we can't use the "expected" solution. This is a key point. You
> and Chris have not been through the release process so you don't know the
> kinds of issues that have to be resolved. I explained these issues in my
> earlier response. I used a much more "expected" solution for the first
> Royale releases and we found out that nobody else except me could use
> them. So we were forced to try this CI multi-step process and finally, we
> had someone be a successful RM other than me. So, any solution that might
> work for you and Chris that uses Maven in the "expected" way on your
> computer is likely to fail to work for other people. That's just our
> reality.
>
> I do not recall seeing any questions about the CI steps since the new
> Maven build seemed to stabilize, so I don't understand why you chose to
> spend so much time on fixing them without asking a question on our lists.
> I will try to answer questions if you have them. The steps are pretty
> simple: Whatever steps you would normally run on the command-line to
> create a release are captured in these steps. At some point, the steps
> generate something that needs to be committed (like a branch, or updated
> poms) or signed, and so that Jenkins job ends so the RM can log into the CI
> server and commit the changes, then another step continues on until the
> next commit or signing is needed.
>
> I will try to find time to understand how the Maven build now works, but I
> am going to try really hard not to be the person who goes and fixes these
> release steps. Not only did I not break them, but it would be better for
> others to understand more about how they work. There is certainly room for
> improvement in the steps, but fundamentally, we have to have a process
> where some shared computer with a known good configuration does some work,
> the RM then does a commit or sign, and so on.
>
> There are no restrictions I can think of on what Maven can be tasked to do
> within a step, the only restriction occurs when something needs to be
> committed or signed. And we need reproducible binaries in order to
> validate the artifacts. Once you have local computer validation it makes
> sense to me to use Maven's Wagon to upload to repository.a.o instead of the
> Maven release plugin, but there might be a better way.
>
> In the end, though, Maven will build the Maven artifacts and Ant will
> build the Ant artifacts. That way we validate as we build the artifacts.
>
> My 2 cents,
> -Alex
>
>
>
>
>
> On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I don't think you should be upset, don't think that to be a positive
> way to
> discuss this task, since in that way you force a solution and maybe
> not all
> of us think the same way as you. So although it could cause some
> tiring to
> all of us (me included) I think we need to put all our effort to get to
> some point where we all be satisfied.
>
> This is probably the most problematic task we have in Royale, and
> since is
> difficult to solve and seems there are at least two groups of people
> thinking in different ways, we need to get what's the better way to
> solve
> it. No one way of thinking is better that other you have valid points
> (but
> in the same way I can find arguments against them), but don't think
> that is
> a productive route. I want to spend our times in get a real solution.
>
> The CI steps you did was a great effort and very appreciated. I was
> very
> happy when you made it, since from outside it all sound very promising.
> Then IIRC Piotr's release doesn't was as straight as expected. So I
> think
> that was a point we should all take into account. Then my experience
> updating maven and broken some steps was as well something from what we
> should learn and think about it. I tried to fix them without exit. I
> still
> want to improve Maven even more in the future. One of the problem I
> see is:
> If we fix CI steps, will broke again when new changes in maven will be
> done? probably...and will the fix as difficult as now? In my
> experience,
> probably too.
>
> Don't think as well that is good for this discussion impose a way to
> act.
> I'll be fixing CI steps if I could, but I repeat that I tried during
> some
> days without exit. Spend many hours over it. So is not something I'd
> not
> do, is just that the process is very fragile and is not what I expect
> it
> will bring to us. Each thing we change can break it and that's a huge
> problem ahead. Or is just me the only one that see a huge problem on
> this?.
>
> Instead, I can offer my work in fixing in other way that I think is
> more
> "industrial" or proven, but you don't like it, due to the points you
> express (that I repeat can be valid, but I see that all are totally
> surmountable If we work in a more industrial way to solve it. Don't
> think
> we are more special that other hundreds of projects out there, and all
> of
> that projects just use maven for release.
>
> Maven SDK could still not be 100%, that's right, but is one of the
> things
> we need to fix in the actual process I offer. For sure. And releasing
> that
> way, you still can build with ANT and check it was all right. We don't
> need
> to do at the same time that releasing. I think that's a valid point.
>
> I think that if you defend the CI steps in such fixed way, the rest of
> us
> thinking that's not the way to go can just not oppose, but you can't
> ask us
> to be responsible of trying to solve something that is very (very)
> difficult to solve, since maybe we just can't do it. You must take into
> account that new changes could come (to ant, to maven), and working
> that
> way should be your responsibility or the any others here that think in
> that
> way. I can help or support in the way I can, but maybe limited in some
> way.
> And of course, we should all know that new optimizations to build
> systems
> can't be stopped to defend a concrete way to release. IOW, release is a
> process to "publish for other", and we can't block progress in the
> project
> or in the way we build to support a concrete way of release.
>
> just my 2
>
> Carlos
>
>
>
>
>
> El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>)
> escribió:
>
> > +1
> >
> > Harbs
> >
> > > On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID>
> > wrote:
> > >
> > > I’m sorry, but these repeated attempts to try to use Maven too
> much just
> > make me very upset. This was a concern of mine when two people who
> have
> > never produced a release went off to refactor the process. There is
> theory
> > and reality. The reality is that Maven cannot and should not be
> used to
> > streamline our release process because:
> > >
> > > - We've learned over the years that RMs have trouble getting set up
> > correctly.
> > > - We've learned over the years that RMs have trouble uploading
> Maven
> > artifacts to repository.a.o.
> > > - We should know that the only way to validate the Ant Task in the
> > release artifacts is to use Ant to verify it.
> > >
> > > Those are the three main reasons there are multiple release steps
> on the
> > CI server. I am hopeful that the new Maven builds can cut down on
> one or
> > two steps, or maybe just make those steps more straightforward, but
> the
> > process simply cannot just run Maven's release steps on the RM's
> local
> > computer. It must run on the CI server, and that requires stopping
> from
> > time to time to verify and sign stuff.
> > >
> > > A fourth reason was that the Ant script had proven to be able to
> build
> > an IDE-compatible artifact. I am not 100% convinced that the Maven
> > distribution build can exactly replicate that artifact. But again,
> if an
> > Ant user wants to use Ant to create artifacts for some IDE to test
> local
> > changes, then we need to prove in each release that Ant can produce
> that
> > set of artifacts for the IDE. So now that Maven can supposedly do
> the
> > same, it actually adds more work to the verification process. The
> Maven
> > artifacts for an IDE will need to be compared against the
> Ant-produced
> > artifacts for an IDE.
> > >
> > > In short, we should use Maven to produce Maven artifacts, and Ant
> to
> > produce Ant artifacts so that the RM is verifying the artifacts long
> before
> > the voters have to. And make it all work on a CI server so that
> RM's don't
> > have to deal with system setup, and not have upload issues blow up
> the
> > process.
> > >
> > > I also am not a fan of using Maven to do scripting, especially if
> it
> > involves custom mojos/plugins. That's what scripting tools like Ant
> are
> > for. The goal should be to make the release system maintainable by
> > everyone, not just by experts in Maven. Similarly, the Ant steps do
> not
> > use custom plugins/tasks for the same reason.
> > >
> > > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> > artifacts and sequence the steps. Use the CI server. Verify and
> sign
> > locally. These are the requirements. It was all working and we
> could have
> > released every month. I think it is your responsibility to make it
> work
> > again within those constraints.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org
> <mailto:
> > carlosrovira@apache.org>> wrote:
> > >
> > > Hi
> > >
> > > this morning in the slack Apache Royale official channel Chris
> Dutz
> > asked
> > > about plans for release 0.9.7. If you see Greg and I help him to
> > create an
> > > Apache Royale interface for pulling data from a Consumer in an
> IoT
> > Apache
> > > PLC4X app. Something very cool :). He published a tweet with a
> video
> > > showing it.
> > >
> > > So regarding the release, I explain that I spent many days some
> > months ago
> > > trying to fix the CI release steps to release, but I was unable
> to do
> > it. I
> > > think making changes to the Maven o Ant make the 13 steps very
> > fragile and
> > > difficult to fix. And we need to evolve continually Maven and
> Ant, so
> > that
> > > means a huge task that will require an huge amount of time that
> almost
> > > nobody here has. So I must say that although the work done on
> that
> > front
> > > was amazing and huge maybe we need to streamline it to an
> standard. I
> > know
> > > is difficult, but although we had many expectations put on the
> 13 step
> > > release process, after try it seems that we finally are not
> getting
> > what we
> > > wanted, that is streamline the release process.
> > >
> > > This is one of the critical points that hold us to release 1.0,
> since
> > not
> > > having an easy way to release means as we push 1.0 and people
> tries
> > us,
> > > we'll need to be faster on releasing, and we can't wait 6 month
> or a
> > year,
> > > since that we'll mean user will not want that kind of release
> cycle.
> > >
> > > So here is my proposal to work on a release process that allow
> us to
> > > release more often and more easily. Hope you all can consider
> it:
> > >
> > > First: We all know we want build with ANT and MAVEN. And when I
> refer
> > to
> > > "all" I really mean "all". Although I'm a Maven advocate, I
> really
> > > appreciate the point to have ANT on place so having 2 build
> systems
> > that
> > > completely works mean advantage. In fact although I use maven I
> build
> > with
> > > both system daily.
> > >
> > > Second: Build does not mean Release. I think other times we
> discussed
> > > Release as a way to impose Maven over Ant. Or maybe that was the
> > perception
> > > for others, but not my intention (and maybe not the intention of
> > others).
> > > But that's not the objective. Release [1] means to us just
> > "publication
> > > outside the development community, defined as individuals
> actively
> > > participating in development or following the dev list."
> > >
> > > That means that we don't need to release using Maven and Ant at
> the
> > same
> > > time, we can streamline greatly the process to just releasing
> with
> > Maven so
> > > we can ensure a simple process the same as any other Apache
> project.
> > >
> > > It means that people trying the release need to check it with
> Maven,
> > but
> > > community users can continue using ANT or Maven to build or
> even just
> > > download the SDK and use it on his IDE of choice and don't use
> ANT or
> > Maven
> > > at all.
> > >
> > > Third: The fact is the rest of projects I know all use releases
> and CI
> > > based on Maven, and that should point us that maybe we're
> trying to
> > > force something that is not standard in our industry, so if we
> want
> > to make
> > > it more reliable and easy process, is normal to embrace how
> others are
> > > doing, since that does not mean we're throwing away a build
> system,
> > since
> > > per previous point we don't want to remove ANT.
> > >
> > > Finally, Chris and I offer our time to make the easiest release
> > process we can
> > > that let all of us release easily and often (maybe each 1-2
> month?)
> > >
> > > Thanks
> > >
> > >
> > > [1]
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=PP%2Bq0O86F%2FguQtSIDzpGOa3CIM4qTiKmf%2FlmUVS7%2B%2Bo%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> > >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Alex Harui <ah...@adobe.com.INVALID>.
HI Carlos,
I only have one vote. But we've spent a lot of time on this issue already and the answer has always been the same: use Maven for Maven artifacts, use Ant for Ant artifacts. I would much rather you spend your energy on fixing what was a working release process. Of course it didn't work perfectly for Piotr at first because it is a complex process, but eventually it did work. If we did change to some new process that you want should we have the same strict criteria that if it doesn't work the first time it must therefore be no good? I'm sure you would not agree to that.
I don't know what you mean by "industrial", but I'm quite certain these days that we can't use the "expected" solution. This is a key point. You and Chris have not been through the release process so you don't know the kinds of issues that have to be resolved. I explained these issues in my earlier response. I used a much more "expected" solution for the first Royale releases and we found out that nobody else except me could use them. So we were forced to try this CI multi-step process and finally, we had someone be a successful RM other than me. So, any solution that might work for you and Chris that uses Maven in the "expected" way on your computer is likely to fail to work for other people. That's just our reality.
I do not recall seeing any questions about the CI steps since the new Maven build seemed to stabilize, so I don't understand why you chose to spend so much time on fixing them without asking a question on our lists. I will try to answer questions if you have them. The steps are pretty simple: Whatever steps you would normally run on the command-line to create a release are captured in these steps. At some point, the steps generate something that needs to be committed (like a branch, or updated poms) or signed, and so that Jenkins job ends so the RM can log into the CI server and commit the changes, then another step continues on until the next commit or signing is needed.
I will try to find time to understand how the Maven build now works, but I am going to try really hard not to be the person who goes and fixes these release steps. Not only did I not break them, but it would be better for others to understand more about how they work. There is certainly room for improvement in the steps, but fundamentally, we have to have a process where some shared computer with a known good configuration does some work, the RM then does a commit or sign, and so on.
There are no restrictions I can think of on what Maven can be tasked to do within a step, the only restriction occurs when something needs to be committed or signed. And we need reproducible binaries in order to validate the artifacts. Once you have local computer validation it makes sense to me to use Maven's Wagon to upload to repository.a.o instead of the Maven release plugin, but there might be a better way.
In the end, though, Maven will build the Maven artifacts and Ant will build the Ant artifacts. That way we validate as we build the artifacts.
My 2 cents,
-Alex
On 3/17/20, 12:50 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
I don't think you should be upset, don't think that to be a positive way to
discuss this task, since in that way you force a solution and maybe not all
of us think the same way as you. So although it could cause some tiring to
all of us (me included) I think we need to put all our effort to get to
some point where we all be satisfied.
This is probably the most problematic task we have in Royale, and since is
difficult to solve and seems there are at least two groups of people
thinking in different ways, we need to get what's the better way to solve
it. No one way of thinking is better that other you have valid points (but
in the same way I can find arguments against them), but don't think that is
a productive route. I want to spend our times in get a real solution.
The CI steps you did was a great effort and very appreciated. I was very
happy when you made it, since from outside it all sound very promising.
Then IIRC Piotr's release doesn't was as straight as expected. So I think
that was a point we should all take into account. Then my experience
updating maven and broken some steps was as well something from what we
should learn and think about it. I tried to fix them without exit. I still
want to improve Maven even more in the future. One of the problem I see is:
If we fix CI steps, will broke again when new changes in maven will be
done? probably...and will the fix as difficult as now? In my experience,
probably too.
Don't think as well that is good for this discussion impose a way to act.
I'll be fixing CI steps if I could, but I repeat that I tried during some
days without exit. Spend many hours over it. So is not something I'd not
do, is just that the process is very fragile and is not what I expect it
will bring to us. Each thing we change can break it and that's a huge
problem ahead. Or is just me the only one that see a huge problem on this?.
Instead, I can offer my work in fixing in other way that I think is more
"industrial" or proven, but you don't like it, due to the points you
express (that I repeat can be valid, but I see that all are totally
surmountable If we work in a more industrial way to solve it. Don't think
we are more special that other hundreds of projects out there, and all of
that projects just use maven for release.
Maven SDK could still not be 100%, that's right, but is one of the things
we need to fix in the actual process I offer. For sure. And releasing that
way, you still can build with ANT and check it was all right. We don't need
to do at the same time that releasing. I think that's a valid point.
I think that if you defend the CI steps in such fixed way, the rest of us
thinking that's not the way to go can just not oppose, but you can't ask us
to be responsible of trying to solve something that is very (very)
difficult to solve, since maybe we just can't do it. You must take into
account that new changes could come (to ant, to maven), and working that
way should be your responsibility or the any others here that think in that
way. I can help or support in the way I can, but maybe limited in some way.
And of course, we should all know that new optimizations to build systems
can't be stopped to defend a concrete way to release. IOW, release is a
process to "publish for other", and we can't block progress in the project
or in the way we build to support a concrete way of release.
just my 2
Carlos
El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>) escribió:
> +1
>
> Harbs
>
> > On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > I’m sorry, but these repeated attempts to try to use Maven too much just
> make me very upset. This was a concern of mine when two people who have
> never produced a release went off to refactor the process. There is theory
> and reality. The reality is that Maven cannot and should not be used to
> streamline our release process because:
> >
> > - We've learned over the years that RMs have trouble getting set up
> correctly.
> > - We've learned over the years that RMs have trouble uploading Maven
> artifacts to repository.a.o.
> > - We should know that the only way to validate the Ant Task in the
> release artifacts is to use Ant to verify it.
> >
> > Those are the three main reasons there are multiple release steps on the
> CI server. I am hopeful that the new Maven builds can cut down on one or
> two steps, or maybe just make those steps more straightforward, but the
> process simply cannot just run Maven's release steps on the RM's local
> computer. It must run on the CI server, and that requires stopping from
> time to time to verify and sign stuff.
> >
> > A fourth reason was that the Ant script had proven to be able to build
> an IDE-compatible artifact. I am not 100% convinced that the Maven
> distribution build can exactly replicate that artifact. But again, if an
> Ant user wants to use Ant to create artifacts for some IDE to test local
> changes, then we need to prove in each release that Ant can produce that
> set of artifacts for the IDE. So now that Maven can supposedly do the
> same, it actually adds more work to the verification process. The Maven
> artifacts for an IDE will need to be compared against the Ant-produced
> artifacts for an IDE.
> >
> > In short, we should use Maven to produce Maven artifacts, and Ant to
> produce Ant artifacts so that the RM is verifying the artifacts long before
> the voters have to. And make it all work on a CI server so that RM's don't
> have to deal with system setup, and not have upload issues blow up the
> process.
> >
> > I also am not a fan of using Maven to do scripting, especially if it
> involves custom mojos/plugins. That's what scripting tools like Ant are
> for. The goal should be to make the release system maintainable by
> everyone, not just by experts in Maven. Similarly, the Ant steps do not
> use custom plugins/tasks for the same reason.
> >
> > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> artifacts and sequence the steps. Use the CI server. Verify and sign
> locally. These are the requirements. It was all working and we could have
> released every month. I think it is your responsibility to make it work
> again within those constraints.
> >
> > My 2 cents,
> > -Alex
> >
> > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org <mailto:
> carlosrovira@apache.org>> wrote:
> >
> > Hi
> >
> > this morning in the slack Apache Royale official channel Chris Dutz
> asked
> > about plans for release 0.9.7. If you see Greg and I help him to
> create an
> > Apache Royale interface for pulling data from a Consumer in an IoT
> Apache
> > PLC4X app. Something very cool :). He published a tweet with a video
> > showing it.
> >
> > So regarding the release, I explain that I spent many days some
> months ago
> > trying to fix the CI release steps to release, but I was unable to do
> it. I
> > think making changes to the Maven o Ant make the 13 steps very
> fragile and
> > difficult to fix. And we need to evolve continually Maven and Ant, so
> that
> > means a huge task that will require an huge amount of time that almost
> > nobody here has. So I must say that although the work done on that
> front
> > was amazing and huge maybe we need to streamline it to an standard. I
> know
> > is difficult, but although we had many expectations put on the 13 step
> > release process, after try it seems that we finally are not getting
> what we
> > wanted, that is streamline the release process.
> >
> > This is one of the critical points that hold us to release 1.0, since
> not
> > having an easy way to release means as we push 1.0 and people tries
> us,
> > we'll need to be faster on releasing, and we can't wait 6 month or a
> year,
> > since that we'll mean user will not want that kind of release cycle.
> >
> > So here is my proposal to work on a release process that allow us to
> > release more often and more easily. Hope you all can consider it:
> >
> > First: We all know we want build with ANT and MAVEN. And when I refer
> to
> > "all" I really mean "all". Although I'm a Maven advocate, I really
> > appreciate the point to have ANT on place so having 2 build systems
> that
> > completely works mean advantage. In fact although I use maven I build
> with
> > both system daily.
> >
> > Second: Build does not mean Release. I think other times we discussed
> > Release as a way to impose Maven over Ant. Or maybe that was the
> perception
> > for others, but not my intention (and maybe not the intention of
> others).
> > But that's not the objective. Release [1] means to us just
> "publication
> > outside the development community, defined as individuals actively
> > participating in development or following the dev list."
> >
> > That means that we don't need to release using Maven and Ant at the
> same
> > time, we can streamline greatly the process to just releasing with
> Maven so
> > we can ensure a simple process the same as any other Apache project.
> >
> > It means that people trying the release need to check it with Maven,
> but
> > community users can continue using ANT or Maven to build or even just
> > download the SDK and use it on his IDE of choice and don't use ANT or
> Maven
> > at all.
> >
> > Third: The fact is the rest of projects I know all use releases and CI
> > based on Maven, and that should point us that maybe we're trying to
> > force something that is not standard in our industry, so if we want
> to make
> > it more reliable and easy process, is normal to embrace how others are
> > doing, since that does not mean we're throwing away a build system,
> since
> > per previous point we don't want to remove ANT.
> >
> > Finally, Chris and I offer our time to make the easiest release
> process we can
> > that let all of us release easily and often (maybe each 1-2 month?)
> >
> > Thanks
> >
> >
> > [1]
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=49KtjLtJDXsCKMMrIEr2W7zEt5L%2FTNk6Rtvl9pgpBBo%3D&reserved=0
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153362334&sdata=PP%2Bq0O86F%2FguQtSIDzpGOa3CIM4qTiKmf%2FlmUVS7%2B%2Bo%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
> >
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C525c830261c347c9dc8d08d7caac68a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200714153372330&sdata=t0BWYYpiCDSPpjPtrRG7mfM%2F%2Bodl0zf4a3j%2B591gFJA%3D&reserved=0
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I don't think you should be upset, don't think that to be a positive way to
discuss this task, since in that way you force a solution and maybe not all
of us think the same way as you. So although it could cause some tiring to
all of us (me included) I think we need to put all our effort to get to
some point where we all be satisfied.
This is probably the most problematic task we have in Royale, and since is
difficult to solve and seems there are at least two groups of people
thinking in different ways, we need to get what's the better way to solve
it. No one way of thinking is better that other you have valid points (but
in the same way I can find arguments against them), but don't think that is
a productive route. I want to spend our times in get a real solution.
The CI steps you did was a great effort and very appreciated. I was very
happy when you made it, since from outside it all sound very promising.
Then IIRC Piotr's release doesn't was as straight as expected. So I think
that was a point we should all take into account. Then my experience
updating maven and broken some steps was as well something from what we
should learn and think about it. I tried to fix them without exit. I still
want to improve Maven even more in the future. One of the problem I see is:
If we fix CI steps, will broke again when new changes in maven will be
done? probably...and will the fix as difficult as now? In my experience,
probably too.
Don't think as well that is good for this discussion impose a way to act.
I'll be fixing CI steps if I could, but I repeat that I tried during some
days without exit. Spend many hours over it. So is not something I'd not
do, is just that the process is very fragile and is not what I expect it
will bring to us. Each thing we change can break it and that's a huge
problem ahead. Or is just me the only one that see a huge problem on this?.
Instead, I can offer my work in fixing in other way that I think is more
"industrial" or proven, but you don't like it, due to the points you
express (that I repeat can be valid, but I see that all are totally
surmountable If we work in a more industrial way to solve it. Don't think
we are more special that other hundreds of projects out there, and all of
that projects just use maven for release.
Maven SDK could still not be 100%, that's right, but is one of the things
we need to fix in the actual process I offer. For sure. And releasing that
way, you still can build with ANT and check it was all right. We don't need
to do at the same time that releasing. I think that's a valid point.
I think that if you defend the CI steps in such fixed way, the rest of us
thinking that's not the way to go can just not oppose, but you can't ask us
to be responsible of trying to solve something that is very (very)
difficult to solve, since maybe we just can't do it. You must take into
account that new changes could come (to ant, to maven), and working that
way should be your responsibility or the any others here that think in that
way. I can help or support in the way I can, but maybe limited in some way.
And of course, we should all know that new optimizations to build systems
can't be stopped to defend a concrete way to release. IOW, release is a
process to "publish for other", and we can't block progress in the project
or in the way we build to support a concrete way of release.
just my 2
Carlos
El mar., 17 mar. 2020 a las 19:50, Harbs (<ha...@gmail.com>) escribió:
> +1
>
> Harbs
>
> > On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > I’m sorry, but these repeated attempts to try to use Maven too much just
> make me very upset. This was a concern of mine when two people who have
> never produced a release went off to refactor the process. There is theory
> and reality. The reality is that Maven cannot and should not be used to
> streamline our release process because:
> >
> > - We've learned over the years that RMs have trouble getting set up
> correctly.
> > - We've learned over the years that RMs have trouble uploading Maven
> artifacts to repository.a.o.
> > - We should know that the only way to validate the Ant Task in the
> release artifacts is to use Ant to verify it.
> >
> > Those are the three main reasons there are multiple release steps on the
> CI server. I am hopeful that the new Maven builds can cut down on one or
> two steps, or maybe just make those steps more straightforward, but the
> process simply cannot just run Maven's release steps on the RM's local
> computer. It must run on the CI server, and that requires stopping from
> time to time to verify and sign stuff.
> >
> > A fourth reason was that the Ant script had proven to be able to build
> an IDE-compatible artifact. I am not 100% convinced that the Maven
> distribution build can exactly replicate that artifact. But again, if an
> Ant user wants to use Ant to create artifacts for some IDE to test local
> changes, then we need to prove in each release that Ant can produce that
> set of artifacts for the IDE. So now that Maven can supposedly do the
> same, it actually adds more work to the verification process. The Maven
> artifacts for an IDE will need to be compared against the Ant-produced
> artifacts for an IDE.
> >
> > In short, we should use Maven to produce Maven artifacts, and Ant to
> produce Ant artifacts so that the RM is verifying the artifacts long before
> the voters have to. And make it all work on a CI server so that RM's don't
> have to deal with system setup, and not have upload issues blow up the
> process.
> >
> > I also am not a fan of using Maven to do scripting, especially if it
> involves custom mojos/plugins. That's what scripting tools like Ant are
> for. The goal should be to make the release system maintainable by
> everyone, not just by experts in Maven. Similarly, the Ant steps do not
> use custom plugins/tasks for the same reason.
> >
> > Use Maven to build the Maven artifacts. Use Ant to build the Ant
> artifacts and sequence the steps. Use the CI server. Verify and sign
> locally. These are the requirements. It was all working and we could have
> released every month. I think it is your responsibility to make it work
> again within those constraints.
> >
> > My 2 cents,
> > -Alex
> >
> > On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org <mailto:
> carlosrovira@apache.org>> wrote:
> >
> > Hi
> >
> > this morning in the slack Apache Royale official channel Chris Dutz
> asked
> > about plans for release 0.9.7. If you see Greg and I help him to
> create an
> > Apache Royale interface for pulling data from a Consumer in an IoT
> Apache
> > PLC4X app. Something very cool :). He published a tweet with a video
> > showing it.
> >
> > So regarding the release, I explain that I spent many days some
> months ago
> > trying to fix the CI release steps to release, but I was unable to do
> it. I
> > think making changes to the Maven o Ant make the 13 steps very
> fragile and
> > difficult to fix. And we need to evolve continually Maven and Ant, so
> that
> > means a huge task that will require an huge amount of time that almost
> > nobody here has. So I must say that although the work done on that
> front
> > was amazing and huge maybe we need to streamline it to an standard. I
> know
> > is difficult, but although we had many expectations put on the 13 step
> > release process, after try it seems that we finally are not getting
> what we
> > wanted, that is streamline the release process.
> >
> > This is one of the critical points that hold us to release 1.0, since
> not
> > having an easy way to release means as we push 1.0 and people tries
> us,
> > we'll need to be faster on releasing, and we can't wait 6 month or a
> year,
> > since that we'll mean user will not want that kind of release cycle.
> >
> > So here is my proposal to work on a release process that allow us to
> > release more often and more easily. Hope you all can consider it:
> >
> > First: We all know we want build with ANT and MAVEN. And when I refer
> to
> > "all" I really mean "all". Although I'm a Maven advocate, I really
> > appreciate the point to have ANT on place so having 2 build systems
> that
> > completely works mean advantage. In fact although I use maven I build
> with
> > both system daily.
> >
> > Second: Build does not mean Release. I think other times we discussed
> > Release as a way to impose Maven over Ant. Or maybe that was the
> perception
> > for others, but not my intention (and maybe not the intention of
> others).
> > But that's not the objective. Release [1] means to us just
> "publication
> > outside the development community, defined as individuals actively
> > participating in development or following the dev list."
> >
> > That means that we don't need to release using Maven and Ant at the
> same
> > time, we can streamline greatly the process to just releasing with
> Maven so
> > we can ensure a simple process the same as any other Apache project.
> >
> > It means that people trying the release need to check it with Maven,
> but
> > community users can continue using ANT or Maven to build or even just
> > download the SDK and use it on his IDE of choice and don't use ANT or
> Maven
> > at all.
> >
> > Third: The fact is the rest of projects I know all use releases and CI
> > based on Maven, and that should point us that maybe we're trying to
> > force something that is not standard in our industry, so if we want
> to make
> > it more reliable and easy process, is normal to embrace how others are
> > doing, since that does not mean we're throwing away a build system,
> since
> > per previous point we don't want to remove ANT.
> >
> > Finally, Chris and I offer our time to make the easiest release
> process we can
> > that let all of us release easily and often (maybe each 1-2 month?)
> >
> > Thanks
> >
> >
> > [1]
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Harbs <ha...@gmail.com>.
+1
Harbs
> On Mar 17, 2020, at 8:10 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I’m sorry, but these repeated attempts to try to use Maven too much just make me very upset. This was a concern of mine when two people who have never produced a release went off to refactor the process. There is theory and reality. The reality is that Maven cannot and should not be used to streamline our release process because:
>
> - We've learned over the years that RMs have trouble getting set up correctly.
> - We've learned over the years that RMs have trouble uploading Maven artifacts to repository.a.o.
> - We should know that the only way to validate the Ant Task in the release artifacts is to use Ant to verify it.
>
> Those are the three main reasons there are multiple release steps on the CI server. I am hopeful that the new Maven builds can cut down on one or two steps, or maybe just make those steps more straightforward, but the process simply cannot just run Maven's release steps on the RM's local computer. It must run on the CI server, and that requires stopping from time to time to verify and sign stuff.
>
> A fourth reason was that the Ant script had proven to be able to build an IDE-compatible artifact. I am not 100% convinced that the Maven distribution build can exactly replicate that artifact. But again, if an Ant user wants to use Ant to create artifacts for some IDE to test local changes, then we need to prove in each release that Ant can produce that set of artifacts for the IDE. So now that Maven can supposedly do the same, it actually adds more work to the verification process. The Maven artifacts for an IDE will need to be compared against the Ant-produced artifacts for an IDE.
>
> In short, we should use Maven to produce Maven artifacts, and Ant to produce Ant artifacts so that the RM is verifying the artifacts long before the voters have to. And make it all work on a CI server so that RM's don't have to deal with system setup, and not have upload issues blow up the process.
>
> I also am not a fan of using Maven to do scripting, especially if it involves custom mojos/plugins. That's what scripting tools like Ant are for. The goal should be to make the release system maintainable by everyone, not just by experts in Maven. Similarly, the Ant steps do not use custom plugins/tasks for the same reason.
>
> Use Maven to build the Maven artifacts. Use Ant to build the Ant artifacts and sequence the steps. Use the CI server. Verify and sign locally. These are the requirements. It was all working and we could have released every month. I think it is your responsibility to make it work again within those constraints.
>
> My 2 cents,
> -Alex
>
> On 3/17/20, 8:48 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>
> Hi
>
> this morning in the slack Apache Royale official channel Chris Dutz asked
> about plans for release 0.9.7. If you see Greg and I help him to create an
> Apache Royale interface for pulling data from a Consumer in an IoT Apache
> PLC4X app. Something very cool :). He published a tweet with a video
> showing it.
>
> So regarding the release, I explain that I spent many days some months ago
> trying to fix the CI release steps to release, but I was unable to do it. I
> think making changes to the Maven o Ant make the 13 steps very fragile and
> difficult to fix. And we need to evolve continually Maven and Ant, so that
> means a huge task that will require an huge amount of time that almost
> nobody here has. So I must say that although the work done on that front
> was amazing and huge maybe we need to streamline it to an standard. I know
> is difficult, but although we had many expectations put on the 13 step
> release process, after try it seems that we finally are not getting what we
> wanted, that is streamline the release process.
>
> This is one of the critical points that hold us to release 1.0, since not
> having an easy way to release means as we push 1.0 and people tries us,
> we'll need to be faster on releasing, and we can't wait 6 month or a year,
> since that we'll mean user will not want that kind of release cycle.
>
> So here is my proposal to work on a release process that allow us to
> release more often and more easily. Hope you all can consider it:
>
> First: We all know we want build with ANT and MAVEN. And when I refer to
> "all" I really mean "all". Although I'm a Maven advocate, I really
> appreciate the point to have ANT on place so having 2 build systems that
> completely works mean advantage. In fact although I use maven I build with
> both system daily.
>
> Second: Build does not mean Release. I think other times we discussed
> Release as a way to impose Maven over Ant. Or maybe that was the perception
> for others, but not my intention (and maybe not the intention of others).
> But that's not the objective. Release [1] means to us just "publication
> outside the development community, defined as individuals actively
> participating in development or following the dev list."
>
> That means that we don't need to release using Maven and Ant at the same
> time, we can streamline greatly the process to just releasing with Maven so
> we can ensure a simple process the same as any other Apache project.
>
> It means that people trying the release need to check it with Maven, but
> community users can continue using ANT or Maven to build or even just
> download the SDK and use it on his IDE of choice and don't use ANT or Maven
> at all.
>
> Third: The fact is the rest of projects I know all use releases and CI
> based on Maven, and that should point us that maybe we're trying to
> force something that is not standard in our industry, so if we want to make
> it more reliable and easy process, is normal to embrace how others are
> doing, since that does not mean we're throwing away a build system, since
> per previous point we don't want to remove ANT.
>
> Finally, Chris and I offer our time to make the easiest release process we can
> that let all of us release easily and often (maybe each 1-2 month?)
>
> Thanks
>
>
> [1] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0>
Re: About release 0.9.7 and how to fix and streamline the process
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I’m sorry, but these repeated attempts to try to use Maven too much just make me very upset. This was a concern of mine when two people who have never produced a release went off to refactor the process. There is theory and reality. The reality is that Maven cannot and should not be used to streamline our release process because:
- We've learned over the years that RMs have trouble getting set up correctly.
- We've learned over the years that RMs have trouble uploading Maven artifacts to repository.a.o.
- We should know that the only way to validate the Ant Task in the release artifacts is to use Ant to verify it.
Those are the three main reasons there are multiple release steps on the CI server. I am hopeful that the new Maven builds can cut down on one or two steps, or maybe just make those steps more straightforward, but the process simply cannot just run Maven's release steps on the RM's local computer. It must run on the CI server, and that requires stopping from time to time to verify and sign stuff.
A fourth reason was that the Ant script had proven to be able to build an IDE-compatible artifact. I am not 100% convinced that the Maven distribution build can exactly replicate that artifact. But again, if an Ant user wants to use Ant to create artifacts for some IDE to test local changes, then we need to prove in each release that Ant can produce that set of artifacts for the IDE. So now that Maven can supposedly do the same, it actually adds more work to the verification process. The Maven artifacts for an IDE will need to be compared against the Ant-produced artifacts for an IDE.
In short, we should use Maven to produce Maven artifacts, and Ant to produce Ant artifacts so that the RM is verifying the artifacts long before the voters have to. And make it all work on a CI server so that RM's don't have to deal with system setup, and not have upload issues blow up the process.
I also am not a fan of using Maven to do scripting, especially if it involves custom mojos/plugins. That's what scripting tools like Ant are for. The goal should be to make the release system maintainable by everyone, not just by experts in Maven. Similarly, the Ant steps do not use custom plugins/tasks for the same reason.
Use Maven to build the Maven artifacts. Use Ant to build the Ant artifacts and sequence the steps. Use the CI server. Verify and sign locally. These are the requirements. It was all working and we could have released every month. I think it is your responsibility to make it work again within those constraints.
My 2 cents,
-Alex
On 3/17/20, 8:48 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi
this morning in the slack Apache Royale official channel Chris Dutz asked
about plans for release 0.9.7. If you see Greg and I help him to create an
Apache Royale interface for pulling data from a Consumer in an IoT Apache
PLC4X app. Something very cool :). He published a tweet with a video
showing it.
So regarding the release, I explain that I spent many days some months ago
trying to fix the CI release steps to release, but I was unable to do it. I
think making changes to the Maven o Ant make the 13 steps very fragile and
difficult to fix. And we need to evolve continually Maven and Ant, so that
means a huge task that will require an huge amount of time that almost
nobody here has. So I must say that although the work done on that front
was amazing and huge maybe we need to streamline it to an standard. I know
is difficult, but although we had many expectations put on the 13 step
release process, after try it seems that we finally are not getting what we
wanted, that is streamline the release process.
This is one of the critical points that hold us to release 1.0, since not
having an easy way to release means as we push 1.0 and people tries us,
we'll need to be faster on releasing, and we can't wait 6 month or a year,
since that we'll mean user will not want that kind of release cycle.
So here is my proposal to work on a release process that allow us to
release more often and more easily. Hope you all can consider it:
First: We all know we want build with ANT and MAVEN. And when I refer to
"all" I really mean "all". Although I'm a Maven advocate, I really
appreciate the point to have ANT on place so having 2 build systems that
completely works mean advantage. In fact although I use maven I build with
both system daily.
Second: Build does not mean Release. I think other times we discussed
Release as a way to impose Maven over Ant. Or maybe that was the perception
for others, but not my intention (and maybe not the intention of others).
But that's not the objective. Release [1] means to us just "publication
outside the development community, defined as individuals actively
participating in development or following the dev list."
That means that we don't need to release using Maven and Ant at the same
time, we can streamline greatly the process to just releasing with Maven so
we can ensure a simple process the same as any other Apache project.
It means that people trying the release need to check it with Maven, but
community users can continue using ANT or Maven to build or even just
download the SDK and use it on his IDE of choice and don't use ANT or Maven
at all.
Third: The fact is the rest of projects I know all use releases and CI
based on Maven, and that should point us that maybe we're trying to
force something that is not standard in our industry, so if we want to make
it more reliable and easy process, is normal to embrace how others are
doing, since that does not mean we're throwing away a build system, since
per previous point we don't want to remove ANT.
Finally, Chris and I offer our time to make the easiest release process we can
that let all of us release easily and often (maybe each 1-2 month?)
Thanks
[1] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0