Re: [DISCUSS] Towards a common understanding of things

[Hervé BOUTEMY]

one thing we need: common focus for some time

there are so many directions followed by so many people at the same time that 
nobody can't follow everything. And when it's about having Maven core evolve, 
this is critical to have many people review and evaluate (it's less critical 
for a plugin or even a shared component, that each plugin will upgrade or not)

we need to give some time to others on focused, well explained topics, to let 
them evaluate and test

Regards,

Hervé

Le lundi 20 mars 2017, 01:51:32 CET Christian Schulte a écrit :
> Am 03/20/17 um 01:47 schrieb Christian Schulte:
> > Am 03/20/17 um 01:11 schrieb Stephen Connolly:
> >> On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
> >> 
> >> stephen.alan.conno...@gmail.com> wrote:
> >>> We need to define:
> >>> 
> >>> * what is a bug vs what is an rfe
> >>> 
> >>> * what are the different severities for bugs and rfes
> >> 
> >> S1: software is unusable, halts, crashes, or is inaccessible, resulting
> >> in
> >> a critical impact on the operation. No workaround is available
> >> 
> >> Examples:
> >> 
> >> Maven crashes on OS-X
> >> Maven goes into infinite loop when installing war artifacts
> >> 
> >> S2: software operates but due to an error, its operation is severely
> >> restricted. No workaround is available
> >> 
> >> Examples:
> >> 
> >> Maven deploys invalid/corrupt artifacts
> >> Maven silently skips tests without asking
> >> Maven ignores batch mode and auto-version submosules for a reactor with
> >> more than 20 modules to release
> >> 
> >> S3: software operates with limitations due to an error that is not
> >> critical
> >> to the overall operation. For example, a workaround forces a user to use
> >> a
> >> time-consuming procedure to operate the software, or removes a
> >> non-essential feature.
> >> 
> >> Examples:
> >> 
> >> Maven has started to prompt with Y/N for each test to be run when
> >> -DconfirmTests=false or when in batch mode.
> >> Maven is stuck logging at debug level
> >> 
> >> S4: software can be used with only slight inconvenience.
> >> 
> >> Examples:
> >> 
> >> Maven colour logging is broken.
> >> Maven is prompting to start execution at the start of the reactor when
> >> not
> >> in batch mode
> >> 
> >> Wdyt
> > 
> > Based on that, what severity would be assigned to the following issues?
> > This somehow lacks the "changes incorrect/unexpected/broken behaviour"
> > category we hopefully do not have to use that often. Some real-world
> > examples we can use to sort things out.
> > 
> > Bugs:
> > -
> > MRESOLVER-8
> > MRESOLVER-9
> > MNG-5359
> > MNG-5984
> > MNG-6114
> > MNG-6164
> > MNG-5227 (ModelBuilder part only - resolver does it since years)
> > MNG-5935
> > MNG-6135 (bug we discussed to death already)
> > 
> > RFEs:
> > -
> > MNG-4463 (or bug due to lack of support?)
> > MNG-5527 (or bug due to lack of support?)
> > MNG-5600 (or bug due to lack of support?)
> > MNG-5971 (currently a new scope - include)
> > MNG-5761+MRESOLVER-10 (or bug - current behaviour
> > unexpected/inconsistent with site)
> 
> Some of them available as pull requests already, in case you want to
> review the changes.
> 
> 
> 
> 
> Regards,



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

Re: [DISCUSS] Towards a common understanding of things

[Hervé BOUTEMY]

ok
there is only one additional point: when things were working previously 
because of special cases that were handled with specific code previously, the 
change has to be done with extra care: that's where the general intent of 
fixing things has the immediate opposite effect

Then always we careful on the idea of "fixing" when it comes to Maven core, 
since the effect is not always limited to the initial intend: there are so 
many plugins, so many situations

Regards,

Hervé

Le lundi 20 mars 2017, 00:20:33 CET Christian Schulte a écrit :
> Am 03/19/17 um 23:32 schrieb Hervé BOUTEMY:
> > for you, documentation is always right?
> > That's the first time I see that documentation is more important and
> > always
> > more accurate than how the tool works
> > 
> > If there is a discrepency between how the tool works and what is written
> > in
> > documentation, there is work to be done to define what part has to be
> > improved to match the other: I don't make any judgement on "fixing", just
> > that the bug is in the discrepency
> 
> That's what I meant with "when there is consensus the
> documentation/specification is stating the intended/correct behaviour"
> First thing to validate is the documentation/specification. If that is
> accurate, work on fixing code can be started. If that is not accurate,
> work on fixing the documentation can be started. Both bugs. Either in
> code or in documentation. That's mainly what I did on the pre-reset
> branches. Make the code match the documentation (site and javadoc) when
> I was sure the documentation is describing the expected behaviour and
> the reports in JIRA were backed by valid analysis or example projects
> demonstrating things are misbehaving.
> 
> Regards,



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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 03/20/17 um 01:47 schrieb Christian Schulte:
> Am 03/20/17 um 01:11 schrieb Stephen Connolly:
>> On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> We need to define:
>>>
>>> * what is a bug vs what is an rfe
>>>
>>> * what are the different severities for bugs and rfes
>>>
>>
>> S1: software is unusable, halts, crashes, or is inaccessible, resulting in
>> a critical impact on the operation. No workaround is available
>>
>> Examples:
>>
>> Maven crashes on OS-X
>> Maven goes into infinite loop when installing war artifacts
>>
>> S2: software operates but due to an error, its operation is severely
>> restricted. No workaround is available
>>
>> Examples:
>>
>> Maven deploys invalid/corrupt artifacts
>> Maven silently skips tests without asking
>> Maven ignores batch mode and auto-version submosules for a reactor with
>> more than 20 modules to release
>>
>> S3: software operates with limitations due to an error that is not critical
>> to the overall operation. For example, a workaround forces a user to use a
>> time-consuming procedure to operate the software, or removes a
>> non-essential feature.
>>
>> Examples:
>>
>> Maven has started to prompt with Y/N for each test to be run when
>> -DconfirmTests=false or when in batch mode.
>> Maven is stuck logging at debug level
>>
>> S4: software can be used with only slight inconvenience.
>>
>> Examples:
>>
>> Maven colour logging is broken.
>> Maven is prompting to start execution at the start of the reactor when not
>> in batch mode
>>
>> Wdyt
> 
> Based on that, what severity would be assigned to the following issues?
> This somehow lacks the "changes incorrect/unexpected/broken behaviour"
> category we hopefully do not have to use that often. Some real-world
> examples we can use to sort things out.
> 
> Bugs:
> -
> MRESOLVER-8
> MRESOLVER-9
> MNG-5359
> MNG-5984
> MNG-6114
> MNG-6164
> MNG-5227 (ModelBuilder part only - resolver does it since years)
> MNG-5935
> MNG-6135 (bug we discussed to death already)
> 
> RFEs:
> -
> MNG-4463 (or bug due to lack of support?)
> MNG-5527 (or bug due to lack of support?)
> MNG-5600 (or bug due to lack of support?)
> MNG-5971 (currently a new scope - include)
> MNG-5761+MRESOLVER-10 (or bug - current behaviour
> unexpected/inconsistent with site)
> 

Some of them available as pull requests already, in case you want to
review the changes.




Regards,
-- 
Christian


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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 03/20/17 um 01:11 schrieb Stephen Connolly:
> On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>> We need to define:
>>
>> * what is a bug vs what is an rfe
>>
>> * what are the different severities for bugs and rfes
>>
> 
> S1: software is unusable, halts, crashes, or is inaccessible, resulting in
> a critical impact on the operation. No workaround is available
> 
> Examples:
> 
> Maven crashes on OS-X
> Maven goes into infinite loop when installing war artifacts
> 
> S2: software operates but due to an error, its operation is severely
> restricted. No workaround is available
> 
> Examples:
> 
> Maven deploys invalid/corrupt artifacts
> Maven silently skips tests without asking
> Maven ignores batch mode and auto-version submosules for a reactor with
> more than 20 modules to release
> 
> S3: software operates with limitations due to an error that is not critical
> to the overall operation. For example, a workaround forces a user to use a
> time-consuming procedure to operate the software, or removes a
> non-essential feature.
> 
> Examples:
> 
> Maven has started to prompt with Y/N for each test to be run when
> -DconfirmTests=false or when in batch mode.
> Maven is stuck logging at debug level
> 
> S4: software can be used with only slight inconvenience.
> 
> Examples:
> 
> Maven colour logging is broken.
> Maven is prompting to start execution at the start of the reactor when not
> in batch mode
> 
> Wdyt

Based on that, what severity would be assigned to the following issues?
This somehow lacks the "changes incorrect/unexpected/broken behaviour"
category we hopefully do not have to use that often. Some real-world
examples we can use to sort things out.

Bugs:
-
MRESOLVER-8
MRESOLVER-9
MNG-5359
MNG-5984
MNG-6114
MNG-6164
MNG-5227 (ModelBuilder part only - resolver does it since years)
MNG-5935
MNG-6135 (bug we discussed to death already)

RFEs:
-
MNG-4463 (or bug due to lack of support?)
MNG-5527 (or bug due to lack of support?)
MNG-5600 (or bug due to lack of support?)
MNG-5971 (currently a new scope - include)
MNG-5761+MRESOLVER-10 (or bug - current behaviour
unexpected/inconsistent with site)


Regards,
-- 
Christian


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

Re: [DISCUSS] Towards a common understanding of things

[Stephen Connolly]

On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We need to define:
>
> * what is a bug vs what is an rfe
>
> * what are the different severities for bugs and rfes
>

S1: software is unusable, halts, crashes, or is inaccessible, resulting in
a critical impact on the operation. No workaround is available

Examples:

Maven crashes on OS-X
Maven goes into infinite loop when installing war artifacts

S2: software operates but due to an error, its operation is severely
restricted. No workaround is available

Examples:

Maven deploys invalid/corrupt artifacts
Maven silently skips tests without asking
Maven ignores batch mode and auto-version submosules for a reactor with
more than 20 modules to release

S3: software operates with limitations due to an error that is not critical
to the overall operation. For example, a workaround forces a user to use a
time-consuming procedure to operate the software, or removes a
non-essential feature.

Examples:

Maven has started to prompt with Y/N for each test to be run when
-DconfirmTests=false or when in batch mode.
Maven is stuck logging at debug level

S4: software can be used with only slight inconvenience.

Examples:

Maven colour logging is broken.
Maven is prompting to start execution at the start of the reactor when not
in batch mode

Wdyt


> * what severity bugs block: an alpha, a beta, a full release
>
> * what do the different release types mean? (My take, alpha is not feature
> complete, beta is not free of bugs, rc is hopefully the real deal)
>
> * how do we decide when to bump major, minor and patch version numbers and
> what scope of changes should be allowed in a non-patch bump
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 03/19/17 um 23:32 schrieb Hervé BOUTEMY:
> for you, documentation is always right?
> That's the first time I see that documentation is more important and always 
> more accurate than how the tool works
> 
> If there is a discrepency between how the tool works and what is written in 
> documentation, there is work to be done to define what part has to be 
> improved 
> to match the other: I don't make any judgement on "fixing", just that the bug 
> is in the discrepency

That's what I meant with "when there is consensus the
documentation/specification is stating the intended/correct behaviour"
First thing to validate is the documentation/specification. If that is
accurate, work on fixing code can be started. If that is not accurate,
work on fixing the documentation can be started. Both bugs. Either in
code or in documentation. That's mainly what I did on the pre-reset
branches. Make the code match the documentation (site and javadoc) when
I was sure the documentation is describing the expected behaviour and
the reports in JIRA were backed by valid analysis or example projects
demonstrating things are misbehaving.

Regards,
-- 
Christian


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

Re: [DISCUSS] Towards a common understanding of things

[Hervé BOUTEMY]

for you, documentation is always right?
That's the first time I see that documentation is more important and always 
more accurate than how the tool works

If there is a discrepency between how the tool works and what is written in 
documentation, there is work to be done to define what part has to be improved 
to match the other: I don't make any judgement on "fixing", just that the bug 
is in the discrepency

Regards,

Hervé

Le dimanche 19 mars 2017, 18:09:31 CET Christian Schulte a écrit :
> Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> > We need to define:
> > 
> > * what is a bug vs what is an rfe
> 
> I'll give it a try. Everything not working as documented/specified is a
> bug, when there is consensus the documentation/specification is stating
> the intended/correct behaviour. The design document on Maven
> fundamentals we have is the Maven site. That is what users are reading
> to learn Maven. There have been reports in JIRA telling us something
> does not behave as documented. That's bugs, IMHO. Means we should put
> more effort into that documentation and should never implement anything
> without documenting it on the site. The release notes are not the right
> place to do this.
> 
> 
> -
> 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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> We need to define:
> 
> * what is a bug vs what is an rfe

I'll give it a try. Everything not working as documented/specified is a
bug, when there is consensus the documentation/specification is stating
the intended/correct behaviour. The design document on Maven
fundamentals we have is the Maven site. That is what users are reading
to learn Maven. There have been reports in JIRA telling us something
does not behave as documented. That's bugs, IMHO. Means we should put
more effort into that documentation and should never implement anything
without documenting it on the site. The release notes are not the right
place to do this.


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

Re: [DISCUSS] Towards a common understanding of things

[Stephen Connolly]

Please let's keep this for the other thread I am trying to start off.

It's really related to how we work with branches and how we use CI

(But that is a more complex thread to kick off)

So let's keep this thread on topic please

On Sun 19 Mar 2017 at 15:59, Christian Schulte  wrote:

> Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> > We need to define:
> >
> > * what is a bug vs what is an rfe
> >
> > * what are the different severities for bugs and rfes
> >
> > * what severity bugs block: an alpha, a beta, a full release
> >
> > * what do the different release types mean? (My take, alpha is not
> feature
> > complete, beta is not free of bugs, rc is hopefully the real deal)
> >
> > * how do we decide when to bump major, minor and patch version numbers
> and
> > what scope of changes should be allowed in a non-patch bump
> >
>
> I'd like to add
>
> * how to commit to branches carrying the next release (master)? We are
> coming from everyone just commits to master as needed. Now everyone is
> creating branches and then merges that to master. Does not make much of
> a difference. What I do not like is that currently no one is testing
> things from branches of someone else. I am working with 3.5.0-SNAPSHOT
> (3.4.0-SNAPSHOT) locally for more than a year. A lot of testing no
> longer taking place the way we work with branches now. Maybe we should
> create a dedicated dev or snapshot branch everyone can merge to which
> then gets merged to master by some release manager when it's time to do.
> Process to create a release would be something like:
>
> - merge the snapshot/dev branch to master
> - release:prepare release:perform on master
> - merge the master branch with the next snapshot version back to the
> snapshot/dev branch
> - continue there until next release
>
> 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

Re: [DISCUSS] Towards a common understanding of things

[Christian Schulte]

Am 19.03.2017 um 13:13 schrieb Stephen Connolly:
> We need to define:
> 
> * what is a bug vs what is an rfe
> 
> * what are the different severities for bugs and rfes
> 
> * what severity bugs block: an alpha, a beta, a full release
> 
> * what do the different release types mean? (My take, alpha is not feature
> complete, beta is not free of bugs, rc is hopefully the real deal)
> 
> * how do we decide when to bump major, minor and patch version numbers and
> what scope of changes should be allowed in a non-patch bump
> 

I'd like to add

* how to commit to branches carrying the next release (master)? We are
coming from everyone just commits to master as needed. Now everyone is
creating branches and then merges that to master. Does not make much of
a difference. What I do not like is that currently no one is testing
things from branches of someone else. I am working with 3.5.0-SNAPSHOT
(3.4.0-SNAPSHOT) locally for more than a year. A lot of testing no
longer taking place the way we work with branches now. Maybe we should
create a dedicated dev or snapshot branch everyone can merge to which
then gets merged to master by some release manager when it's time to do.
Process to create a release would be something like:

- merge the snapshot/dev branch to master
- release:prepare release:perform on master
- merge the master branch with the next snapshot version back to the
snapshot/dev branch
- continue there until next release

Regards,
-- 
Christian


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

[DISCUSS] Towards a common understanding of things

[Stephen Connolly]

We need to define:

* what is a bug vs what is an rfe

* what are the different severities for bugs and rfes

* what severity bugs block: an alpha, a beta, a full release

* what do the different release types mean? (My take, alpha is not feature
complete, beta is not free of bugs, rc is hopefully the real deal)

* how do we decide when to bump major, minor and patch version numbers and
what scope of changes should be allowed in a non-patch bump
-- 
Sent from my phone