You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Enrico Olivelli <eo...@gmail.com> on 2019/09/02 17:59:01 UTC
Re: Draft of release notes for Maven 3.6.2
Any suggestion ?
I am leaning towards creating a single list of "Contributors" and a list of
"Reporters"
I have to close the VOTE, I will wait to reach consensus on this release
notes stuff before closing the vote.
Enrico
Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
tibordigana@apache.org> ha scritto:
> We have contributors listed directly in the POM
> https://github.com/apache/maven/blob/master/pom.xml#L120
> If we started with this great idea to list contributors in POM, we should
> continue with it and this is the same privilege for future contributurs as
> well. They will be listed on the Maven sites which is a big Thx from us
> ASF/Maven for them.
> Enrico, you have hard time because you are doing it only by your hands. Why
> not to ask the contributor to add himself to the POM while the pull-request
> is open? This would simplify your work with the release and then the
> release notes is more simple to do.
>
> For instance in the JUnit4 group the author and contributor is writing the
> release notes on Wiki. It is part of the normal work, otherwise it is
> incomplete.
> I was also asked by the comitter to describe the fix/feature on Wiki in
> JUnit4. But there must be writtent rules and culture in the team to remind
> the contributor to write the release notes.
> You as committer cannot compete with a large number of contributors!
> The contributors must understand that the work is not only about Java code,
> it is also documentation of whatever manner.
>
> Also we should ask a contributor whether he wants to be in the list, but we
> cannot ignore the contributor in the list.
> And what is the next fact, the list of contributors exists for some time.
> We should continue in this tradition and we should pickup a new commiter
> from this list. It is simple because we can see that some contributors are
> more active than the others and we can see it based on the the number of
> issues MNG-xxxxx. We will very hardly "decompile" the release notes and
> find such statistics. We can do it only in JIRA.
> But still "reporter" is important because without him the idea would not
> exist and this is important for users, I mean the idea, but contributor
> will be always in the development team or in the users which is the matter
> of time when somebody writes the code. Contributors are important for
> development and us in ASF but the reporter is relevant for users because he
> is the architect of "business idea" - of course it is not the same as in
> the enterprise. In the enterprise, the customer does not care who is
> contributor ala developer, he cares about the work done for him.
>
> On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > In my opinion release notes should tell:
> > - new features/news and noteworthy
> > - user visible changes
> > - breaking changes
> >
> > I would add a list of contributors.
> > The list of 'reporters' is not useful.
> >
> > I see we are doing those lists in order to have a better engagement with
> > the community, but I am not sure at 100% it is something that should stay
> > forever on the website, maybe it can be in the announcement email.
> >
> > I have used the release notes of 3.6.1 as template, to me it is not a
> > problem to shrink the list making some sort of select
> > 'distict(reportername)', distinct(contributor name).
> >
> > Enrico
> >
> > Il sab 31 ago 2019, 11:17 Tibor Digana <ti...@apache.org> ha
> > scritto:
> >
> > > For me and many users the Release Note like this are very hard to read
> > and
> > > hard to find what is needed.
> > > Many times they go to google because it's easier to search than walking
> > > through all versions of release notes.
> > >
> > > We do not have a cumulative documentation with a list of features and
> we
> > > often point to release notes whenever any uaser is asking about feature
> > or
> > > for a problem that he has in his build.
> > >
> > > If it was only up to me, I would have the cumulative documentation(s)
> > which
> > > is in one folder, and another documents would be Jira Report generated
> by
> > > "reporting" and this would include the author in the table - easy and
> > > automated.
> > > IMO it should be just like in the plugins - every feature fully
> > documented
> > > in src/site/../*.apt and pushed with the code and tests to master in
> one
> > > commit.
> > >
> > > Then the Release Notes would be a matter of command line "mvn site
> ...".
> > >
> > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte <rf...@apache.org>
> > > wrote:
> > >
> > > > The goal of release notes is that they are being read.
> > > > There should be a good balance of the amount of information,
> preventing
> > > > people to say TLDR;
> > > >
> > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful
> > information.
> > > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting the
> > > > related Jira page will provide you the extra information, including
> the
> > > > actual reporter and contributors.
> > > >
> > > > Summing up a list of names that helped on the release is a good way
> to
> > > > appreciate their help on this release.
> > > >
> > > > Robert
> > > >
> > > >
> > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <
> > tibordigana@apache.org
> > > >
> > > >
> > > > wrote:
> > > >
> > > > > We should use authors of the issue/PR/idea.
> > > > > After the release we can ask WHY (practical goals) he wanted the
> > > feature
> > > > > more than how. The question for "HOW" has to be placed very early
> > > during
> > > > > the review, but too late after the PR has been merged.
> > > > > I expect that the reviewer developer has checked all the code, so
> > there
> > > > > would not be questions about *how* it is done. If the reviewer does
> > not
> > > > > understand the code and he admits the change, then it is question
> for
> > > him
> > > > > whenever a new trouble happens.
> > > > > So this is my opinion - listing the author(s) of the idea in every
> > > > > issue/PR.
> > > > >
> > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <
> > rfscholte@apache.org>
> > > > > wrote:
> > > > >
> > > > >> Not sure if the reader of the release notes is helped with a long
> > list
> > > > >> of
> > > > >> reporters and contributers per issue.
> > > > >> I would expect that only a list of (unique) names is good enough.
> > > > >>
> > > > >> If there is someone that deserves extra credits, I'd say it is
> > Stefan
> > > > >> Oehme for diving into the code, looking for memory leaks AND
> > providing
> > > > >> patches to solve it.
> > > > >>
> > > > >> thanks for pushing this release!
> > > > >> Robert
> > > > >>
> > > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
> > > > >> <eo...@gmail.com>
> > > > >>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi all,
> > > > >> > I have sent a draft of the release notes for 3.6.2
> > > > >> >
> > > > >> > this is the PR
> > > > >> > https://github.com/apache/maven-site/pull/99/files
> > > > >> >
> > > > >> > Feel free to add comments or push fixes directly to the branch.
> > > > >> >
> > > > >> > It still lacks a bit of formatting, but the content is ready
> > > > >> >
> > > > >> > Cheers
> > > > >> > Enrico
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Draft of release notes for Maven 3.6.2
Posted by Tibor Digana <ti...@apache.org>.
We have the contributors in POM. See this
https://github.com/apache/maven/blob/master/pom.xml#L120
This dicussion is also personal opinions which is acceptable for thinking
of new improvements in the release processes. We can always improve them
and simplify.
Next time, I vote for production of AUTOMATED release notes which avoids
eating our private time.
Also i Vote for a separate documentation of features rather than describing
them in release notes (since of 5.0.0).
Usually, the people do not "iterate over" many versions. They want to have
only one looking at Chapters and see a suitable feature, just one lookup.
Therefore I mentioned plugins because they have this approach.
Anyway go ahead with the release. Do not stop yourself. ;-)
Good luck, Enrico.
On Mon, Sep 2, 2019 at 8:37 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Agree, +1 for a single list (see last paragraph for a note on this)
>
> @Tibor: we dont really have a contibutor section in the pom :p. Joke apart,
> it cant be used at all here because it ignores the time slice the report
> requires and does not scale well in time. Jira and git are reliable and
> easily scriptable so no real reason to require yet another manual
> synchro/task and new meta to be able to do the extraction IMHO.
>
> Btw, when listing only contributors for one version, a lot of projects call
> them "release heros", I kind of like this promotion of people who helped
> which abstracts code, doc, test, report etc...It represents well what we
> call "community" IMHO.
>
> Le lun. 2 sept. 2019 à 20:21, Robert Scholte <rf...@apache.org> a
> écrit :
>
> > On Mon, 02 Sep 2019 19:59:01 +0200, Enrico Olivelli <eolivelli@gmail.com
> >
> >
> > wrote:
> >
> > > Any suggestion ?
> > > I am leaning towards creating a single list of "Contributors" and a
> > list
> > > of
> > > "Reporters"
> >
> > I agree with Romain that we're kind of mixing the different kind of
> > reports, but in all cases every block of text needs to add value and it
> > should be compact, though easy to read/overview. Compressing reporters
> > and
> > contributors to a list (or comma separated line) makes sense to me.
> >
> > Robert
> >
> > >
> > > I have to close the VOTE, I will wait to reach consensus on this
> release
> > > notes stuff before closing the vote.
> > >
> > > Enrico
> > >
> > > Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
> > > tibordigana@apache.org> ha scritto:
> > >
> > >> We have contributors listed directly in the POM
> > >> https://github.com/apache/maven/blob/master/pom.xml#L120
> > >> If we started with this great idea to list contributors in POM, we
> > >> should
> > >> continue with it and this is the same privilege for future
> > contributurs
> > >> as
> > >> well. They will be listed on the Maven sites which is a big Thx from
> us
> > >> ASF/Maven for them.
> > >> Enrico, you have hard time because you are doing it only by your
> > hands.
> > >> Why
> > >> not to ask the contributor to add himself to the POM while the
> > >> pull-request
> > >> is open? This would simplify your work with the release and then the
> > >> release notes is more simple to do.
> > >>
> > >> For instance in the JUnit4 group the author and contributor is writing
> > >> the
> > >> release notes on Wiki. It is part of the normal work, otherwise it is
> > >> incomplete.
> > >> I was also asked by the comitter to describe the fix/feature on Wiki
> in
> > >> JUnit4. But there must be writtent rules and culture in the team to
> > >> remind
> > >> the contributor to write the release notes.
> > >> You as committer cannot compete with a large number of contributors!
> > >> The contributors must understand that the work is not only about Java
> > >> code,
> > >> it is also documentation of whatever manner.
> > >>
> > >> Also we should ask a contributor whether he wants to be in the list,
> > >> but we
> > >> cannot ignore the contributor in the list.
> > >> And what is the next fact, the list of contributors exists for some
> > >> time.
> > >> We should continue in this tradition and we should pickup a new
> commiter
> > >> from this list. It is simple because we can see that some contributors
> > >> are
> > >> more active than the others and we can see it based on the the number
> of
> > >> issues MNG-xxxxx. We will very hardly "decompile" the release notes
> and
> > >> find such statistics. We can do it only in JIRA.
> > >> But still "reporter" is important because without him the idea would
> not
> > >> exist and this is important for users, I mean the idea, but
> contributor
> > >> will be always in the development team or in the users which is the
> > >> matter
> > >> of time when somebody writes the code. Contributors are important for
> > >> development and us in ASF but the reporter is relevant for users
> > >> because he
> > >> is the architect of "business idea" - of course it is not the same as
> in
> > >> the enterprise. In the enterprise, the customer does not care who is
> > >> contributor ala developer, he cares about the work done for him.
> > >>
> > >> On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eo...@gmail.com>
> > >> wrote:
> > >>
> > >> > In my opinion release notes should tell:
> > >> > - new features/news and noteworthy
> > >> > - user visible changes
> > >> > - breaking changes
> > >> >
> > >> > I would add a list of contributors.
> > >> > The list of 'reporters' is not useful.
> > >> >
> > >> > I see we are doing those lists in order to have a better engagement
> > >> with
> > >> > the community, but I am not sure at 100% it is something that should
> > >> stay
> > >> > forever on the website, maybe it can be in the announcement email.
> > >> >
> > >> > I have used the release notes of 3.6.1 as template, to me it is not
> a
> > >> > problem to shrink the list making some sort of select
> > >> > 'distict(reportername)', distinct(contributor name).
> > >> >
> > >> > Enrico
> > >> >
> > >> > Il sab 31 ago 2019, 11:17 Tibor Digana <ti...@apache.org> ha
> > >> > scritto:
> > >> >
> > >> > > For me and many users the Release Note like this are very hard to
> > >> read
> > >> > and
> > >> > > hard to find what is needed.
> > >> > > Many times they go to google because it's easier to search than
> > >> walking
> > >> > > through all versions of release notes.
> > >> > >
> > >> > > We do not have a cumulative documentation with a list of features
> > >> and
> > >> we
> > >> > > often point to release notes whenever any uaser is asking about
> > >> feature
> > >> > or
> > >> > > for a problem that he has in his build.
> > >> > >
> > >> > > If it was only up to me, I would have the cumulative
> > >> documentation(s)
> > >> > which
> > >> > > is in one folder, and another documents would be Jira Report
> > >> generated
> > >> by
> > >> > > "reporting" and this would include the author in the table - easy
> > >> and
> > >> > > automated.
> > >> > > IMO it should be just like in the plugins - every feature fully
> > >> > documented
> > >> > > in src/site/../*.apt and pushed with the code and tests to master
> in
> > >> one
> > >> > > commit.
> > >> > >
> > >> > > Then the Release Notes would be a matter of command line "mvn site
> > >> ...".
> > >> > >
> > >> > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte
> > >> <rf...@apache.org>
> > >> > > wrote:
> > >> > >
> > >> > > > The goal of release notes is that they are being read.
> > >> > > > There should be a good balance of the amount of information,
> > >> preventing
> > >> > > > people to say TLDR;
> > >> > > >
> > >> > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful
> > >> > information.
> > >> > > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting
> > >> the
> > >> > > > related Jira page will provide you the extra information,
> > >> including
> > >> the
> > >> > > > actual reporter and contributors.
> > >> > > >
> > >> > > > Summing up a list of names that helped on the release is a good
> > >> way
> > >> to
> > >> > > > appreciate their help on this release.
> > >> > > >
> > >> > > > Robert
> > >> > > >
> > >> > > >
> > >> > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <
> > >> > tibordigana@apache.org
> > >> > > >
> > >> > > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > We should use authors of the issue/PR/idea.
> > >> > > > > After the release we can ask WHY (practical goals) he wanted
> the
> > >> > > feature
> > >> > > > > more than how. The question for "HOW" has to be placed very
> > >> early
> > >> > > during
> > >> > > > > the review, but too late after the PR has been merged.
> > >> > > > > I expect that the reviewer developer has checked all the code,
> > >> so
> > >> > there
> > >> > > > > would not be questions about *how* it is done. If the reviewer
> > >> does
> > >> > not
> > >> > > > > understand the code and he admits the change, then it is
> > >> question
> > >> for
> > >> > > him
> > >> > > > > whenever a new trouble happens.
> > >> > > > > So this is my opinion - listing the author(s) of the idea in
> > >> every
> > >> > > > > issue/PR.
> > >> > > > >
> > >> > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <
> > >> > rfscholte@apache.org>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > >> Not sure if the reader of the release notes is helped with a
> > >> long
> > >> > list
> > >> > > > >> of
> > >> > > > >> reporters and contributers per issue.
> > >> > > > >> I would expect that only a list of (unique) names is good
> > >> enough.
> > >> > > > >>
> > >> > > > >> If there is someone that deserves extra credits, I'd say it
> is
> > >> > Stefan
> > >> > > > >> Oehme for diving into the code, looking for memory leaks AND
> > >> > providing
> > >> > > > >> patches to solve it.
> > >> > > > >>
> > >> > > > >> thanks for pushing this release!
> > >> > > > >> Robert
> > >> > > > >>
> > >> > > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
> > >> > > > >> <eo...@gmail.com>
> > >> > > > >>
> > >> > > > >> wrote:
> > >> > > > >>
> > >> > > > >> > Hi all,
> > >> > > > >> > I have sent a draft of the release notes for 3.6.2
> > >> > > > >> >
> > >> > > > >> > this is the PR
> > >> > > > >> > https://github.com/apache/maven-site/pull/99/files
> > >> > > > >> >
> > >> > > > >> > Feel free to add comments or push fixes directly to the
> > >> branch.
> > >> > > > >> >
> > >> > > > >> > It still lacks a bit of formatting, but the content is
> ready
> > >> > > > >> >
> > >> > > > >> > Cheers
> > >> > > > >> > Enrico
> > >> > > > >>
> > >> > > > >>
> > >> >
> ---------------------------------------------------------------------
> > >> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> > > > >>
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Draft of release notes for Maven 3.6.2
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Agree, +1 for a single list (see last paragraph for a note on this)
@Tibor: we dont really have a contibutor section in the pom :p. Joke apart,
it cant be used at all here because it ignores the time slice the report
requires and does not scale well in time. Jira and git are reliable and
easily scriptable so no real reason to require yet another manual
synchro/task and new meta to be able to do the extraction IMHO.
Btw, when listing only contributors for one version, a lot of projects call
them "release heros", I kind of like this promotion of people who helped
which abstracts code, doc, test, report etc...It represents well what we
call "community" IMHO.
Le lun. 2 sept. 2019 à 20:21, Robert Scholte <rf...@apache.org> a
écrit :
> On Mon, 02 Sep 2019 19:59:01 +0200, Enrico Olivelli <eo...@gmail.com>
>
> wrote:
>
> > Any suggestion ?
> > I am leaning towards creating a single list of "Contributors" and a
> list
> > of
> > "Reporters"
>
> I agree with Romain that we're kind of mixing the different kind of
> reports, but in all cases every block of text needs to add value and it
> should be compact, though easy to read/overview. Compressing reporters
> and
> contributors to a list (or comma separated line) makes sense to me.
>
> Robert
>
> >
> > I have to close the VOTE, I will wait to reach consensus on this release
> > notes stuff before closing the vote.
> >
> > Enrico
> >
> > Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
> > tibordigana@apache.org> ha scritto:
> >
> >> We have contributors listed directly in the POM
> >> https://github.com/apache/maven/blob/master/pom.xml#L120
> >> If we started with this great idea to list contributors in POM, we
> >> should
> >> continue with it and this is the same privilege for future
> contributurs
> >> as
> >> well. They will be listed on the Maven sites which is a big Thx from us
> >> ASF/Maven for them.
> >> Enrico, you have hard time because you are doing it only by your
> hands.
> >> Why
> >> not to ask the contributor to add himself to the POM while the
> >> pull-request
> >> is open? This would simplify your work with the release and then the
> >> release notes is more simple to do.
> >>
> >> For instance in the JUnit4 group the author and contributor is writing
> >> the
> >> release notes on Wiki. It is part of the normal work, otherwise it is
> >> incomplete.
> >> I was also asked by the comitter to describe the fix/feature on Wiki in
> >> JUnit4. But there must be writtent rules and culture in the team to
> >> remind
> >> the contributor to write the release notes.
> >> You as committer cannot compete with a large number of contributors!
> >> The contributors must understand that the work is not only about Java
> >> code,
> >> it is also documentation of whatever manner.
> >>
> >> Also we should ask a contributor whether he wants to be in the list,
> >> but we
> >> cannot ignore the contributor in the list.
> >> And what is the next fact, the list of contributors exists for some
> >> time.
> >> We should continue in this tradition and we should pickup a new commiter
> >> from this list. It is simple because we can see that some contributors
> >> are
> >> more active than the others and we can see it based on the the number of
> >> issues MNG-xxxxx. We will very hardly "decompile" the release notes and
> >> find such statistics. We can do it only in JIRA.
> >> But still "reporter" is important because without him the idea would not
> >> exist and this is important for users, I mean the idea, but contributor
> >> will be always in the development team or in the users which is the
> >> matter
> >> of time when somebody writes the code. Contributors are important for
> >> development and us in ASF but the reporter is relevant for users
> >> because he
> >> is the architect of "business idea" - of course it is not the same as in
> >> the enterprise. In the enterprise, the customer does not care who is
> >> contributor ala developer, he cares about the work done for him.
> >>
> >> On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eo...@gmail.com>
> >> wrote:
> >>
> >> > In my opinion release notes should tell:
> >> > - new features/news and noteworthy
> >> > - user visible changes
> >> > - breaking changes
> >> >
> >> > I would add a list of contributors.
> >> > The list of 'reporters' is not useful.
> >> >
> >> > I see we are doing those lists in order to have a better engagement
> >> with
> >> > the community, but I am not sure at 100% it is something that should
> >> stay
> >> > forever on the website, maybe it can be in the announcement email.
> >> >
> >> > I have used the release notes of 3.6.1 as template, to me it is not a
> >> > problem to shrink the list making some sort of select
> >> > 'distict(reportername)', distinct(contributor name).
> >> >
> >> > Enrico
> >> >
> >> > Il sab 31 ago 2019, 11:17 Tibor Digana <ti...@apache.org> ha
> >> > scritto:
> >> >
> >> > > For me and many users the Release Note like this are very hard to
> >> read
> >> > and
> >> > > hard to find what is needed.
> >> > > Many times they go to google because it's easier to search than
> >> walking
> >> > > through all versions of release notes.
> >> > >
> >> > > We do not have a cumulative documentation with a list of features
> >> and
> >> we
> >> > > often point to release notes whenever any uaser is asking about
> >> feature
> >> > or
> >> > > for a problem that he has in his build.
> >> > >
> >> > > If it was only up to me, I would have the cumulative
> >> documentation(s)
> >> > which
> >> > > is in one folder, and another documents would be Jira Report
> >> generated
> >> by
> >> > > "reporting" and this would include the author in the table - easy
> >> and
> >> > > automated.
> >> > > IMO it should be just like in the plugins - every feature fully
> >> > documented
> >> > > in src/site/../*.apt and pushed with the code and tests to master in
> >> one
> >> > > commit.
> >> > >
> >> > > Then the Release Notes would be a matter of command line "mvn site
> >> ...".
> >> > >
> >> > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte
> >> <rf...@apache.org>
> >> > > wrote:
> >> > >
> >> > > > The goal of release notes is that they are being read.
> >> > > > There should be a good balance of the amount of information,
> >> preventing
> >> > > > people to say TLDR;
> >> > > >
> >> > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful
> >> > information.
> >> > > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting
> >> the
> >> > > > related Jira page will provide you the extra information,
> >> including
> >> the
> >> > > > actual reporter and contributors.
> >> > > >
> >> > > > Summing up a list of names that helped on the release is a good
> >> way
> >> to
> >> > > > appreciate their help on this release.
> >> > > >
> >> > > > Robert
> >> > > >
> >> > > >
> >> > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <
> >> > tibordigana@apache.org
> >> > > >
> >> > > >
> >> > > > wrote:
> >> > > >
> >> > > > > We should use authors of the issue/PR/idea.
> >> > > > > After the release we can ask WHY (practical goals) he wanted the
> >> > > feature
> >> > > > > more than how. The question for "HOW" has to be placed very
> >> early
> >> > > during
> >> > > > > the review, but too late after the PR has been merged.
> >> > > > > I expect that the reviewer developer has checked all the code,
> >> so
> >> > there
> >> > > > > would not be questions about *how* it is done. If the reviewer
> >> does
> >> > not
> >> > > > > understand the code and he admits the change, then it is
> >> question
> >> for
> >> > > him
> >> > > > > whenever a new trouble happens.
> >> > > > > So this is my opinion - listing the author(s) of the idea in
> >> every
> >> > > > > issue/PR.
> >> > > > >
> >> > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <
> >> > rfscholte@apache.org>
> >> > > > > wrote:
> >> > > > >
> >> > > > >> Not sure if the reader of the release notes is helped with a
> >> long
> >> > list
> >> > > > >> of
> >> > > > >> reporters and contributers per issue.
> >> > > > >> I would expect that only a list of (unique) names is good
> >> enough.
> >> > > > >>
> >> > > > >> If there is someone that deserves extra credits, I'd say it is
> >> > Stefan
> >> > > > >> Oehme for diving into the code, looking for memory leaks AND
> >> > providing
> >> > > > >> patches to solve it.
> >> > > > >>
> >> > > > >> thanks for pushing this release!
> >> > > > >> Robert
> >> > > > >>
> >> > > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
> >> > > > >> <eo...@gmail.com>
> >> > > > >>
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >> > Hi all,
> >> > > > >> > I have sent a draft of the release notes for 3.6.2
> >> > > > >> >
> >> > > > >> > this is the PR
> >> > > > >> > https://github.com/apache/maven-site/pull/99/files
> >> > > > >> >
> >> > > > >> > Feel free to add comments or push fixes directly to the
> >> branch.
> >> > > > >> >
> >> > > > >> > It still lacks a bit of formatting, but the content is ready
> >> > > > >> >
> >> > > > >> > Cheers
> >> > > > >> > Enrico
> >> > > > >>
> >> > > > >>
> >> > ---------------------------------------------------------------------
> >> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> >> > > > >>
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > > >
> >> > > >
> >> > >
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Draft of release notes for Maven 3.6.2
Posted by Robert Scholte <rf...@apache.org>.
On Mon, 02 Sep 2019 19:59:01 +0200, Enrico Olivelli <eo...@gmail.com>
wrote:
> Any suggestion ?
> I am leaning towards creating a single list of "Contributors" and a list
> of
> "Reporters"
I agree with Romain that we're kind of mixing the different kind of
reports, but in all cases every block of text needs to add value and it
should be compact, though easy to read/overview. Compressing reporters and
contributors to a list (or comma separated line) makes sense to me.
Robert
>
> I have to close the VOTE, I will wait to reach consensus on this release
> notes stuff before closing the vote.
>
> Enrico
>
> Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
> tibordigana@apache.org> ha scritto:
>
>> We have contributors listed directly in the POM
>> https://github.com/apache/maven/blob/master/pom.xml#L120
>> If we started with this great idea to list contributors in POM, we
>> should
>> continue with it and this is the same privilege for future contributurs
>> as
>> well. They will be listed on the Maven sites which is a big Thx from us
>> ASF/Maven for them.
>> Enrico, you have hard time because you are doing it only by your hands.
>> Why
>> not to ask the contributor to add himself to the POM while the
>> pull-request
>> is open? This would simplify your work with the release and then the
>> release notes is more simple to do.
>>
>> For instance in the JUnit4 group the author and contributor is writing
>> the
>> release notes on Wiki. It is part of the normal work, otherwise it is
>> incomplete.
>> I was also asked by the comitter to describe the fix/feature on Wiki in
>> JUnit4. But there must be writtent rules and culture in the team to
>> remind
>> the contributor to write the release notes.
>> You as committer cannot compete with a large number of contributors!
>> The contributors must understand that the work is not only about Java
>> code,
>> it is also documentation of whatever manner.
>>
>> Also we should ask a contributor whether he wants to be in the list,
>> but we
>> cannot ignore the contributor in the list.
>> And what is the next fact, the list of contributors exists for some
>> time.
>> We should continue in this tradition and we should pickup a new commiter
>> from this list. It is simple because we can see that some contributors
>> are
>> more active than the others and we can see it based on the the number of
>> issues MNG-xxxxx. We will very hardly "decompile" the release notes and
>> find such statistics. We can do it only in JIRA.
>> But still "reporter" is important because without him the idea would not
>> exist and this is important for users, I mean the idea, but contributor
>> will be always in the development team or in the users which is the
>> matter
>> of time when somebody writes the code. Contributors are important for
>> development and us in ASF but the reporter is relevant for users
>> because he
>> is the architect of "business idea" - of course it is not the same as in
>> the enterprise. In the enterprise, the customer does not care who is
>> contributor ala developer, he cares about the work done for him.
>>
>> On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eo...@gmail.com>
>> wrote:
>>
>> > In my opinion release notes should tell:
>> > - new features/news and noteworthy
>> > - user visible changes
>> > - breaking changes
>> >
>> > I would add a list of contributors.
>> > The list of 'reporters' is not useful.
>> >
>> > I see we are doing those lists in order to have a better engagement
>> with
>> > the community, but I am not sure at 100% it is something that should
>> stay
>> > forever on the website, maybe it can be in the announcement email.
>> >
>> > I have used the release notes of 3.6.1 as template, to me it is not a
>> > problem to shrink the list making some sort of select
>> > 'distict(reportername)', distinct(contributor name).
>> >
>> > Enrico
>> >
>> > Il sab 31 ago 2019, 11:17 Tibor Digana <ti...@apache.org> ha
>> > scritto:
>> >
>> > > For me and many users the Release Note like this are very hard to
>> read
>> > and
>> > > hard to find what is needed.
>> > > Many times they go to google because it's easier to search than
>> walking
>> > > through all versions of release notes.
>> > >
>> > > We do not have a cumulative documentation with a list of features
>> and
>> we
>> > > often point to release notes whenever any uaser is asking about
>> feature
>> > or
>> > > for a problem that he has in his build.
>> > >
>> > > If it was only up to me, I would have the cumulative
>> documentation(s)
>> > which
>> > > is in one folder, and another documents would be Jira Report
>> generated
>> by
>> > > "reporting" and this would include the author in the table - easy
>> and
>> > > automated.
>> > > IMO it should be just like in the plugins - every feature fully
>> > documented
>> > > in src/site/../*.apt and pushed with the code and tests to master in
>> one
>> > > commit.
>> > >
>> > > Then the Release Notes would be a matter of command line "mvn site
>> ...".
>> > >
>> > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte
>> <rf...@apache.org>
>> > > wrote:
>> > >
>> > > > The goal of release notes is that they are being read.
>> > > > There should be a good balance of the amount of information,
>> preventing
>> > > > people to say TLDR;
>> > > >
>> > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful
>> > information.
>> > > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting
>> the
>> > > > related Jira page will provide you the extra information,
>> including
>> the
>> > > > actual reporter and contributors.
>> > > >
>> > > > Summing up a list of names that helped on the release is a good
>> way
>> to
>> > > > appreciate their help on this release.
>> > > >
>> > > > Robert
>> > > >
>> > > >
>> > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <
>> > tibordigana@apache.org
>> > > >
>> > > >
>> > > > wrote:
>> > > >
>> > > > > We should use authors of the issue/PR/idea.
>> > > > > After the release we can ask WHY (practical goals) he wanted the
>> > > feature
>> > > > > more than how. The question for "HOW" has to be placed very
>> early
>> > > during
>> > > > > the review, but too late after the PR has been merged.
>> > > > > I expect that the reviewer developer has checked all the code,
>> so
>> > there
>> > > > > would not be questions about *how* it is done. If the reviewer
>> does
>> > not
>> > > > > understand the code and he admits the change, then it is
>> question
>> for
>> > > him
>> > > > > whenever a new trouble happens.
>> > > > > So this is my opinion - listing the author(s) of the idea in
>> every
>> > > > > issue/PR.
>> > > > >
>> > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <
>> > rfscholte@apache.org>
>> > > > > wrote:
>> > > > >
>> > > > >> Not sure if the reader of the release notes is helped with a
>> long
>> > list
>> > > > >> of
>> > > > >> reporters and contributers per issue.
>> > > > >> I would expect that only a list of (unique) names is good
>> enough.
>> > > > >>
>> > > > >> If there is someone that deserves extra credits, I'd say it is
>> > Stefan
>> > > > >> Oehme for diving into the code, looking for memory leaks AND
>> > providing
>> > > > >> patches to solve it.
>> > > > >>
>> > > > >> thanks for pushing this release!
>> > > > >> Robert
>> > > > >>
>> > > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
>> > > > >> <eo...@gmail.com>
>> > > > >>
>> > > > >> wrote:
>> > > > >>
>> > > > >> > Hi all,
>> > > > >> > I have sent a draft of the release notes for 3.6.2
>> > > > >> >
>> > > > >> > this is the PR
>> > > > >> > https://github.com/apache/maven-site/pull/99/files
>> > > > >> >
>> > > > >> > Feel free to add comments or push fixes directly to the
>> branch.
>> > > > >> >
>> > > > >> > It still lacks a bit of formatting, but the content is ready
>> > > > >> >
>> > > > >> > Cheers
>> > > > >> > Enrico
>> > > > >>
>> > > > >>
>> > ---------------------------------------------------------------------
>> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
>> > > > >>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >
>> > > >
>> > >
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Draft of release notes for Maven 3.6.2
Posted by Enrico Olivelli <eo...@gmail.com>.
Thank you Gary.
I have updated the draft of release notes:
https://github.com/apache/maven-site/pull/99/files
I am closing the vote now and move forward with the release.
I will use that branch as base for the release notes, we can always
amend/fix/enhance them
Enrico
Il giorno lun 2 set 2019 alle ore 21:52 Gary Gregory <ga...@gmail.com>
ha scritto:
> FWIW, over in Apache Commons, I take the following approach when filling in
> the due-to attribute for an issue in changes.xml: I list the reporter first
> (the person who created the jira or wrote an email, then each person who
> participated in any way in chronological order, even if it is just making a
> good point in a Jira comment in order to guide the fix or feature. Nice and
> simple.
>
> Gary
>
> On Mon, Sep 2, 2019 at 1:59 PM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Any suggestion ?
> > I am leaning towards creating a single list of "Contributors" and a list
> of
> > "Reporters"
> >
> > I have to close the VOTE, I will wait to reach consensus on this release
> > notes stuff before closing the vote.
> >
> > Enrico
> >
> > Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
> > tibordigana@apache.org> ha scritto:
> >
> > > We have contributors listed directly in the POM
> > > https://github.com/apache/maven/blob/master/pom.xml#L120
> > > If we started with this great idea to list contributors in POM, we
> should
> > > continue with it and this is the same privilege for future contributurs
> > as
> > > well. They will be listed on the Maven sites which is a big Thx from us
> > > ASF/Maven for them.
> > > Enrico, you have hard time because you are doing it only by your hands.
> > Why
> > > not to ask the contributor to add himself to the POM while the
> > pull-request
> > > is open? This would simplify your work with the release and then the
> > > release notes is more simple to do.
> > >
> > > For instance in the JUnit4 group the author and contributor is writing
> > the
> > > release notes on Wiki. It is part of the normal work, otherwise it is
> > > incomplete.
> > > I was also asked by the comitter to describe the fix/feature on Wiki in
> > > JUnit4. But there must be writtent rules and culture in the team to
> > remind
> > > the contributor to write the release notes.
> > > You as committer cannot compete with a large number of contributors!
> > > The contributors must understand that the work is not only about Java
> > code,
> > > it is also documentation of whatever manner.
> > >
> > > Also we should ask a contributor whether he wants to be in the list,
> but
> > we
> > > cannot ignore the contributor in the list.
> > > And what is the next fact, the list of contributors exists for some
> time.
> > > We should continue in this tradition and we should pickup a new
> commiter
> > > from this list. It is simple because we can see that some contributors
> > are
> > > more active than the others and we can see it based on the the number
> of
> > > issues MNG-xxxxx. We will very hardly "decompile" the release notes and
> > > find such statistics. We can do it only in JIRA.
> > > But still "reporter" is important because without him the idea would
> not
> > > exist and this is important for users, I mean the idea, but contributor
> > > will be always in the development team or in the users which is the
> > matter
> > > of time when somebody writes the code. Contributors are important for
> > > development and us in ASF but the reporter is relevant for users
> because
> > he
> > > is the architect of "business idea" - of course it is not the same as
> in
> > > the enterprise. In the enterprise, the customer does not care who is
> > > contributor ala developer, he cares about the work done for him.
> > >
> > > On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eo...@gmail.com>
> > > wrote:
> > >
> > > > In my opinion release notes should tell:
> > > > - new features/news and noteworthy
> > > > - user visible changes
> > > > - breaking changes
> > > >
> > > > I would add a list of contributors.
> > > > The list of 'reporters' is not useful.
> > > >
> > > > I see we are doing those lists in order to have a better engagement
> > with
> > > > the community, but I am not sure at 100% it is something that should
> > stay
> > > > forever on the website, maybe it can be in the announcement email.
> > > >
> > > > I have used the release notes of 3.6.1 as template, to me it is not a
> > > > problem to shrink the list making some sort of select
> > > > 'distict(reportername)', distinct(contributor name).
> > > >
> > > > Enrico
> > > >
> > > > Il sab 31 ago 2019, 11:17 Tibor Digana <ti...@apache.org> ha
> > > > scritto:
> > > >
> > > > > For me and many users the Release Note like this are very hard to
> > read
> > > > and
> > > > > hard to find what is needed.
> > > > > Many times they go to google because it's easier to search than
> > walking
> > > > > through all versions of release notes.
> > > > >
> > > > > We do not have a cumulative documentation with a list of features
> and
> > > we
> > > > > often point to release notes whenever any uaser is asking about
> > feature
> > > > or
> > > > > for a problem that he has in his build.
> > > > >
> > > > > If it was only up to me, I would have the cumulative
> documentation(s)
> > > > which
> > > > > is in one folder, and another documents would be Jira Report
> > generated
> > > by
> > > > > "reporting" and this would include the author in the table - easy
> and
> > > > > automated.
> > > > > IMO it should be just like in the plugins - every feature fully
> > > > documented
> > > > > in src/site/../*.apt and pushed with the code and tests to master
> in
> > > one
> > > > > commit.
> > > > >
> > > > > Then the Release Notes would be a matter of command line "mvn site
> > > ...".
> > > > >
> > > > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte <
> > rfscholte@apache.org>
> > > > > wrote:
> > > > >
> > > > > > The goal of release notes is that they are being read.
> > > > > > There should be a good balance of the amount of information,
> > > preventing
> > > > > > people to say TLDR;
> > > > > >
> > > > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful
> > > > information.
> > > > > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting
> the
> > > > > > related Jira page will provide you the extra information,
> including
> > > the
> > > > > > actual reporter and contributors.
> > > > > >
> > > > > > Summing up a list of names that helped on the release is a good
> way
> > > to
> > > > > > appreciate their help on this release.
> > > > > >
> > > > > > Robert
> > > > > >
> > > > > >
> > > > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <
> > > > tibordigana@apache.org
> > > > > >
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > We should use authors of the issue/PR/idea.
> > > > > > > After the release we can ask WHY (practical goals) he wanted
> the
> > > > > feature
> > > > > > > more than how. The question for "HOW" has to be placed very
> early
> > > > > during
> > > > > > > the review, but too late after the PR has been merged.
> > > > > > > I expect that the reviewer developer has checked all the code,
> so
> > > > there
> > > > > > > would not be questions about *how* it is done. If the reviewer
> > does
> > > > not
> > > > > > > understand the code and he admits the change, then it is
> question
> > > for
> > > > > him
> > > > > > > whenever a new trouble happens.
> > > > > > > So this is my opinion - listing the author(s) of the idea in
> > every
> > > > > > > issue/PR.
> > > > > > >
> > > > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <
> > > > rfscholte@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Not sure if the reader of the release notes is helped with a
> > long
> > > > list
> > > > > > >> of
> > > > > > >> reporters and contributers per issue.
> > > > > > >> I would expect that only a list of (unique) names is good
> > enough.
> > > > > > >>
> > > > > > >> If there is someone that deserves extra credits, I'd say it is
> > > > Stefan
> > > > > > >> Oehme for diving into the code, looking for memory leaks AND
> > > > providing
> > > > > > >> patches to solve it.
> > > > > > >>
> > > > > > >> thanks for pushing this release!
> > > > > > >> Robert
> > > > > > >>
> > > > > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
> > > > > > >> <eo...@gmail.com>
> > > > > > >>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > Hi all,
> > > > > > >> > I have sent a draft of the release notes for 3.6.2
> > > > > > >> >
> > > > > > >> > this is the PR
> > > > > > >> > https://github.com/apache/maven-site/pull/99/files
> > > > > > >> >
> > > > > > >> > Feel free to add comments or push fixes directly to the
> > branch.
> > > > > > >> >
> > > > > > >> > It still lacks a bit of formatting, but the content is ready
> > > > > > >> >
> > > > > > >> > Cheers
> > > > > > >> > Enrico
> > > > > > >>
> > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >>
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Draft of release notes for Maven 3.6.2
Posted by Gary Gregory <ga...@gmail.com>.
FWIW, over in Apache Commons, I take the following approach when filling in
the due-to attribute for an issue in changes.xml: I list the reporter first
(the person who created the jira or wrote an email, then each person who
participated in any way in chronological order, even if it is just making a
good point in a Jira comment in order to guide the fix or feature. Nice and
simple.
Gary
On Mon, Sep 2, 2019 at 1:59 PM Enrico Olivelli <eo...@gmail.com> wrote:
> Any suggestion ?
> I am leaning towards creating a single list of "Contributors" and a list of
> "Reporters"
>
> I have to close the VOTE, I will wait to reach consensus on this release
> notes stuff before closing the vote.
>
> Enrico
>
> Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
> tibordigana@apache.org> ha scritto:
>
> > We have contributors listed directly in the POM
> > https://github.com/apache/maven/blob/master/pom.xml#L120
> > If we started with this great idea to list contributors in POM, we should
> > continue with it and this is the same privilege for future contributurs
> as
> > well. They will be listed on the Maven sites which is a big Thx from us
> > ASF/Maven for them.
> > Enrico, you have hard time because you are doing it only by your hands.
> Why
> > not to ask the contributor to add himself to the POM while the
> pull-request
> > is open? This would simplify your work with the release and then the
> > release notes is more simple to do.
> >
> > For instance in the JUnit4 group the author and contributor is writing
> the
> > release notes on Wiki. It is part of the normal work, otherwise it is
> > incomplete.
> > I was also asked by the comitter to describe the fix/feature on Wiki in
> > JUnit4. But there must be writtent rules and culture in the team to
> remind
> > the contributor to write the release notes.
> > You as committer cannot compete with a large number of contributors!
> > The contributors must understand that the work is not only about Java
> code,
> > it is also documentation of whatever manner.
> >
> > Also we should ask a contributor whether he wants to be in the list, but
> we
> > cannot ignore the contributor in the list.
> > And what is the next fact, the list of contributors exists for some time.
> > We should continue in this tradition and we should pickup a new commiter
> > from this list. It is simple because we can see that some contributors
> are
> > more active than the others and we can see it based on the the number of
> > issues MNG-xxxxx. We will very hardly "decompile" the release notes and
> > find such statistics. We can do it only in JIRA.
> > But still "reporter" is important because without him the idea would not
> > exist and this is important for users, I mean the idea, but contributor
> > will be always in the development team or in the users which is the
> matter
> > of time when somebody writes the code. Contributors are important for
> > development and us in ASF but the reporter is relevant for users because
> he
> > is the architect of "business idea" - of course it is not the same as in
> > the enterprise. In the enterprise, the customer does not care who is
> > contributor ala developer, he cares about the work done for him.
> >
> > On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eo...@gmail.com>
> > wrote:
> >
> > > In my opinion release notes should tell:
> > > - new features/news and noteworthy
> > > - user visible changes
> > > - breaking changes
> > >
> > > I would add a list of contributors.
> > > The list of 'reporters' is not useful.
> > >
> > > I see we are doing those lists in order to have a better engagement
> with
> > > the community, but I am not sure at 100% it is something that should
> stay
> > > forever on the website, maybe it can be in the announcement email.
> > >
> > > I have used the release notes of 3.6.1 as template, to me it is not a
> > > problem to shrink the list making some sort of select
> > > 'distict(reportername)', distinct(contributor name).
> > >
> > > Enrico
> > >
> > > Il sab 31 ago 2019, 11:17 Tibor Digana <ti...@apache.org> ha
> > > scritto:
> > >
> > > > For me and many users the Release Note like this are very hard to
> read
> > > and
> > > > hard to find what is needed.
> > > > Many times they go to google because it's easier to search than
> walking
> > > > through all versions of release notes.
> > > >
> > > > We do not have a cumulative documentation with a list of features and
> > we
> > > > often point to release notes whenever any uaser is asking about
> feature
> > > or
> > > > for a problem that he has in his build.
> > > >
> > > > If it was only up to me, I would have the cumulative documentation(s)
> > > which
> > > > is in one folder, and another documents would be Jira Report
> generated
> > by
> > > > "reporting" and this would include the author in the table - easy and
> > > > automated.
> > > > IMO it should be just like in the plugins - every feature fully
> > > documented
> > > > in src/site/../*.apt and pushed with the code and tests to master in
> > one
> > > > commit.
> > > >
> > > > Then the Release Notes would be a matter of command line "mvn site
> > ...".
> > > >
> > > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte <
> rfscholte@apache.org>
> > > > wrote:
> > > >
> > > > > The goal of release notes is that they are being read.
> > > > > There should be a good balance of the amount of information,
> > preventing
> > > > > people to say TLDR;
> > > > >
> > > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful
> > > information.
> > > > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting the
> > > > > related Jira page will provide you the extra information, including
> > the
> > > > > actual reporter and contributors.
> > > > >
> > > > > Summing up a list of names that helped on the release is a good way
> > to
> > > > > appreciate their help on this release.
> > > > >
> > > > > Robert
> > > > >
> > > > >
> > > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <
> > > tibordigana@apache.org
> > > > >
> > > > >
> > > > > wrote:
> > > > >
> > > > > > We should use authors of the issue/PR/idea.
> > > > > > After the release we can ask WHY (practical goals) he wanted the
> > > > feature
> > > > > > more than how. The question for "HOW" has to be placed very early
> > > > during
> > > > > > the review, but too late after the PR has been merged.
> > > > > > I expect that the reviewer developer has checked all the code, so
> > > there
> > > > > > would not be questions about *how* it is done. If the reviewer
> does
> > > not
> > > > > > understand the code and he admits the change, then it is question
> > for
> > > > him
> > > > > > whenever a new trouble happens.
> > > > > > So this is my opinion - listing the author(s) of the idea in
> every
> > > > > > issue/PR.
> > > > > >
> > > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <
> > > rfscholte@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > >> Not sure if the reader of the release notes is helped with a
> long
> > > list
> > > > > >> of
> > > > > >> reporters and contributers per issue.
> > > > > >> I would expect that only a list of (unique) names is good
> enough.
> > > > > >>
> > > > > >> If there is someone that deserves extra credits, I'd say it is
> > > Stefan
> > > > > >> Oehme for diving into the code, looking for memory leaks AND
> > > providing
> > > > > >> patches to solve it.
> > > > > >>
> > > > > >> thanks for pushing this release!
> > > > > >> Robert
> > > > > >>
> > > > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
> > > > > >> <eo...@gmail.com>
> > > > > >>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Hi all,
> > > > > >> > I have sent a draft of the release notes for 3.6.2
> > > > > >> >
> > > > > >> > this is the PR
> > > > > >> > https://github.com/apache/maven-site/pull/99/files
> > > > > >> >
> > > > > >> > Feel free to add comments or push fixes directly to the
> branch.
> > > > > >> >
> > > > > >> > It still lacks a bit of formatting, but the content is ready
> > > > > >> >
> > > > > >> > Cheers
> > > > > >> > Enrico
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>