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
> 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
+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
+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 <
>
> >
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
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
+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
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
+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
+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
+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
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
+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
+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
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
+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
+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
>
+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
+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
+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 <
> >
> >
+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
>
+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
+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
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
25 matches
Mail list logo