Cutting a release for Surefire?

[Enrico Olivelli <eo...@gmail.com>]

What about cutting a release for Surefire plugin?
We already fixed important problems that are on 3.0.0-M5 and I saw that
current master branch works well.

Thoughts?
Volunteers?

Enrico

Re: Cutting a release for Surefire?

[Olivier Lamy <ol...@apache.org>]

Agree
+1 let's release another milestone as said it's only milestones

On Sun, 4 Apr 2021 at 01:32, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> +1 to release, last milestones have blockers master fixes
>
> Le sam. 3 avr. 2021 à 13:59, Enrico Olivelli <eo...@gmail.com> a
> écrit :
>
> > Tibor
> >
> > Il Sab 3 Apr 2021, 12:32 Tibor Digana <ti...@apache.org> ha
> scritto:
> >
> > > It is only a milestone version which means a work in progress. The
> fixes
> > > made so far are really minor, no need to make any release.
> > >
> >
> > Got it thanks.
> >
> > Latest release 3.0.0-M5 has some weird behaviour that makes it impossible
> > to upgrade from 3.0.0-M4 but I saw that current master works well.
> >
> > I am sorry I don't have time to contribute code patches to surefire
> during
> > this period (no need to explain) but I am actively following the project
> > and I see that all of the patches that went in since 3.0.0-M5 only
> enhance
> > surefire and did not introduce instability.
> >
> > I can help with bureaucratic stuff and I can take care of ensuring that
> > what we release to the public is in good shape with responsibility.
> >
> > That said, upgrading to 3.0.0M5 is not important to me.
> >
> > I can wait.
> >
> > Thanks for sharing your opinion
> >
> > Cheers
> > Enrico
> >
> >
> > If you take a look at the road map, you will see that I do not need to
> fix
> > > tiny issues, I need to rework the additional attributes which will
> > transfer
> > > events about tests. There are testId and RunOrder. Without them the
> > BIGGER
> > > fixes, than the ones you are aiming for, would not be possible, e.g.
> > better
> > > xml marshaller, logs from parallel tests and re-run which is currently
> > > unstable due to it relies on the order of test run. The next thing
> which
> > > seems to be easier and also necessary is the execution of UUID and
> Script
> > > which is needed by Cucumber and junit5.
> > > The sad thing is that mostly common users participate and they become
> > > committers. Our official committers do not. So Enrico, pls participate
> in
> > > coding because many of us like performing releases but there are only
> few
> > > hard workers. Making a release is easy but taking the responsibility
> for
> > > the binaries in the world is much harder. So, pls participate in
> > > Stackoverflow like Karl does and me, participate in coding and then we
> > can
> > > talk about taking a benefit from a release.
> > >
> > > Yeah, one more very important thing. We introduced TCP connector for
> > making
> > > the above plan possible. The user found that the TCP feature hangs
> > somehow,
> > > see https://issues.apache.org/jira/browse/SUREFIRE-1881. It took me
> > > several
> > > months to understand the rootcase. It has nothing to do with TCP
> itself,
> > > nothing but process pipes which are full of bytes before the tcp makes
> > > handshaking. Releasing the work in the middle and unstable is silly.
> You
> > > know when I found the root cause? It was at 1:30 early in the morning.
> > > Again pls come to work and spend less time in discussions, let;s work
> in
> > > PRs on GitHub and we will have a chance to make releases earlier.
> > > I am sorry that I am a bad guy, but I asked Enrico several times to
> work
> > in
> > > this OSS as well. I know Enrico that you participate in another OSSes
> too
> > > but you have to decide, since the day has only 24 hours, how much you
> > will
> > > do and what you will do, but sorry making a release without working on
> it
> > > is not adequate.
> > >
> > > T
> > >
> > > On Sat, Apr 3, 2021 at 11:08 AM Enrico Olivelli <eo...@gmail.com>
> > > wrote:
> > >
> > > > What about cutting a release for Surefire plugin?
> > > > We already fixed important problems that are on 3.0.0-M5 and I saw
> that
> > > > current master branch works well.
> > > >
> > > > Thoughts?
> > > > Volunteers?
> > > >
> > > > Enrico
> > > >
> > >
> >
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Cutting a release for Surefire?

[Romain Manni-Bucau <rm...@gmail.com>]

+1 to release, last milestones have blockers master fixes

Le sam. 3 avr. 2021 à 13:59, Enrico Olivelli <eo...@gmail.com> a écrit :

> Tibor
>
> Il Sab 3 Apr 2021, 12:32 Tibor Digana <ti...@apache.org> ha scritto:
>
> > It is only a milestone version which means a work in progress. The fixes
> > made so far are really minor, no need to make any release.
> >
>
> Got it thanks.
>
> Latest release 3.0.0-M5 has some weird behaviour that makes it impossible
> to upgrade from 3.0.0-M4 but I saw that current master works well.
>
> I am sorry I don't have time to contribute code patches to surefire during
> this period (no need to explain) but I am actively following the project
> and I see that all of the patches that went in since 3.0.0-M5 only enhance
> surefire and did not introduce instability.
>
> I can help with bureaucratic stuff and I can take care of ensuring that
> what we release to the public is in good shape with responsibility.
>
> That said, upgrading to 3.0.0M5 is not important to me.
>
> I can wait.
>
> Thanks for sharing your opinion
>
> Cheers
> Enrico
>
>
> If you take a look at the road map, you will see that I do not need to fix
> > tiny issues, I need to rework the additional attributes which will
> transfer
> > events about tests. There are testId and RunOrder. Without them the
> BIGGER
> > fixes, than the ones you are aiming for, would not be possible, e.g.
> better
> > xml marshaller, logs from parallel tests and re-run which is currently
> > unstable due to it relies on the order of test run. The next thing which
> > seems to be easier and also necessary is the execution of UUID and Script
> > which is needed by Cucumber and junit5.
> > The sad thing is that mostly common users participate and they become
> > committers. Our official committers do not. So Enrico, pls participate in
> > coding because many of us like performing releases but there are only few
> > hard workers. Making a release is easy but taking the responsibility for
> > the binaries in the world is much harder. So, pls participate in
> > Stackoverflow like Karl does and me, participate in coding and then we
> can
> > talk about taking a benefit from a release.
> >
> > Yeah, one more very important thing. We introduced TCP connector for
> making
> > the above plan possible. The user found that the TCP feature hangs
> somehow,
> > see https://issues.apache.org/jira/browse/SUREFIRE-1881. It took me
> > several
> > months to understand the rootcase. It has nothing to do with TCP itself,
> > nothing but process pipes which are full of bytes before the tcp makes
> > handshaking. Releasing the work in the middle and unstable is silly. You
> > know when I found the root cause? It was at 1:30 early in the morning.
> > Again pls come to work and spend less time in discussions, let;s work in
> > PRs on GitHub and we will have a chance to make releases earlier.
> > I am sorry that I am a bad guy, but I asked Enrico several times to work
> in
> > this OSS as well. I know Enrico that you participate in another OSSes too
> > but you have to decide, since the day has only 24 hours, how much you
> will
> > do and what you will do, but sorry making a release without working on it
> > is not adequate.
> >
> > T
> >
> > On Sat, Apr 3, 2021 at 11:08 AM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > What about cutting a release for Surefire plugin?
> > > We already fixed important problems that are on 3.0.0-M5 and I saw that
> > > current master branch works well.
> > >
> > > Thoughts?
> > > Volunteers?
> > >
> > > Enrico
> > >
> >
>

Re: Cutting a release for Surefire?

[Enrico Olivelli <eo...@gmail.com>]

Tibor

Il Sab 3 Apr 2021, 12:32 Tibor Digana <ti...@apache.org> ha scritto:

> It is only a milestone version which means a work in progress. The fixes
> made so far are really minor, no need to make any release.
>

Got it thanks.

Latest release 3.0.0-M5 has some weird behaviour that makes it impossible
to upgrade from 3.0.0-M4 but I saw that current master works well.

I am sorry I don't have time to contribute code patches to surefire during
this period (no need to explain) but I am actively following the project
and I see that all of the patches that went in since 3.0.0-M5 only enhance
surefire and did not introduce instability.

I can help with bureaucratic stuff and I can take care of ensuring that
what we release to the public is in good shape with responsibility.

That said, upgrading to 3.0.0M5 is not important to me.

I can wait.

Thanks for sharing your opinion

Cheers
Enrico


If you take a look at the road map, you will see that I do not need to fix
> tiny issues, I need to rework the additional attributes which will transfer
> events about tests. There are testId and RunOrder. Without them the BIGGER
> fixes, than the ones you are aiming for, would not be possible, e.g. better
> xml marshaller, logs from parallel tests and re-run which is currently
> unstable due to it relies on the order of test run. The next thing which
> seems to be easier and also necessary is the execution of UUID and Script
> which is needed by Cucumber and junit5.
> The sad thing is that mostly common users participate and they become
> committers. Our official committers do not. So Enrico, pls participate in
> coding because many of us like performing releases but there are only few
> hard workers. Making a release is easy but taking the responsibility for
> the binaries in the world is much harder. So, pls participate in
> Stackoverflow like Karl does and me, participate in coding and then we can
> talk about taking a benefit from a release.
>
> Yeah, one more very important thing. We introduced TCP connector for making
> the above plan possible. The user found that the TCP feature hangs somehow,
> see https://issues.apache.org/jira/browse/SUREFIRE-1881. It took me
> several
> months to understand the rootcase. It has nothing to do with TCP itself,
> nothing but process pipes which are full of bytes before the tcp makes
> handshaking. Releasing the work in the middle and unstable is silly. You
> know when I found the root cause? It was at 1:30 early in the morning.
> Again pls come to work and spend less time in discussions, let;s work in
> PRs on GitHub and we will have a chance to make releases earlier.
> I am sorry that I am a bad guy, but I asked Enrico several times to work in
> this OSS as well. I know Enrico that you participate in another OSSes too
> but you have to decide, since the day has only 24 hours, how much you will
> do and what you will do, but sorry making a release without working on it
> is not adequate.
>
> T
>
> On Sat, Apr 3, 2021 at 11:08 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > What about cutting a release for Surefire plugin?
> > We already fixed important problems that are on 3.0.0-M5 and I saw that
> > current master branch works well.
> >
> > Thoughts?
> > Volunteers?
> >
> > Enrico
> >
>

Re: Cutting a release for Surefire?

[Tibor Digana <ti...@apache.org>]

It is only a milestone version which means a work in progress. The fixes
made so far are really minor, no need to make any release.
If you take a look at the road map, you will see that I do not need to fix
tiny issues, I need to rework the additional attributes which will transfer
events about tests. There are testId and RunOrder. Without them the BIGGER
fixes, than the ones you are aiming for, would not be possible, e.g. better
xml marshaller, logs from parallel tests and re-run which is currently
unstable due to it relies on the order of test run. The next thing which
seems to be easier and also necessary is the execution of UUID and Script
which is needed by Cucumber and junit5.
The sad thing is that mostly common users participate and they become
committers. Our official committers do not. So Enrico, pls participate in
coding because many of us like performing releases but there are only few
hard workers. Making a release is easy but taking the responsibility for
the binaries in the world is much harder. So, pls participate in
Stackoverflow like Karl does and me, participate in coding and then we can
talk about taking a benefit from a release.

Yeah, one more very important thing. We introduced TCP connector for making
the above plan possible. The user found that the TCP feature hangs somehow,
see https://issues.apache.org/jira/browse/SUREFIRE-1881. It took me several
months to understand the rootcase. It has nothing to do with TCP itself,
nothing but process pipes which are full of bytes before the tcp makes
handshaking. Releasing the work in the middle and unstable is silly. You
know when I found the root cause? It was at 1:30 early in the morning.
Again pls come to work and spend less time in discussions, let;s work in
PRs on GitHub and we will have a chance to make releases earlier.
I am sorry that I am a bad guy, but I asked Enrico several times to work in
this OSS as well. I know Enrico that you participate in another OSSes too
but you have to decide, since the day has only 24 hours, how much you will
do and what you will do, but sorry making a release without working on it
is not adequate.

T

On Sat, Apr 3, 2021 at 11:08 AM Enrico Olivelli <eo...@gmail.com> wrote:

> What about cutting a release for Surefire plugin?
> We already fixed important problems that are on 3.0.0-M5 and I saw that
> current master branch works well.
>
> Thoughts?
> Volunteers?
>
> Enrico
>