Ticket #3780 (new task)

Opened 9 months ago

Last modified 24 hours ago

Prepare for release mc-4.8.20

Reported by: zaytsev Owned by:
Priority: major Milestone: 4.8.20
Component: adm Version: master
Keywords: Cc: egmont
Blocked By: Blocking: #3856
Branch state: no branch Votes for changeset:

Description


Change History

comment:1 Changed 9 months ago by egmont

  • Cc egmont added

comment:2 Changed 7 months ago by andrew_b

Last edited 5 months ago by andrew_b (previous) (diff)

comment:3 Changed 7 months ago by mooffie

src/filemanager/panelize.c has unused "#define LABELS 3". Credit goes to "Andreas Mohr <and@…>" (this is from #2942).

comment:4 Changed 7 months ago by zaytsev

../../../../src/vfs/tar/tar.c: In function ‘tar_open_archive’:
../../../../src/vfs/tar/tar.c:805:69: error: ‘h_size’ may be used uninitialized in this function [-Werror=uninitialized]

comment:5 Changed 6 months ago by and

I tidy up OBS build testing across some linux distributions
https://build.opensuse.org/project/show/home:andreasmohr:mc

mc-git_cleanup-*-default is current cleanup branch (3780_cleanup)
mc-git_master-*-default is HEAD branch

minor distributions failed with

parse_ls_vga.c:790:13: error: In the GNU C Library, "makedev" is defined
  by <sys/sysmacros.h>. For historical compatibility, it is
  currently defined by <sys/types.h> as well, but we plan to
  remove this soon. To use "makedev", include <sys/sysmacros.h>
  directly. If you did not intend to use a system-defined macro
  "makedev", you should undefine it after including <sys/types.h>. [-Werror]
          s->st_rdev = makedev (maj, min);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~       

comment:6 Changed 6 months ago by andrew_b

mc-3780-tar.c-Cleanup-compiler-aggressive-loop-optimizations-warning.patch: applied as fixup.
mc-3780-boxes.c-Cleanup-pointer-compare-warning.patch: applied.
mc-3780-mcviewer.c-Cleanup-implicit-fallthrough-warning.patchh: applied.

comment:7 Changed 5 months ago by andrew_b

At current moment, the 3780_cleanup branch has 20 commits. I think it's time to review and merge it.

comment:8 Changed 2 months ago by egmont

Hi guys,

What do you think about a release real soon? It's been half a year since the last one.

Way back on May 7 I wrote on mc-devel: "this timestamp issue plus the pending mcview growing issues [...] are I believe a good reason to schedule a .20 release for the not-so-distant future (let's say, within a month or so)"

wiki/ReleaseGuidelines says "Period of releases: two-three months", but, in fact, the pattern recently seems to be (with a few exceptions) one in the spring and one in autumn :)

comment:9 Changed 2 months ago by zaytsev

Hi Egmont,

I thought of all people you are pretty much aware of what the current situation is. Sure, I'm all for making releases more often, but I'm simply incapable of doing so, as my stress level keeps increasing year after year beyond what I thought was even possible. Therefore, I'm struggling to do at least two releases per year and no less, and indeed they fall on time periods immediately "after spring vacation" and "after fall vacation"...

Anyways, as you might have noticed, I've started trying to merge easy stuff in preparation for the fall release. I don't know what Andrew's plans are, would be good if he could comment on what he absolutely wants to get in before release. I was hoping to review his cleanup branch next weekend, and then check what else can be easily merged & make an RC.

There have been some annoying OS X build breakage stuff on GitHub and a few small things I was thinking of trying to process...

Z.

comment:10 follow-up: ↓ 15 Changed 2 months ago by andrew_b

I want to see #3850 and #3148 in the release.
Currently, #3148 is on top on #3850 and will be rebased to master after merge of #3850.

comment:11 Changed 2 months ago by zaytsev

Hi Andrew, many thanks for your patience and feedback! I think the important thing is to finally get the cleanup in, then update translations and co., and then I will try my best to look into the other 2 things you mentioned.

comment:12 Changed 2 months ago by egmont

@Yury, sorry, I didn't want to urge you... in fact, when I started typing my comment I hadn't yet realized the twice-a-year pattern :) By the time I finished writing the comment, I didn't think it through that there'll be a release soon anyways :)

Sure, let's wait for everyone's pet peeve bugs to get fixed first.

Thanks a lot again to all of you guys!

PS. I've updated the wiki about the release frequency.

comment:13 Changed 2 months ago by andrew_b

  • Blocking 3856 added

comment:14 Changed 2 days ago by andrew_b

Merged to master: [2f25f66b5d0c62f70798ef3d922af1d9677209ee].

git log --pretty=oneline aff3834..2f25f66

comment:15 in reply to: ↑ 10 ; follow-up: ↓ 16 Changed 2 days ago by andrew_b

Replying to andrew_b:

I want to see #3850 and #3148 in the release.

Move to the next release.

comment:16 in reply to: ↑ 15 Changed 2 days ago by egmont

I was just about to ping you guys :) It's been a pretty quiet month, which hopefully means mc is quite stable. Hopefully all the changes got enough testing. Perfect time for a release :-)

I want to see #3850 and #3148 in the release.

Move to the next release.

#3850 has an accepted change, maybe it's okay to squeeze in that (but then it won't get enough testing, so maybe we should just delay it). I'd prefer you (andrew_b) to make the decision here. #3148 has been broken for a long time and doesn't have a fix yet, I fully agree that we shouldn't wait for it.

Note: See TracTickets for help on using tickets.