Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Hi Stephen. In the Roadmap you have mentioned that all the discussion of particular Jira issue is discussed in ML. I cannot imaging how the code would be discussed here. Why not in pull request at github? In the repository with ASF rights INFRA can create labels like you have proposed "?" or "+1"

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I am +100 on that. Thanks for taking the initiative to get things back on track. Manfred Stephen Connolly wrote on 2017-01-03 09:40: > I believe we have consensus, here is the final call for anyone objecting to > the plan to have their opinions considered. > > Here is the draft of the proposal

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I believe we have consensus, here is the final call for anyone objecting to the plan to have their opinions considered. Here is the draft of the proposal for the vote: NOTE: THIS IS *NOT* THE VOTE -BEGIN DRAFT- Hi, We have collectively managed to mess up our ability to follow the

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

We need to get a release that is *the same as 3.3.9 only with aether swapped for resolver* first IMHO. That was the original plan... Then people started wanting to add bug fixes and lots of other stuff. The point of a reset is to return to the original plan. Bugs orthogonal to the

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I thought you had said that it was a regression introduced in 3.0, so if prerequisites is 2.x then you should resolve the "fixed" way as that was the way of 2.x that you are *restoring* The only reason for the bug reproduction on [3.0,3.4) is because people developing against the 3.x versions

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:23 schrieb Christian Schulte: > Am 01/01/17 um 08:18 schrieb Christian Schulte: >> Once more I asked someone to test a snapshot and provided a link to >> Jenkins. That's where all those commits come from. I hope I'll get >> feedback on this one and that could again lead to

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:06 schrieb Christian Schulte: > It's not even needed to change the plugin tools version any more. Only > plugins having declared > > 3.4 > > would get the correct resolution. As of yesterday. Happy new year everyone, BTW.

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:18 schrieb Christian Schulte: > Once more I asked someone to test a snapshot and provided a link to > Jenkins. That's where all those commits come from. I hope I'll get > feedback on this one and that could again lead to commits. Doing this on > a release branch - yes - I got

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 07:52 schrieb Christian Schulte: > Number of fixes to plugin POMs was lower than 10 commits. During all of > this quite a few other bugs have been identified in the core, the ITs, > the plugins, the plugin ITs, etc. Last issue I created in JIRA due to this is:

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:06 schrieb Christian Schulte: > Am 01/01/17 um 07:52 schrieb Christian Schulte: >> is uncovering bugs in the poms. Current master is passing all core ITs, >> all plugin ITs and also can be used to build all plugins, if you >> manually change to a different plugin tools release >>

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 07:52 schrieb Christian Schulte: > is uncovering bugs in the poms. Current master is passing all core ITs, > all plugin ITs and also can be used to build all plugins, if you > manually change to a different plugin tools release > (-DmavenPluginToolsVersion=3.3 or 3.5). It's not

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 12:13 schrieb Guillaume Boué: > > Having a vote on all changes to master sounds too much. I think it > should be up to the developers to always raise discussions whenever a > change would have impacts on existing ITs, or whenever a new feature is > considered to be added. Bug

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 17:36 schrieb Hervé BOUTEMY: > looks like 1.1.0 was released without tagging the repo: no tag even in > Eclipse > git [1]. I hope it is a state that is in git, even without tag: if someone > can > define the git hash, it would be useful to add a tag, just for reference > > I

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 2016-12-31 um 19:28 schrieb Stephen Connolly: Well I think syncing patch versions is pointless but as consumers outside of Maven are rare it might actually help to keep major.minor aligned... esp if we are doing a reset of resolver (if we have a release of resolver already cut) If we have

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I'm not seeing any objections to the general idea. On Tuesday I'll post a draft of the vote proposal to this thread... then if everyone is happy (translation: nobody says "I'm not happy") I'll start the vote on Wednesday 3rd... usual 72h but I'll probably wait for Monday 9th Jan before closing

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I'm hoping that people step forward with suggestions and we build a consensus IMHO 3.5.0 should be absolute minimum content. Just the switch to resolver and *maybe* the bug fixes on the launcher scripts and .mvn folder handling. Aim would be to release 3.5.0 by mid-Jan 3.5.x is less of a rush,

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Well I think syncing patch versions is pointless but as consumers outside of Maven are rare it might actually help to keep major.minor aligned... esp if we are doing a reset of resolver (if we have a release of resolver already cut) If we have not cut a resolver release then I'm fine with

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

It is a separate component, just like wagon. Don't think there's a need to sync those versions. On Sat, 31 Dec 2016 17:48:25 +0100, Stephen Connolly wrote: I think we should also align our resolver release version on 3.5.0 if we do the reset... wdyt?

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I think we should also align our resolver release version on 3.5.0 if we do the reset... wdyt? On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY wrote: > looks like 1.1.0 was released without tagging the repo: no tag even in > Eclipse > > git [1]. I hope it is a state that is in

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

looks like 1.1.0 was released without tagging the repo: no tag even in Eclipse git [1]. I hope it is a state that is in git, even without tag: if someone can define the git hash, it would be useful to add a tag, just for reference I don't know who uses Aether 1.1.0. And why are you saying that

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

good question. Here are some options: 1. last release used in Maven 3.3.9, ie Aether 1.0.2.v20150114 sha1 8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e [1], that is currently HEAD of 1.0.x branch 2. code imported to Apache, that I tagged as aether-core-import in master sha1

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

With pipeline multibranch we should be able to get the integration test results as a GitHub status pushed back (perhaps even comments on JIRA) Switching to pipeline multibranch should radically improve our CI infrastructure On Sat 31 Dec 2016 at 12:12, Tibor Digana

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Stephen, Maybe we should add an icon (green/red) of build status on the page [1]. The same should appear on every pull request in GitHub Maven origin/master and branches. WDYT? [1] https://github.com/apache/maven-integration-testing T On Sat, Dec 31, 2016 at 1:07 PM, Stephen Connolly <

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

On Saturday, 31 December 2016, Guillaume Boué wrote: > > > Le 30/12/2016 à 09:01, Robert Scholte a écrit : > >> On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY >> wrote: >> >> perhaps maven-resolver will require same reset >>> >> >> +1 >> >> IMO we

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Le 30/12/2016 à 09:01, Robert Scholte a écrit : On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY wrote: perhaps maven-resolver will require same reset +1 IMO we forgot to do a release with the original Aether code with the new GAVs. Robert and we'll need to

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

OT: how you can have a release with a majority of the PMC voting -1 1. The reasons for voting -1 must not relate to the responsibility delegated by the board to the PMC with respect to the requirements of a release 2. The majority of votes cast by committers + PMC must be in favour of the

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

You have misunderstood the Apache way, imho Votes are only to *confirm* consensus... and the consensus is of the *community* (ie everyone on the dev list who steps up to comment) When it comes to code changes, committers have a veto and the permission to commit, so no code changes can happen

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

That is not how Apache works The PMC vote is only required for policy or releases. Outside of that, committer votes are what count. Votes cast always trump votes not cast, and when it comes to commits, -1 is a veto... any -1 on a commit means thou shall not merge ... one should be very careful

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 03:27 schrieb Christian Schulte: > Am 12/29/16 um 13:49 schrieb Robert Scholte: >> My worries are more about: how to manage which issues should be cherry >> picked and who decides that list. Otherwise we might end up in the same >> situation. E.g. do we have to do a vote on the

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 03:27 schrieb Christian Schulte: > Am 12/29/16 um 13:49 schrieb Robert Scholte: >> My worries are more about: how to manage which issues should be cherry >> picked and who decides that list. Otherwise we might end up in the same >> situation. E.g. do we have to do a vote on the

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 13:49 schrieb Robert Scholte: > My worries are more about: how to manage which issues should be cherry > picked and who decides that list. Otherwise we might end up in the same > situation. E.g. do we have to do a vote on the branch (which might cover > multiple issues but

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/30/16 um 09:01 schrieb Robert Scholte: > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY > wrote: > >> perhaps maven-resolver will require same reset > > +1 > > IMO we forgot to do a release with the original Aether code with the new > GAVs. > Keep in mind

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

What hash do we want to reset resolved to? (We will be *renaming* master in all cases so that the history is available... just not on master) On Fri 30 Dec 2016 at 08:02, Robert Scholte wrote: > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY > >

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY wrote: perhaps maven-resolver will require same reset +1 IMO we forgot to do a release with the original Aether code with the new GAVs. Robert and we'll need to define which convention to use on Jira when

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

This got lost on the PMC list by mistake On Thu 29 Dec 2016 at 14:33, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I don't think we need to vote each change, but I do think we need to look > at a more RTC like model for bigger impact changes. > > I think we can trust developer

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 2016-12-29 um 20:41 schrieb Christian Schulte: Am 12/29/16 um 16:04 schrieb Michael Osipov: Am 2016-12-29 um 12:18 schrieb Stephen Connolly: On ASF infra, our master branch is supposed to be a protected branch and thus cannot be reset or force-pushed without an INFRA ticket. If we want to

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 16:04 schrieb Michael Osipov: > Am 2016-12-29 um 12:18 schrieb Stephen Connolly: >> On ASF infra, our master branch is supposed to be a protected branch and >> thus cannot be reset or force-pushed without an INFRA ticket. >> >> If we want to reset our master branch in order to clean

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 18:57 schrieb Hervé BOUTEMY: > perhaps maven-resolver will require same reset No need for this. Reverting MRESOLVER-8 and MRESOLVER-9 will be sufficient. Those are one-line style of commits. The rest of the commits do not change any behaviour.

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 12:18 schrieb Stephen Connolly: > I propose that we reset master back > to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of > master for the integration tests, and then immediately commit a dummy > commit so that nobody accidentally does a fast-forward push. +1

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

perhaps maven-resolver will require same reset and we'll need to define which convention to use on Jira when merging code: remove "Fix Version: 3.4.0" for example, to track what features have not been merged yet Regards, Hervé Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

I'm not against putting Jenkins config is source control: this will improve tracability. But until now, the PMC chair is supposed to be able to give karma [1]: this should be faster and IMHO remains useful. If this does not work, an INFRA ticket should be opened Regards, Hervé [1]

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Well Jenkins is my day job I have no issues seeking time to implement pipeline for Maven as that can be seen as benefiting the Jenkins OSS community as well as proving out pipeline for real world use cases. Note the above is all pure OSS work not the for-pay side of my employers house. So I am

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 2016-12-29 um 12:18 schrieb Stephen Connolly: On ASF infra, our master branch is supposed to be a protected branch and thus cannot be reset or force-pushed without an INFRA ticket. If we want to reset our master branch in order to clean out the history of the many changes and reverts to and

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

thanks Stephen for picking this up. SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03 * [maven-release-plugin] prepare for next development iteration Yes, this is the hash I would expect to revert to. Based on the date I would expect that maven-its should be reset to SHA-1:

[DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

On ASF infra, our master branch is supposed to be a protected branch and thus cannot be reset or force-pushed without an INFRA ticket. If we want to reset our master branch in order to clean out the history of the many changes and reverts to and fro etc, we thus need an INFRA ticket raised.