GitHub user Tibor17 opened a pull request:
https://github.com/apache/maven-surefire/pull/33
fixed tests for SUREFIRE[1055]
The parallel tests should check the test count so that all have completed
successfully.
This is possible after fix 1055.
You can merge this pull request in
Eclipse development process distinguishes several build types [1], so I
am wondering if you really want to do weekly "full" releases or your
goal is to have something closer to integration builds in eclipse
nomenclature.
I see two major downsides doing weekly full releases.
First, one week just
There's an Apache nuance to highlight here.
We may not advertise non-voted items to the general public. We may
offer non-voted items to engaged community members.
I do not know enough about Eclipse to offer an intelligent comparison.
--
On Feb 18, 2014, at 4:23 PM, Stephen Connolly
wrote:
>
> If they are releases that we intend users picking up, then there needs to
> be a vote.
>
That's not true. Official releases need to be voted on, if people pick the
product of a nightly or wander into the workspace of a CI build that's
On Feb 18, 2014, at 4:32 PM, Benson Margulies wrote:
> Looking for common ground here, how about we start by documenting the core
> release procedure so that someone else could plausibly take a turn? Without
> knowing the details of the release process, I don't see how I could disagree
> with
Looking for common ground here, how about we start by documenting the core
release procedure so that someone else could plausibly take a turn? Without
knowing the details of the release process, I don't see how I could disagree
with JvZ.
It mostly seems to me that Stephen's desired schedule co
Looking for common ground here, how about we start by documenting the core
release procedure so that someone else could plausibly take a turn? Without
knowing the details of the release process, I don't see how I could disagree
with JvZ.
It mostly seems to me that Stephen's desired schedule co
On 18 February 2014 23:58, Jason van Zyl wrote:
>
> On Feb 18, 2014, at 3:20 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Well for one that is not how RM works or has worked here.
> >
>
> Really? When I have planned to release core it takes some effort that
> requires mo
On Feb 18, 2014, at 3:20 PM, Stephen Connolly
wrote:
> Well for one that is not how RM works or has worked here.
>
Really? When I have planned to release core it takes some effort that requires
more effort than the normal components. So if it's not clear from trying to
curate the issues for
On 18 February 2014 22:47, Jason van Zyl wrote:
>
> On Feb 18, 2014, at 2:19 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Tuesday, 18 February 2014, Jason van Zyl wrote:
> >
> >>
> >> On Feb 18, 2014, at 11:47 AM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.c
Perhaps a stupid question, however if no change goes in, and it kicks off
and gives the same gold star as the previous week, then there's no point to
releasing it, because it's the same thing, what takes care of this? Just
the human going "well, actually there were no commits, so this email is
spur
On Feb 18, 2014, at 2:19 PM, Stephen Connolly
wrote:
> On Tuesday, 18 February 2014, Jason van Zyl wrote:
>
>>
>> On Feb 18, 2014, at 11:47 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com > wrote:
>>
>>> Well all this will be for the moment is a reminder that the best tests we
>>>
On Tuesday, 18 February 2014, Jason van Zyl wrote:
>
> On Feb 18, 2014, at 11:47 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > Well all this will be for the moment is a reminder that the best tests we
> > have say it is releasable and that a *human* can think about cutti
GitHub user everflux opened a pull request:
https://github.com/apache/maven-indexer/pull/3
Update to lucene 4.6 with new API
Please note that the version is changed for local development. You may want
to bump it to 6.0.0 to communicate the API break clearly.
You can merge this pull
On Feb 18, 2014, at 11:47 AM, Stephen Connolly
wrote:
> Well all this will be for the moment is a reminder that the best tests we
> have say it is releasable and that a *human* can think about cutting a
> release.
>
> Right now it will fail to notify because there are failing integration
> tes
Well all this will be for the moment is a reminder that the best tests we
have say it is releasable and that a *human* can think about cutting a
release.
Right now it will fail to notify because there are failing integration
tests (need a 3.2.1 in central to fix the three failing tests)
If we swi
Am 2014-02-18 16:26, schrieb Stephen Connolly:
I have set up a chain of build jobs in Jenkins.
The root of the chain is
https://builds.apache.org/job/maven-3.2-release-status/
The certificate has expired today, hopefully infra will fix this ASAP.
Michael
---
Sorry, but I don't think this is a good way to do releases. Honestly I think
it's a potential recipe for disaster.
As I said before, it's the lack of work being done in the core that is the
issue. Releases aren't being made because until recently there isn't a lot of
activity in the core. Just
On 13 February 2014 15:14, Stephen Connolly wrote:
> We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
>
> During that period no release manager has stepped up to cut a release.
>
> I would argue that we should just therefore just declare Maven 2.x as end
> of life.
>
> T
I have set up a chain of build jobs in Jenkins.
The root of the chain is
https://builds.apache.org/job/maven-3.2-release-status/
This builds at midnight UTC every monday.
If there are changes to the master branch of Maven since the last release
of Maven then that build will pass and kick off the
20 matches
Mail list logo
