Stream: brlcad

Topic: release


view this post on Zulip Sean (Sep 13 2020 at 05:12):

Egads, @starseeker ... can't be doing development on the RELEAESE branch like that. Totally out of band, violates the branch, screws up tracking... You made significant behavior changes, rippling implications. Why is that being snuck in like that??

view this post on Zulip Sean (Sep 13 2020 at 05:13):

No logic changes should be originating on RELEASE, STABLE, or any tagged branches.

view this post on Zulip Sean (Sep 13 2020 at 05:35):

As for your question, yes -- you could help document commits 75764, 75774. Obviously pertain to new bot subcommands, some restructured and some new, but there's no mention in NEWS

view this post on Zulip Sean (Sep 13 2020 at 05:53):

oh another was 75939 (doesn't matter that it's experimental, it's visible) -- needs both NEWS and manual page.

view this post on Zulip Sean (Sep 13 2020 at 05:55):

related, 75953 needs a manual page mention

view this post on Zulip Sean (Sep 13 2020 at 06:08):

Sean said:

oh another was 75939 (doesn't matter that it's experimental, it's visible) -- needs both NEWS and manual page.

I went ahead and did the news entry, only should need manual page update now.

view this post on Zulip Sean (Sep 13 2020 at 06:09):

er, rather, I documented that it does ranges, but not the new switches

view this post on Zulip Sean (Sep 13 2020 at 06:09):

that may warrant additional new line

view this post on Zulip Sean (Sep 13 2020 at 06:15):

another commit missing documentation updates is 75975. that mk.tr was the sole user documentation for the src/shapes commands, so either needs some replacement doc or needs manual pages for the six of them.

view this post on Zulip Sean (Sep 13 2020 at 06:38):

also had a question on 76007, whether that was due to dm-fb changes, or if that was fixing a released bug

view this post on Zulip Sean (Sep 13 2020 at 06:44):

last (for tonight) noticed 76009/76021 doesn't appear to be on trunk, unless I missed it on a merge, but will need docs (news, manpage) when/if merged. easily lost given that's a really big branch (i.e., I won't likely catch it on merge). although now that I'm writing this, I'm recalling this is an unpublished interface too and don't recall how it all settled out, so it's a question of interface maturity/status too but still good to note somewhere so there's something to check whenever it is merged.

view this post on Zulip Sean (Sep 13 2020 at 06:45):

there's a few other things on that branch in particular like that, user facing changes. might want to review the commit list and put notes in NEWS or TODO so they're not forgotten come merge time.

view this post on Zulip starseeker (Sep 13 2020 at 13:19):

@Sean Wasn't meaning to "sneak" in - I guess I had a slightly different view of how RELEASE works, possibly incorrect... The changes there are focused on fixing observed behavior issues ahead of the release, and would/will be merged back into trunk after the release is complete.

When I tested rtwizard on Windows, line edge only rendering didn't work at all with the working dir set to the C:/Program Files/... system location - the simplest way to avoid the issue was to adjust the working dir IFF it was set to the bin dir.

view this post on Zulip starseeker (Sep 13 2020 at 13:31):

I guess maybe I get into the habit of doing too much on RELEASE since (especially on Windows) it's very awkward to be building/testing the branch there, adjusting/fixing issues, then going back and making them in trunk, merging them to RELEASE, testing to make sure all that worked, and then iterating on again to the next RELEASE bug.

view this post on Zulip starseeker (Sep 13 2020 at 13:40):

If that's too big a change to make right before release we can go ahead and back it out - the issue is also present in 7.30.8, so it's not a regression.

view this post on Zulip starseeker (Sep 13 2020 at 14:05):

OK, bot command... r75764 got superseded structurally by other commits - checking where we landed... ah. The new commands are extrude, get and set.

view this post on Zulip starseeker (Sep 13 2020 at 14:13):

Oh, I see - whichid and whichair each have a man page, and I only updated whichid. OK, easy fix...

view this post on Zulip starseeker (Sep 13 2020 at 14:50):

@Sean I'm seeing bolt.xml (added from MGED dir), handle.xml, gastank.xml, wire.xml, window.xml and window_frame.xml - are those different from the mk.tr utilities?

view this post on Zulip starseeker (Sep 13 2020 at 14:52):

icv2fb... hmm, good question. Let me check...

view this post on Zulip starseeker (Sep 13 2020 at 15:00):

Oh. r76007 was specific to the fb_read_icv function, which was newly introduced for the dm-fb work.

view this post on Zulip starseeker (Sep 13 2020 at 15:05):

icv2fb and fb2icv is a question, actually - I deliberately removed it since png2fb is (I'm pretty sure) used by other scripts, and at the time I didn't want to tangle with trying to find/fix them all on top of the dm/fb changes. I'd almost forgotten about them, to be honest.

If we do want to resurrect them, probably the thing to do is list png2fb and the other format specific tools for deprecation, and introduce the new ones, but I don't remember how thoroughly the code in those commits got exercised before it was removed...

view this post on Zulip starseeker (Sep 13 2020 at 15:09):

The dm-fb branch was merged - that's the dm plugin rearchitecting - so I'll do a scan and see if I spot anything that survived the branch work as user facing to be merged. There was a lot of churn like the icv2fb stuff, so I'll check and see if any of it (intentionally) survived...

view this post on Zulip starseeker (Sep 13 2020 at 15:31):

AH - that's why the icv2fb and fb2icv commands were removed - screengrab and overlay got those abilities. Updated man pages looks like, but forgot the NEWS items.

view this post on Zulip starseeker (Sep 13 2020 at 15:31):

So the question of icv2fb and fb2icv is for the command line utilities, rather than the GED commands, and that I'm pretty sure I didn't get into for the dm-fb work.

view this post on Zulip starseeker (Sep 13 2020 at 15:49):

Added NEWS item for nburst refactor of the burst command.

view this post on Zulip starseeker (Sep 13 2020 at 16:21):

@Sean I think there may be an option in NSIS to deal with the startup dir - experimenting now, and I've backed out the RELEASE changes pertaining to startup dir manipulation.

view this post on Zulip starseeker (Sep 13 2020 at 17:51):

OK, it looks like r77130 was successful - NSIS installer shortcuts seem to be starting up with the correct directory. WiX will be trickier, but that can wait since we don't really need the .msi installer.

view this post on Zulip starseeker (Sep 13 2020 at 17:54):

@Sean if that solution looks OK, I'll go ahead and add the NEWS item.

view this post on Zulip starseeker (Sep 13 2020 at 21:12):

r75953 mentioned in search man page.

view this post on Zulip starseeker (Sep 14 2020 at 03:12):

Question about 74536 - if app code includes that header, mightn't read and write end up undefined in the app code?

view this post on Zulip starseeker (Sep 14 2020 at 03:33):

That might explain something Robert was asking about... probably safer just to fix this problem at the source...

view this post on Zulip Sean (Sep 14 2020 at 09:13):

starseeker said:

Sean Wasn't meaning to "sneak" in - I guess I had a slightly different view of how RELEASE works, possibly incorrect... The changes there are focused on fixing observed behavior issues ahead of the release, and would/will be merged back into trunk after the release is complete.

Ah yeah... no, that's never been the intention or a convention I've encountered before in the wild, but I'm sure some groups somewhere might. Guess we have wires crossed, maybe we should write it out more explicitly. The gist I've always known is that RELEASE should be only what is strictly necessary to stabilize, finalize, and prepare a release. For example, typically compilation/portability issues detected during testing and final adjustments to release notes/docs. The branch should almost exclusively pull feature/logic changes from trunk. Multiple reasons for the separation, but IA would be a main concern for us so there's never really a need to review changes committed to RELEASE (or STABLE) as they should just be necessary machinery. The other intention is that trunk -> RELEASE -> STABLE -> tag should be a gradient of increasing stability or at least decreasing risk.

view this post on Zulip Sean (Sep 14 2020 at 09:15):

On a more positive note, I think I'm done with the review! I have a laundry list of non-blockers, but the core work is done and I think we're good to release. Thank you for your help on those remaining doc items. That was a big help.

view this post on Zulip Sean (Sep 14 2020 at 09:18):

starseeker said:

Added NEWS item for nburst refactor of the burst command.

Yeah, I debated on that one myself, sounds good. Begs for tests, but not a priority until old goes away.

view this post on Zulip Sean (Sep 14 2020 at 09:20):

starseeker said:

Sean I think there may be an option in NSIS to deal with the startup dir - experimenting now, and I've backed out the RELEASE changes pertaining to startup dir manipulation.

Okay. I actually had a talk with several of the guys a few week ago specifically about the startup concerns. You and I should probably take some time later to discuss. Several tradeoff and expectation considerations.

view this post on Zulip Sean (Sep 14 2020 at 09:27):

starseeker said:

Question about 74536 - if app code includes that header, mightn't read and write end up undefined in the app code?

they shouldn't, but there is a potential problem if someone has wrapped read/write before that header is included. that could be the case with config_win.h but then I'd expect it to issue a redefinition warning. easy fix would be o stash the existing read/write values and restore them after opennurbs instead of undef'ing them.

view this post on Zulip starseeker (Sep 14 2020 at 09:34):

Is the r77137 change OK? That seemed like the surest way to guarantee there isn't an issue...

view this post on Zulip starseeker (Sep 14 2020 at 09:39):

Thanks for pushing through with the review, I know that was an epic slog

view this post on Zulip starseeker (Sep 14 2020 at 09:40):

/me commences the final tests/sync/version updates

view this post on Zulip starseeker (Sep 14 2020 at 14:48):

Windows and Linux binaries up, as well as source tarballs.

view this post on Zulip starseeker (Sep 14 2020 at 15:22):

@Sean Did you want to handle the brlcad-news announcement?

view this post on Zulip starseeker (Sep 14 2020 at 15:22):

Wondering in particular if you wanted to combine it with a GSoC update...

view this post on Zulip Sean (Sep 14 2020 at 15:52):

That was a slog but it was my fault getting that far behind. Or I can blame it on pandemic. Wildly off on estimation too. I’d cruise though a couple hundred commits and think “oh I’ll be done in 2-3 days at this rate”, and then there’d be a dozen user vis changes made in one day.

view this post on Zulip Sean (Sep 14 2020 at 15:53):

Sure I can post the announce today.

view this post on Zulip Sean (Sep 18 2020 at 17:23):

No sorry, @starseeker, I got it. Just was trying to get a Mac build up there to go with it, but needn't wait.

view this post on Zulip Sean (Sep 19 2020 at 21:00):

@starseeker what is the last time you have for when we publicly announced? I have a rev, but want to see if it matches with what you have.

view this post on Zulip Sean (Sep 19 2020 at 21:00):

I know we made a number of releases without announcing.

view this post on Zulip starseeker (Sep 19 2020 at 21:01):

It's been a while. When I looked at brlcad-news it was years back

view this post on Zulip starseeker (Sep 19 2020 at 21:02):

The NEWS file has a 7.30.0 writeup, but I don't think it got sent out to news...

view this post on Zulip starseeker (Sep 19 2020 at 21:03):

https://sourceforge.net/p/brlcad/mailman/message/31152309/ is the last one I see in the brlcad-news archive...

view this post on Zulip Sean (Jul 22 2021 at 09:07):

@starseeker I posted comments on two of the commits, but the rest all looked fine on review. No show stoppers, though do think the timer will need to be reworked.

view this post on Zulip Sean (Jul 23 2021 at 04:37):

On an unrelated point, it looks like Coverity is fully integrated/integratable with GitHub, so we can make the checks continuous. Looks like they've also matured a lot in terms of how one can submit and view scans with TravisCI support and other manual integrations supported too if we wanted to have it trigger off from our Jenkins install or elsewhere.

view this post on Zulip Sean (Nov 15 2022 at 06:48):

@starseeker fyi r72266 isn't right. unfortunately didn't catch that earlier. I explain why it's wrong in a commit to CHANGES that aims to at least revert the deprecation notice.

view this post on Zulip starseeker (Nov 15 2022 at 17:12):

@Sean OK. One question I do have about that - what's our behavior on Windows with respect to btclsh and key bindings? I may be wrong, but I think libtermio is a no-go for Windows... is there some solution we should add to our longer term plan for ensuring feature parity for btclsh?

view this post on Zulip Sean (Nov 16 2022 at 23:00):

Don't know the behavior on Windows, but wouldn't be surprised if it's lame. That porting came years later. I think long-term, we could possibly make them go away. E.g., make "package require tclcad" include whatever is needed inside a vanilla tclsh/wish and don't provide a shell, but will require some testing. Do know there are a number of btclsh/bwish-using applications outside our code as it was actively promoted for a while. The critical features they provided were auto-loading of all packages and commands, and auto-discovery of their installation so users didn't have to resort to PATH, shell scripting, and other workarounds.

view this post on Zulip Sean (Nov 16 2022 at 23:00):

@starseeker question about r74380 .. doesn't that make them undocumented in doxygen?

view this post on Zulip starseeker (Nov 16 2022 at 23:45):

Hmm. Possibly - I'll check. (been a while since I've done a doxygen build - probably a bit of a mess to clean up, now that you mention it...)

view this post on Zulip starseeker (Nov 16 2022 at 23:50):

So it looks like the answer is "sort of" - they're there, but not especially pretty: image.png

view this post on Zulip starseeker (Nov 16 2022 at 23:51):

IIRC I was trying to simplify the parsing problem for the debug command at the time - I can revisit that and see what the issue was

view this post on Zulip starseeker (Nov 17 2022 at 00:22):

@Sean Fixed: https://github.com/BRL-CAD/brlcad/commit/786bb1b3b14ebf7eb8f8e7b809b390c995b5be3e

view this post on Zulip Sean (Nov 17 2022 at 03:28):

@Daniel Rossberg Do you recall what 84c679a74fe8248e52ef7066a6a1284eafd2a4b5 (svn r74503) was about in the comgeom converter? Did that fix a bug?

view this post on Zulip Sean (Nov 17 2022 at 03:42):

@starseeker is r74757 inadvertently fixed?

view this post on Zulip starseeker (Nov 17 2022 at 03:46):

It should be, actually - let me test.

view this post on Zulip starseeker (Nov 17 2022 at 03:46):

If not, it will be

view this post on Zulip starseeker (Nov 17 2022 at 04:05):

It does not survive - I must not be saving the object type it is stored as. Investigating - may have to fix it tomorrow morning

view this post on Zulip starseeker (Nov 17 2022 at 04:17):

Whoops - still have the tcl script version going in MGED - that's not good...

view this post on Zulip starseeker (Nov 17 2022 at 05:30):

OK, there we go. With the right code hooked up, r74757 is indeed inadvertently fixed

view this post on Zulip Daniel Rossberg (Nov 17 2022 at 19:19):

Regarding 84c679a74fe8248e52ef7066a6a1284eafd2a4b5 (svn r74503): I don't recall what the bug was, but I'm pretty sure that there was one. At this time I had to convert some old GIFT models.

view this post on Zulip starseeker (Nov 18 2022 at 19:40):

@Sean You put back r74890 in the 7c57481b TODO commit... -r opt for color randomization is an old feature, was in NEWS in 7.16.0, and I added a 3dm-g man page - is there something else still missing?

view this post on Zulip starseeker (Nov 18 2022 at 21:00):

On the 7c9572e270 (MGED menu entries) change - do you want to restore those and handle them in appropriate fashion later? I'll have to confirm, but it looks like putting openw.tcl back to that state will restore them...

view this post on Zulip Sean (Nov 21 2022 at 20:03):

starseeker said:

Sean You put back r74890 in the 7c57481b TODO commit... -r opt for color randomization is an old feature, was in NEWS in 7.16.0, and I added a 3dm-g man page - is there something else still missing?

Oh wow, no I didn't look that far back. I just noticed e3a12028cf00c1eb316ffbc6c77bd198db5b2e97 change and had interpreted as turning it on on quick glance, but see now you'd promoted it to a new field. Man page was all that was needed.

view this post on Zulip Sean (Nov 21 2022 at 20:13):

starseeker said:

On the 7c9572e270 (MGED menu entries) change - do you want to restore those and handle them in appropriate fashion later? I'll have to confirm, but it looks like putting openw.tcl back to that state will restore them...

If literally dropping in openw.tcl restores them, then I think we can leave them obsoleted. It'd at least be a runtime workaround to anyone affected. I'd guess impact is unlikely, but those are a Chesterton's Fence issue for me.

I don't know/remember the use case for some of them to be able to accurately evaluate impact. Still, with a workaround, I think the gut sentiment holds -- the docs just still have to be fixed then.

view this post on Zulip starseeker (Nov 21 2022 at 20:23):

I think one of the target modelers may have mentioned something about the View Ring a while back, which surprised me at the time but would constitute an argument for restoring it until something else is available to replace it.

view this post on Zulip starseeker (Nov 21 2022 at 20:30):

I have a vague recollection of discussing this a long while back - we may have figured saveview/loadview could serve as a substitute for the View Ring, but it looks like I didn't make a note of that in the commit message if we did...

view this post on Zulip starseeker (Nov 21 2022 at 20:32):

Although going that route, looks like I need to add "loadview" man page to the necessary doc updates

view this post on Zulip Sean (Nov 21 2022 at 20:40):

I have a recollection as well, about a year ago, though not the specifics. It was just in reviewing in more depth that it became evident that several of those have no counterpart within mged, while others did. It's a mixed bag.

view this post on Zulip starseeker (Nov 21 2022 at 20:41):

I'm OK either way Sean - whatever you're more comfortable with.

view this post on Zulip Sean (Nov 21 2022 at 21:41):

Does dropping in openw.tcl restore them? If it does, then I think we can just move on. I've already taken too long of a break talking....

view this post on Zulip starseeker (Nov 21 2022 at 21:43):

It appears to restore them, yes.

view this post on Zulip starseeker (Nov 21 2022 at 21:45):

I'll put it back and add a new item noting their restoration

view this post on Zulip Sean (Nov 22 2022 at 04:56):

Really nice work on breaking up and cleaning up libnmg..

I mean there's no way I can properly test it all in time, but looked like you were definitely going in the right direction and making significant strides cleaning it up.

view this post on Zulip Sean (Nov 22 2022 at 18:19):

@starseeker any idea what introduced this blather?

[ 21%] Built target libged-obj
[ 21%] Linking CXX shared library ../../lib/libged.dylib
ld: warning: dylib (../../lib//libpng_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../lib//libnetpbm.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../lib//libregex_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../lib//libz_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
[ 21%] Built target libged
[ 21%] Building C object src/libged/sync/CMakeFiles/ged-sync.dir/sync.c.o
[ 21%] Linking C shared library ../../../libexec/ged/libged-sync.dylib
ld: warning: dylib (../../../lib//libnetpbm.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../../lib//libz_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../../lib//libpng_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../../lib//libregex_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
... and so on...

view this post on Zulip starseeker (Nov 22 2022 at 21:10):

Not offhand. Is MACOSX_DEPLOYMENT_TARGET set to something?

view this post on Zulip Sean (Nov 22 2022 at 21:10):

I have not set anything

view this post on Zulip starseeker (Nov 22 2022 at 21:11):

The only obvious thing I can think of is one of the OSX CMake variables (CMAKE_OSX_DEPLOYMENT_TARGET or the like) is somehow out of sync with what is being built...

view this post on Zulip starseeker (Nov 22 2022 at 21:12):

But I don't know why that would manifest that way, if that's even what it is.

view this post on Zulip starseeker (Nov 22 2022 at 21:14):

CMake is warning me for my build to set MACOSX_DEPLOYMENT_TARGET to something...

view this post on Zulip starseeker (Nov 22 2022 at 21:19):

One question Sean - are you building using Xcode gui, or from the command line with make?

view this post on Zulip Sean (Nov 23 2022 at 00:06):

Almost exclusively just run cmake -D... && make

view this post on Zulip Sean (Nov 23 2022 at 00:06):

By the way, if it's not clear from the commits, I'm tapping out and calling review done!

view this post on Zulip Sean (Nov 23 2022 at 00:07):

I wrote up a brief 2 para preamble that felt commensurate with what wasn't covered in the bullets below.

view this post on Zulip Sean (Nov 23 2022 at 00:08):

Trick is always how to keep it as brief as possible without under-informing or over-sharing.

view this post on Zulip starseeker (Nov 23 2022 at 00:54):

@Sean Looks good. Any known missing user visible NEWS items to add? If not I'll clear that last TODO, update the clang static analyzer count for the current code state, and commence merge to RELEASE branch.

view this post on Zulip Sean (Nov 23 2022 at 07:54):

Not that I know of, all clear here. I've been kicking tires and seeing if I see any obvious critical breakage.

view this post on Zulip Sean (Nov 23 2022 at 07:56):

fyi, Mac build was no-test for me as that's an arm64 (apple m2?) build and I'm on x86_64 (intel)

view this post on Zulip starseeker (Nov 23 2022 at 13:01):

Ah, nuts. Sorry about that - I forgot that one was an arm machine

view this post on Zulip starseeker (Nov 24 2022 at 01:58):

@Christopher @Sean Anything I can to do to help?

view this post on Zulip Sean (Aug 01 2024 at 04:14):

@starseeker Only release concern is pulling in the hlbvh changes on such short order feels super risky (and that's before discovering it outright broke windows). Thought we were going to pull that in the next minor? Something changed?

view this post on Zulip Sean (Aug 01 2024 at 04:18):

Otherwise, I've not tested it since it's been merged, so I definitely can't speak to release status.

view this post on Zulip Sean (Aug 01 2024 at 04:27):

I'd suggest we revert it back out until 7.42 -- give more time for more exhaustive discovery and manual testing.

I think it really deserves special release notes on its own, and adding it to the existing waters down the magnitude of the other two big changes.

Similarly, if there are any bot raytracing issues, it'd be helpful to rule out facetize vs tracing, and that won't be easy if released together.

I mean, we can even do another minor a week later ... I just wouldn't ship them together without then doing even more cross-platform, validation, and performance testing.

view this post on Zulip starseeker (Aug 01 2024 at 11:39):

@Sean We're branched into RELEASE for 7.40 - hlbvh changes aren't in that release

view this post on Zulip Sean (Aug 01 2024 at 13:57):

@starseeker Ah, gotcha. Didn't know you weren't going to sync main to RELEASE again. That's a much different picture! Then only question is how much testing RELEASE has at this point from you guys -- if you're confident. I've not tested RELEASE, but can kick that off today for some manual testing.

view this post on Zulip starseeker (Aug 01 2024 at 13:59):

Release has been tested by both Chris and myself - the last substantial change/fix was just to address the environment variable thing from the cfarm machine. Yes, please test RELEASE - as far as I know (and I think @Christopher as well?) we should be good to go.

view this post on Zulip starseeker (Aug 01 2024 at 13:59):

I'd like to try building on a Rocky Linux platform, but that's the only thing I think still on the list for me

view this post on Zulip Sean (Aug 01 2024 at 14:00):

Heh

view this post on Zulip Sean (Aug 01 2024 at 14:13):

Mildly related, I assume you saw the Issue posted by cmpitts on plate-mode BoT? Doesn't sound like it's a new issue, so probably not release-related, but we should probably confirm that.


Last updated: Oct 09 2024 at 00:44 UTC