D 1.076 and 2.061 release

[Leandro Lucarella]

Walter Bright, el  4 de January a las 10:58 me escribiste:
> On 1/4/2013 6:02 AM, Leandro Lucarella wrote:
> >Walter Bright, el  3 de January a las 23:03 me escribiste:
> >>On 1/3/2013 9:49 PM, Jonathan M Davis wrote:
> >>>but other lines like
> >>>
> >>>$(LI std.string: $(RED The implementations of std.string.format and
> >>>string.sformat have been replaced with improved implementations which conform
> >>>to writef. In some, rare cases, this will break code. Please see the
> >>>documentation for std.string.format and std.string.sformat for details.))
> >>
> >>Yes, you can put this in as the bugzilla title, though I'd tighten it up a little.
> >
> >Are you being serious? Do you really think this would be useful for the
> >user?  That the user will be able to spot that particular comment among
> >hundreds of bugs in a bugzilla search query result?
> 
> It's not hundreds. It's the new/changed list, which is rather short.
> It was a little longer this time because it's been several months.
> Usually, it's just a handful.

True, but sometimes bugfixes needs important news too, if some code use
to compile when it shouldn't. What would you do with that? Add another
bug and tag it as a enhancement? Makes no sense to me, is prostituting
the tool and making the users go to a prostitute (no offense to
prostitutes!).

Why settle with an option that's clearly worse for the users?

> >Is really that hard to acknowledge that release notes are better than
> >doing that? I can understand if you see problems on keeping up to date
> >the release notes, but I can't believe that anyone can think is plain
> >better to user bugzilla instead (for the user POV at least).
> >
> >Can we at least agree on that and then see if is feasible to have good
> >and up to date release notes?
> 
> But we've done that before. It was not working.

You are mixing everything together! What you did before is manually
adding **all** the changes to the changelog. Again (and again, and
again) I'm suggesting keep the automatic listings in bugzilla but adding
release notes too, some more "high level" text explaining users the key
changes in a new release.

But I guess we are arguing for no reason now because you already said
that was OK. So now, my only request is for the reviewers to try to pay
more attention to pull request and stop merging them until they also
update the documentation and add release notes when appropriate. That
should improve the situation a lot and doesn't generate a lot of new
work, just more attention when reviewing and telling the contributor
what's missing for the pull request to be merged. Then the work of
writing the release notes is distributed among all the users.

> >I understand that, but I don't think that work should be optional and
> >only done if somebody feels like. Every pull request should include
> >proper documentation update. Can we try to focus on that for the next
> >release?
> 
> We are all volunteers. You are welcome to help out with this.

I know that (and honestly, I think you know that I know). I already fix
my incomplete pull request by updating the documentation and the
"release notes". I try to help with everything I can. And there's
organization too. We are all volunteers but there some more experienced
volunteers and some with extra responsibilities. I just can't reject
pull requests because I can't merge them, and I'm not experienced enough
to precisely tell people exactly what pull requests are missing. I'll
try to pay more attention myself too and give feedback when I see a pull
request that I think is incomplete.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El techo de mi cuarto lleno de estrellas