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 <garydgreg...@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 <eolive...@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 < > > tibordig...@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 <eolive...@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 <tibordig...@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 < > > rfscho...@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 < > > > > tibordig...@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 < > > > > rfscho...@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 > > > > > > >> <eolive...@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-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 > > > > > > > > > > > > > > > > > > > > > > > > > > >
