On 4 January 2017 at 12:16, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether for the c
> I like this idea of avoiding force pushing, but I'm not git expert to know
> exactly if this gives exactly the intended result = start clean and not
> have noise when doing bisects or git blame
It's clean for our own repo but might probably screw up cloned repos as they
cannot just git-pull an
+1 (Committer)
Special thanks for pulling all these together
-D
On Sun, Jan 8, 2017 at 1:05 PM, Olivier Lamy wrote:
> +1
>
> On Sun, 8 Jan 2017 at 6:40 pm, Karl Heinz Marbaise
> wrote:
>
> > Hi,
> >
> >
> >
> > +1 (PMC + Committer)
> >
> >
> >
> > Kind regards
> >
> > Karl Heinz Marbaise
> >
+1
On Sun, 8 Jan 2017 at 6:40 pm, Karl Heinz Marbaise
wrote:
> Hi,
>
>
>
> +1 (PMC + Committer)
>
>
>
> Kind regards
>
> Karl Heinz Marbaise
>
>
>
> On 08/01/17 05:48, Tibor Digana wrote:
>
> > +1
>
> >
>
> > On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
>
> > stephen.alan.conno...@gmail.co
Hi,
+1 (PMC + Committer)
Kind regards
Karl Heinz Marbaise
On 08/01/17 05:48, Tibor Digana wrote:
+1
On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4
If we were *throwing away* the other commits then that would work.
But as I understand it, ours would mean that the commits are part of the
history, so merging would not apply them... tooling to check if they need
to be cherry picked would show as already merged... I'd need to check if
cherry pick
+1 (committer & PMC)
notice that the merge ours implementation strategy may be a better
implementation than force push with branches renaming
If some git expert can dig into implementaion strategies, please, that would
be great
what is important to me is the vote to reset and to define the new
I like this idea of avoiding force pushing, but I'm not git expert to know
exactly if this gives exactly the intended result = start clean and not have
noise when doing bisects or git blame
this technical discussion should probably on a separate email thread, to not
pollute the vote thread
Any
+1
On Wed, 4 Jan 2017 at 17:39, Manfred Moser wrote:
> +1 (committer)
>
>
>
> Stephen Connolly wrote on 2017-01-04 04:16:
>
>
>
> > Hi,
>
> >
>
> > We have collectively managed to mess up our ability to follow the
> original
>
> > release plan for 3.4.0 which was originally supposed to consist
+1
Le dim. 8 janv. 2017 à 05:48, Tibor Digana a
écrit :
> +1
>
>
>
> On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
>
> stephen.alan.conno...@gmail.com> wrote:
>
>
>
> > Hi,
>
> >
>
> > We have collectively managed to mess up our ability to follow the
> original
>
> > release plan for 3.4.0
+1
On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether f
I'll give the vote until monday just in case anyone missed it
On 4 January 2017 at 12:16, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consi
+1 (committer)
Le 04/01/2017 à 13:16, Stephen Connolly a écrit :
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
Apach
+1 (committer)
Am 01/04/17 um 13:16 schrieb Stephen Connolly:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether for the code after migration to
>
This would be better on the discuss thread, but here is my answer anyway:
Well we want to bring most of that history back in for 3.5.1+ so, no that
wouldn't work AIUI.
Part of the issue is the to and fro with things like the bump of
modelVersion to 4.1.0 and then the revert, etc.
Plus if the com
On 5 Jan 2017, at 1:16, Stephen Connolly wrote:
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
You _could_ branch at the point you want to reset to, then use an ours/theirs
merge strategy which creates a merge commit t
+1 (PMC & committer)
Am 2017-01-04 um 13:16 schrieb Stephen Connolly:
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
A
+1 (committer)
Stephen Connolly wrote on 2017-01-04 04:16:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether for the code after migration to
> A
+1
On Jan 4, 2017 10:03 AM, "Robert Scholte" wrote:
> +1
>
> On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> Hi,
>>
>> We have collectively managed to mess up our ability to follow the original
>> release plan for 3.4.0 which was originally su
+1
On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly
wrote:
Hi,
We have collectively managed to mess up our ability to follow the
original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration
t
+1
--
Regards,
Igor
On Wed, Jan 4, 2017, at 08:31 AM, Andreas Gudian wrote:
> +1
>
>
> Anders Hammar schrieb am Mi. 4. Jan. 2017 um 13:22:
>
> > +1
> >
> >
> >
> > /Anders
> >
> >
> >
> > On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> >
>
+1
Anders Hammar schrieb am Mi. 4. Jan. 2017 um 13:22:
> +1
>
>
>
> /Anders
>
>
>
> On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
>
> stephen.alan.conno...@gmail.com> wrote:
>
>
>
> > Hi,
>
> >
>
> > We have collectively managed to mess up our ability to follow the
> original
>
> > release
+1
/Anders
On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's
+1 (PMC & committer)
On Wed 4 Jan 2017 at 12:16, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Ecli
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
Apache's Maven Resolver plus some other orthogonal changes around logging
Are you trying to add a test specifically for the maven-ear-plugin? Is there a
reason you’re not adding this to the maven-ear-plugin ITs? Are you trying test
reactor resolution?
You should also not need to use the dependency plugin to pull things down. You
sure it’s not our weird CI setup? If y
Hi Hervé,
On 10/25/15 12:59 PM, Hervé BOUTEMY wrote:
I saw that you finally managed to make the bootstrap happy: do you think the
issue is foxed, or do you still fear unexpected failures in the future?
At the moment i'm fighting with embedded it's which say a dependency for
maven-ear-plugin 2
I saw that you finally managed to make the bootstrap happy: do you think the
issue is foxed, or do you still fear unexpected failures in the future?
Then to make the bootstrap process easier to understand, perhaps we should
publish bootstrap result in core-its documentation [1], in addition to t
Hi,
at the moment i'm observing a strange behaviour where i don't have any
idea of the cause.
Sometimes the IT's start and the bootstrap is successful and you can
find log.txt in the appropriate folder..
But sometimes it fails and there is no track of a log.txt in the
appropriate folder...
tegration-tests/src/test/
resources/it0040/pom.xml
Modified: maven/components/trunk/maven-core-integration-tests/src/
test/resources/it0040/pom.xml
URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-
core-integration-tests/src/test/resources/it0040/pom.xml?
view=diff&rev=466686
Log:
correcting artifactId and groupId
Modified:
maven/components/trunk/maven-core-integration-tests/src/test/
resources/it0040/pom.xml
Modified: maven/components/trunk/maven-core-integration-tests/src/
test/resources/it0040/pom.xml
URL: http://svn.apache.org/viewvc/maven/components/trunk/m
/viewvc?view=rev&rev=466686
Log:
correcting artifactId and groupId
Modified:
maven/components/trunk/maven-core-integration-tests/src/test/
resources/it0040/pom.xml
Modified: maven/components/trunk/maven-core-integration-tests/src/
test/resources/it0040/pom.xml
URL: http://svn.apache.org/vi
32 matches
Mail list logo
