Subsurface-mobile 2.0.1 and Subsurface 4.7.5

[Dirk Hohndel]

> On Dec 7, 2017, at 12:09, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> I need to write a release announcement. I haven’t had enough time this morning to look into this - I’ve been fighting with screen shots for the iOS app for two hours. What fun.
>> 
>>> isn't what's in our CHANGELOG.md sufficient? i know about at least a
>>> couple of changes that were not mentioned there.
>> 
>> That’s part of it - make sure all relevant changes are mentioned.
> 
> ok, i will now go through the commits and see what is missing and add
> it. question about RleaseNotes.txt format bellow.
> we should require PRs to always add notes to CHANGELOG.md before
> accepting the PR.

Yes, we should.

>> Sort them for what’s relevant to mobile vs desktop
>> And then... do we want to collate them back into ReleaseNotes.txt when we do a release?
>> 
> 
> i'm not sure TBH. i would move what has accumulated in CHANGELOG.md to
> ReleaseNotes.txt.
> normally projects only have a CHENGELOG.md file, but we are using
> asciidoc/a2x for the .txt.
> 
> so in our case we need an extra step.
> 
> i think the formatting of ReleaseNotes.txt has to be changed from:
> "Some of the changes since _Subsurface_ 4.7.4"
> ...
> 
> to (the old format):
> "New in version 4.7.5" / : "Changes in 4.7.5"
> ...

Oh, good. I like that (says the person who started what’s now in ReleaseNotes.txt)

>>> also i just merged a change from Robert.
>>> should we consider an email from you like the above as the actual
>>> master branch LOCK until the next release happens?
>>> 
>> 
>> Yes, that would have been nice. I think the builds that I have will work for the release, but it would have been nice to not merge things without an approval from me while I’m in the middle of doing a release.
>> 95% of the time others merging things is really making my life easier. There are a few exceptions.
>> - don’t merge things unless you are super certain that this is the right thing or unless other maintainers have approved (this has lead to one revert recently)
>> - please don’t merge things that clearly fall into someone else’s area of expertise without their feedback (I try not to touch the planner / deco calculation without Robert commenting - or Windows internals without you commenting - or core data structures without a comment from Linus, etc.)
>> - when I start talking about getting ready for a release (which I usually do about a week before I think I’ll be making the release), SLOW DOWN. Pay attention to new strings and alert me to new strings, ideally right away so we give the translators a chance. Don’t merge changes that change the UI without talking to me. And usually, also check with Willem on that in case we need new screen shots.
>> - if something breaks a build and you merge it, then please fix it (I’ve done that, so I’m adding it explicitly)
>> 
> 
> understood - that's what i said last time, but still merged things. ugh.
> perhaps "the merge window is now closed" notification would make it
> more clear to everyone.

But we don’t have a formal merge window, and we don’t have a process
where we do RCs after the merge window. All I’m hoping for is a bit of
stability / quiet in the repo while I’m literally trying to get to a release.
And of course, I myself am the worst offender...

> one problem he have is that not all collaborators review and small PRs
> tend to collect dust.

Everyone here volunteers whatever time they are comfortable with.
I try to comment on every PR within a day or two. I’d love it if others
did more, but I’m grateful for what everyone is able to contribute.

> always a couple of people reviewing a PR, one being a maintainer is of
> course the ideal scenario, but we only have that something like 30% of
> the time.
> 
> maybe we should always wait for a couple of people approving a PR.

This is why I hate black and white rules.
Many cleanups are obviously correct (removing an unused variable as
an extreme case). Why would that wait for a review?
On the flip side, especially things that change the UI, change core data
structures... those really should get a review or two.

/D