> On Dec 7, 2017, at 12:09, Lubomir I. Ivanov <neolit...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface