Re: Cannot edit or comment on Wiki pages

[Hervé BOUTEMY]

Hi,

I just got "Space Admin" karma to see what happens:
edit right are put on maven-committers group, and you are on the Unis maven 
group https://people.apache.org/phonebook.html?unix=maven

Perhaps there is a sync issue between LDAP goups and Confluence groups.

Can you confirm that you can't edit any page? (read only is for non-committers)

Regards,

Hervé

Le mercredi 4 janvier 2017, 08:44:35 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> I don't know how it was done (a good number of years ago) for me to have
> edit karma, but I have.
> I looked for INFRA documentation on the topic, and found related procedure I
> didn't know [1]
> 
> I don't know who is the "Space Admin" for Maven Wiki, but we'll need to
> figure out and add this point in our new committer process: looks like new
> committers don't get access to the necessary toolset currently to work
> efficiently within the team...
> 
> BTW, is the Jenkins admin question fixed also?
> 
> Since if I contact INFRA on the Wiki topic, I'll see the Jenkins topic also.
> 
> Regards,
> 
> Hervé
> 
> [1]
> https://cwiki.apache.org/confluence/display/INFRA/Managing+permissions+on
> +your+project%27s+Confluence+Space
> 
> Le mercredi 4 janvier 2017, 04:25:34 CET Christian Schulte a écrit :
> > Hi,
> > 
> > user name is "schulte". I am not sure about this, but I think I do not
> > have permission to do anything in the Wiki. I can read everything, but
> > cannot edit things or comment on things.
> > 
> > Regards,
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-release pull request #9: Fix for MRELEASE-976

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven-release/pull/9


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Dan Tran]

+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
> >
> >
> >
> > 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.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
> >
> > >> colourization and launcher script bug fixes.
> >
> > >>
> >
> > >> Given that some developer private builds of the current master branch
> > have
> >
> > >> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> > been
> >
> > >> closed with a fixed version of 3.4.0.
> >
> > >>
> >
> > >> For us to release a 3.4.0 with those fixes reverted, could cause
> > confusion
> >
> > >> with our user community.
> >
> > >>
> >
> > >> Additionally the informal practice of keeping existing integration
> > tests as
> >
> > >> RTC has not been followed, leading to some people to question whether
> > the
> >
> > >> integration tests remain valid.
> >
> > >>
> >
> > >> For all the above reasons it is proposed to do *all* the following as
> an
> >
> > >> whole:
> >
> > >>
> >
> > >> 1. In git://git.apache.org/maven.git we will rename the current
> master
> >
> > >> branch to `pre-reset-master` and recreate `master`
> >
> > >> as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
> >
> > >> https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
> >
> > >> 74dc195fb1
> >
> > >> )
> >
> > >>
> >
> > >> 2. In git://git.apache.org/maven-integration-testing.git we will
> rename
> >
> > >> the
> >
> > >> current master branch to `pre-reset-master` and recreate `master`
> >
> > >> as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
> >
> > >> https://github.com/apache/maven-integration-testing/commit/
> >
> > >> f31241ad6cb6474e559289f1bd7110ea5d5a4fba
> >
> > >> )
> >
> > >>
> >
> > >> 3. In git://git.apache.org/maven-resolver.git we will rename the
> > current
> >
> > >> master branch to `pre-reset-master` and recreate `master`
> >
> > >> as b74f7a1e8837875b4780199f644119f55d22465d (
> >
> > >> https://github.com/apache/maven-resolver/commit/
> >
> > >> b74f7a1e8837875b4780199f644119f55d22465d),
> >
> > >> i.e. the 1.0.x branch
> >
> > >>
> >
> > >> We will then proceed to have (ideally) the original committers
> > cherry-pick
> >
> > >> (and tidy up an squash... if the original committers are not able to
> > assist
> >
> > >> then squashing may not be practicable) those changes that have been
> > agreed
> >
> > >> for 3.5.0 as summarized on the
> >
> > >> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki
> > page
> >
> > >> (authorative source of the decisions summarized in the wiki page is
> the
> >
> > >> mail thread:
> >
> > >> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.
> mbox/%3CCA%
> >
> > >> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com
> %3E
> >
> > >>  ).
> >
> > >>
> >
> > >> As this involves a --force push on the `master` branch, we want to get
> > the
> >
> > >> approval of the committers before continuing.
> >
> > >>
> >
> > >> The vote will be open for at least 72 hours.
> >
> > >>
> >
> > >> The vote will be decided by a simple majority of valid votes cast.
> > There is
> >
> > >> no veto.
> >
> > >>
> >
> > >> The vote is open to all committers.
> >
> > >>
> >
> > >> In addition, for the vote to be valid, there must be at least 3x+1
> votes
> >
> > >> from PMC members
> >
> > >>
> >
> > >> [ ] +1: Yes
> >
> > >> [ ] 0:
> >
> > >> [ ] -1: No
> >
> > >>
> >
> > >> -Stephen
> >
> > >> --
> >
> > >> Sent from my phone
> >
> > >>
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
>

Re: [DISCUSS] Stop allowing forced pushes to GIT repositories.

[Arnaud Héritier]

+1. It should be forbidden on master.

Le dim. 8 janv. 2017 à 23:56, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :

> Master is supposed to be set up that way by infra... if some repositories
>
> are not set up that way we should just get infra to fix it
>
>
>
> On Sun 8 Jan 2017 at 22:47, Christian Schulte  wrote:
>
>
>
> > Hi,
>
> >
>
> >
>
> >
>
> > subject says it all. I'd like to request that our GIT repositories are
>
> >
>
> > setup in a way that a 'git --force push' is not possible. Not pulling
>
> >
>
> > changes of others in and then force pushing to exchange the remote
>
> >
>
> > master branch with some other branch should not be possible. In fact, in
>
> >
>
> > subversion you just could not commit to trunk whithout updating your
>
> >
>
> > local working copy first and that is something very good about
>
> >
>
> > subversion. We should not change this just because we switched from
>
> >
>
> > subversion to git.
>
> >
>
> >
>
> >
>
> > Regards,
>
> >
>
> > --
>
> >
>
> > Christian
>
> >
>
> >
>
> >
>
> > -
>
> >
>
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> >
>
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >
>
> >
>
> >
>
> > --
>
> Sent from my phone
>
>

[GitHub] maven-release pull request #8: Fix for MRELEASE-975

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven-release/pull/8


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Stop allowing forced pushes to GIT repositories.

[Stephen Connolly]

Master is supposed to be set up that way by infra... if some repositories
are not set up that way we should just get infra to fix it

On Sun 8 Jan 2017 at 22:47, Christian Schulte  wrote:

> Hi,
>
>
>
> subject says it all. I'd like to request that our GIT repositories are
>
> setup in a way that a 'git --force push' is not possible. Not pulling
>
> changes of others in and then force pushing to exchange the remote
>
> master branch with some other branch should not be possible. In fact, in
>
> subversion you just could not commit to trunk whithout updating your
>
> local working copy first and that is something very good about
>
> subversion. We should not change this just because we switched from
>
> subversion to git.
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

[DISCUSS] Stop allowing forced pushes to GIT repositories.

[Christian Schulte]

Hi,

subject says it all. I'd like to request that our GIT repositories are
setup in a way that a 'git --force push' is not possible. Not pulling
changes of others in and then force pushing to exchange the remote
master branch with some other branch should not be possible. In fact, in
subversion you just could not commit to trunk whithout updating your
local working copy first and that is something very good about
subversion. We should not change this just because we switched from
subversion to git.

Regards,
-- 
Christian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-release pull request #9: adds project version policies support to rele...

[hgschmie]

GitHub user hgschmie opened a pull request:

https://github.com/apache/maven-release/pull/9

adds project version policies support to release:branch



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgschmie/maven-release MRELEASE-976

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-release/pull/9.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #9


commit 8b6ee121abdbc9e5f3b175359d54d78757e8cd10
Author: Henning Schmiedehausen 
Date:   2017-01-08T05:18:37Z

adds project version policies support to release:branch




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-release pull request #8: Fix for MRELEASE-975

[hgschmie]

GitHub user hgschmie opened a pull request:

https://github.com/apache/maven-release/pull/8

Fix for MRELEASE-975

fixes https://issues.apache.org/jira/browse/MRELEASE-975

When passing in an unknown project version policy id with 
-DprojectVersionPolicyId, the plugin will throw an NPE.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgschmie/maven-release MRELEASE-975

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-release/pull/8.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #8


commit 86b21dcfb404eb0adbc3653aa6878294570e24f4
Author: Henning Schmiedehausen 
Date:   2017-01-08T05:15:57Z

fixes NPE when using an unknown policy id




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Olivier Lamy]

+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.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 code after migration
> to
>
> >> Apache's Maven Resolver plus some other orthogonal changes around
> logging
>
> >> colourization and launcher script bug fixes.
>
> >>
>
> >> Given that some developer private builds of the current master branch
> have
>
> >> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> been
>
> >> closed with a fixed version of 3.4.0.
>
> >>
>
> >> For us to release a 3.4.0 with those fixes reverted, could cause
> confusion
>
> >> with our user community.
>
> >>
>
> >> Additionally the informal practice of keeping existing integration
> tests as
>
> >> RTC has not been followed, leading to some people to question whether
> the
>
> >> integration tests remain valid.
>
> >>
>
> >> For all the above reasons it is proposed to do *all* the following as an
>
> >> whole:
>
> >>
>
> >> 1. In git://git.apache.org/maven.git we will rename the current master
>
> >> branch to `pre-reset-master` and recreate `master`
>
> >> as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
>
> >> https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
>
> >> 74dc195fb1
>
> >> )
>
> >>
>
> >> 2. In git://git.apache.org/maven-integration-testing.git we will rename
>
> >> the
>
> >> current master branch to `pre-reset-master` and recreate `master`
>
> >> as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
>
> >> https://github.com/apache/maven-integration-testing/commit/
>
> >> f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> >> )
>
> >>
>
> >> 3. In git://git.apache.org/maven-resolver.git we will rename the
> current
>
> >> master branch to `pre-reset-master` and recreate `master`
>
> >> as b74f7a1e8837875b4780199f644119f55d22465d (
>
> >> https://github.com/apache/maven-resolver/commit/
>
> >> b74f7a1e8837875b4780199f644119f55d22465d),
>
> >> i.e. the 1.0.x branch
>
> >>
>
> >> We will then proceed to have (ideally) the original committers
> cherry-pick
>
> >> (and tidy up an squash... if the original committers are not able to
> assist
>
> >> then squashing may not be practicable) those changes that have been
> agreed
>
> >> for 3.5.0 as summarized on the
>
> >> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki
> page
>
> >> (authorative source of the decisions summarized in the wiki page is the
>
> >> mail thread:
>
> >> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
>
> >> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
>
> >>  ).
>
> >>
>
> >> As this involves a --force push on the `master` branch, we want to get
> the
>
> >> approval of the committers before continuing.
>
> >>
>
> >> The vote will be open for at least 72 hours.
>
> >>
>
> >> The vote will be decided by a simple majority of valid votes cast.
> There is
>
> >> no veto.
>
> >>
>
> >> The vote is open to all committers.
>
> >>
>
> >> In addition, for the vote to be valid, there must be at least 3x+1 votes
>
> >> from PMC members
>
> >>
>
> >> [ ] +1: Yes
>
> >> [ ] 0:
>
> >> [ ] -1: No
>
> >>
>
> >> -Stephen
>
> >> --
>
> >> Sent from my phone
>
> >>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Karl Heinz Marbaise]

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.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
colourization and launcher script bug fixes.

Given that some developer private builds of the current master branch have
been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
closed with a fixed version of 3.4.0.

For us to release a 3.4.0 with those fixes reverted, could cause confusion
with our user community.

Additionally the informal practice of keeping existing integration tests as
RTC has not been followed, leading to some people to question whether the
integration tests remain valid.

For all the above reasons it is proposed to do *all* the following as an
whole:

1. In git://git.apache.org/maven.git we will rename the current master
branch to `pre-reset-master` and recreate `master`
as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
74dc195fb1
)

2. In git://git.apache.org/maven-integration-testing.git we will rename
the
current master branch to `pre-reset-master` and recreate `master`
as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
https://github.com/apache/maven-integration-testing/commit/
f31241ad6cb6474e559289f1bd7110ea5d5a4fba
)

3. In git://git.apache.org/maven-resolver.git we will rename the current
master branch to `pre-reset-master` and recreate `master`
as b74f7a1e8837875b4780199f644119f55d22465d (
https://github.com/apache/maven-resolver/commit/
b74f7a1e8837875b4780199f644119f55d22465d),
i.e. the 1.0.x branch

We will then proceed to have (ideally) the original committers cherry-pick
(and tidy up an squash... if the original committers are not able to assist
then squashing may not be practicable) those changes that have been agreed
for 3.5.0 as summarized on the
https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
(authorative source of the decisions summarized in the wiki page is the
mail thread:
https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
 ).

As this involves a --force push on the `master` branch, we want to get the
approval of the committers before continuing.

The vote will be open for at least 72 hours.

The vote will be decided by a simple majority of valid votes cast. There is
no veto.

The vote is open to all committers.

In addition, for the vote to be valid, there must be at least 3x+1 votes
from PMC members

[ ] +1: Yes
[ ] 0:
[ ] -1: No

-Stephen
--
Sent from my phone



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Stephen Connolly]

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 would work without additional options...

And on top of that the history for mortal users would show the fixes "as
present in the history"

It would be great if Kristian R. Could confirm my understanding.

-Stephen

On Sun 8 Jan 2017 at 10:41, Hervé BOUTEMY  wrote:

> 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 git experts to evaluate this implementation strategy?
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
> Le jeudi 5 janvier 2017, 10:12:10 CET Mark Derricutt a écrit :
>
> > 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 that ONLY takes one side.
>
> > Effectively resetting, keeping the fact we did this reversal, and doesn't
>
> > force everyone to re-clone.
>
> >
>
> > From https://git-scm.com/docs/merge-strategies:
>
> >
>
> > ours: This resolves any number of heads, but the resulting tree of the
> merge
>
> > is always that of the current branch head, effectively ignoring all
> changes
>
> > from all other branches. It is meant to be used to supersede old
>
> > development history of side branches. Note that this is different from
> the
>
> > -Xours option to the 'recursive' merge strategy.
>
> >
>
> > Would something like this be better than force pushing?
>
> >
>
> > --
>
> > Mark Derricutt
>
> > http://www.theoryinpractice.net
>
> > http://www.chaliceofblood.net
>
> > http://plus.google.com/+MarkDerricutt
>
> > http://twitter.com/talios
>
> > http://facebook.com/mderricutt
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Hervé BOUTEMY]

+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 starting 
point
implementation strategy detail can be changed without issue

Regards,

Hervé

Le mercredi 4 janvier 2017, 12:16:11 CET 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
> Apache's Maven Resolver plus some other orthogonal changes around logging
> colourization and launcher script bug fixes.
> 
> Given that some developer private builds of the current master branch have
> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
> closed with a fixed version of 3.4.0.
> 
> For us to release a 3.4.0 with those fixes reverted, could cause confusion
> with our user community.
> 
> Additionally the informal practice of keeping existing integration tests as
> RTC has not been followed, leading to some people to question whether the
> integration tests remain valid.
> 
> For all the above reasons it is proposed to do *all* the following as an
> whole:
> 
> 1. In git://git.apache.org/maven.git we will rename the current master
> branch to `pre-reset-master` and recreate `master`
> as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
> https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb174dc195
> fb1 )
> 
> 2. In git://git.apache.org/maven-integration-testing.git we will rename the
> current master branch to `pre-reset-master` and recreate `master`
> as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
> https://github.com/apache/maven-integration-testing/commit/f31241ad6cb6474e5
> 59289f1bd7110ea5d5a4fba )
> 
> 3. In git://git.apache.org/maven-resolver.git we will rename the current
> master branch to `pre-reset-master` and recreate `master`
> as b74f7a1e8837875b4780199f644119f55d22465d (
> https://github.com/apache/maven-resolver/commit/b74f7a1e8837875b4780199f6441
> 19f55d22465d), i.e. the 1.0.x branch
> 
> We will then proceed to have (ideally) the original committers cherry-pick
> (and tidy up an squash... if the original committers are not able to assist
> then squashing may not be practicable) those changes that have been agreed
> for 3.5.0 as summarized on the
> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
> (authorative source of the decisions summarized in the wiki page is the
> mail thread:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%2BnPnM
> xERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E ).
> 
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
> 
> The vote will be open for at least 72 hours.
> 
> The vote will be decided by a simple majority of valid votes cast. There is
> no veto.
> 
> The vote is open to all committers.
> 
> In addition, for the vote to be valid, there must be at least 3x+1 votes
> from PMC members
> 
> [ ] +1: Yes
> [ ] 0:
> [ ] -1: No
> 
> -Stephen



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Hervé BOUTEMY]

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 git experts to evaluate this implementation strategy?

Regards,

Hervé

Le jeudi 5 janvier 2017, 10:12:10 CET Mark Derricutt a écrit :
> 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 that ONLY takes one side.
> Effectively resetting, keeping the fact we did this reversal, and doesn't
> force everyone to re-clone.
> 
> From https://git-scm.com/docs/merge-strategies:
> 
> ours: This resolves any number of heads, but the resulting tree of the merge
> is always that of the current branch head, effectively ignoring all changes
> from all other branches. It is meant to be used to supersede old
> development history of side branches. Note that this is different from the
> -Xours option to the 'recursive' merge strategy.
> 
> Would something like this be better than force pushing?
> 
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: FOSDEM 2017

[Stephane Nicoll]

I might come on Sunday.


On Thu, 5 Jan 2017 at 14:20, Robert Scholte  wrote:

> Hi,
>
>
>
> Just like the last couple of years FOSDEM has been a great opportunity to
>
> meet several Maven developers.
>
> Some of the new features and improvements started here when the Maven
>
> committers shared their ideas.
>
>
>
> FOSDEM 2017 will take place at ULB Campus Solbosch on Saturday 4 and
>
> Sunday 5 February 2017.
>
> I plan to go this year and I'm wondering who considers to come as well.
>
>
>
> thanks,
>
> Robert
>
>
>
> [1] https://fosdem.org/2017/
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Stephane Nicoll]

+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 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
>
> > colourization and launcher script bug fixes.
>
> >
>
> > Given that some developer private builds of the current master branch
> have
>
> > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> been
>
> > closed with a fixed version of 3.4.0.
>
> >
>
> > For us to release a 3.4.0 with those fixes reverted, could cause
> confusion
>
> > with our user community.
>
> >
>
> > Additionally the informal practice of keeping existing integration tests
> as
>
> > RTC has not been followed, leading to some people to question whether the
>
> > integration tests remain valid.
>
> >
>
> > For all the above reasons it is proposed to do *all* the following as an
>
> > whole:
>
> >
>
> > 1. In git://git.apache.org/maven.git we will rename the current master
>
> > branch to `pre-reset-master` and recreate `master`
>
> > as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
>
> >
> https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb174dc195fb1
>
> > )
>
> >
>
> > 2. In git://git.apache.org/maven-integration-testing.git we will rename
> the
>
> > current master branch to `pre-reset-master` and recreate `master`
>
> > as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
>
> >
> https://github.com/apache/maven-integration-testing/commit/f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> > )
>
> >
>
> > 3. In git://git.apache.org/maven-resolver.git we will rename the current
>
> > master branch to `pre-reset-master` and recreate `master`
>
> > as b74f7a1e8837875b4780199f644119f55d22465d (
>
> >
> https://github.com/apache/maven-resolver/commit/b74f7a1e8837875b4780199f644119f55d22465d
> ),
>
> > i.e. the 1.0.x branch
>
> >
>
> > We will then proceed to have (ideally) the original committers
> cherry-pick
>
> > (and tidy up an squash... if the original committers are not able to
> assist
>
> > then squashing may not be practicable) those changes that have been
> agreed
>
> > for 3.5.0 as summarized on the
>
> > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
>
> > (authorative source of the decisions summarized in the wiki page is the
>
> > mail thread:
>
> >
> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
>
> > ).
>
> >
>
> > As this involves a --force push on the `master` branch, we want to get
> the
>
> > approval of the committers before continuing.
>
> >
>
> > The vote will be open for at least 72 hours.
>
> >
>
> > The vote will be decided by a simple majority of valid votes cast. There
> is
>
> > no veto.
>
> >
>
> > The vote is open to all committers.
>
> >
>
> > In addition, for the vote to be valid, there must be at least 3x+1 votes
>
> > from PMC members
>
> >
>
> > [ ] +1: Yes
>
> > [ ] 0:
>
> > [ ] -1: No
>
> >
>
> > -Stephen
>
> > --
>
> > Sent from my phone
>
> >
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Arnaud Héritier]

+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 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
>
> > colourization and launcher script bug fixes.
>
> >
>
> > Given that some developer private builds of the current master branch
> have
>
> > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> been
>
> > closed with a fixed version of 3.4.0.
>
> >
>
> > For us to release a 3.4.0 with those fixes reverted, could cause
> confusion
>
> > with our user community.
>
> >
>
> > Additionally the informal practice of keeping existing integration tests
> as
>
> > RTC has not been followed, leading to some people to question whether the
>
> > integration tests remain valid.
>
> >
>
> > For all the above reasons it is proposed to do *all* the following as an
>
> > whole:
>
> >
>
> > 1. In git://git.apache.org/maven.git we will rename the current master
>
> > branch to `pre-reset-master` and recreate `master`
>
> > as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
>
> > https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
>
> > 74dc195fb1
>
> > )
>
> >
>
> > 2. In git://git.apache.org/maven-integration-testing.git we will rename
>
> > the
>
> > current master branch to `pre-reset-master` and recreate `master`
>
> > as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
>
> > https://github.com/apache/maven-integration-testing/commit/
>
> > f31241ad6cb6474e559289f1bd7110ea5d5a4fba
>
> > )
>
> >
>
> > 3. In git://git.apache.org/maven-resolver.git we will rename the current
>
> > master branch to `pre-reset-master` and recreate `master`
>
> > as b74f7a1e8837875b4780199f644119f55d22465d (
>
> > https://github.com/apache/maven-resolver/commit/
>
> > b74f7a1e8837875b4780199f644119f55d22465d),
>
> > i.e. the 1.0.x branch
>
> >
>
> > We will then proceed to have (ideally) the original committers
> cherry-pick
>
> > (and tidy up an squash... if the original committers are not able to
> assist
>
> > then squashing may not be practicable) those changes that have been
> agreed
>
> > for 3.5.0 as summarized on the
>
> > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
>
> > (authorative source of the decisions summarized in the wiki page is the
>
> > mail thread:
>
> > https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
>
> > 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
>
> >  ).
>
> >
>
> > As this involves a --force push on the `master` branch, we want to get
> the
>
> > approval of the committers before continuing.
>
> >
>
> > The vote will be open for at least 72 hours.
>
> >
>
> > The vote will be decided by a simple majority of valid votes cast. There
> is
>
> > no veto.
>
> >
>
> > The vote is open to all committers.
>
> >
>
> > In addition, for the vote to be valid, there must be at least 3x+1 votes
>
> > from PMC members
>
> >
>
> > [ ] +1: Yes
>
> > [ ] 0:
>
> > [ ] -1: No
>
> >
>
> > -Stephen
>
> > --
>
> > Sent from my phone
>
> >
>
>
>
>
>
>
>
> --
>
> Cheers
>
> Tibor
>
>