Re: Draft of release notes for Maven 3.6.2

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Draft of release notes for Maven 3.6.2

Enrico Olivelli
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 <
[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <
> > [hidden email]
> > > >
> > > >
> > > > 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 <
> > [hidden email]>
> > > > > 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
> > > > >> <[hidden email]>
> > > > >>
> > > > >> 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: [hidden email]
> > > > >> For additional commands, e-mail: [hidden email]
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
>