On Thu, May 23, 2019 at 01:05:53PM -0600, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > On Thu, May 23, 2019 at 07:15:52AM -0700, we recorded a bogon-computron > collision of the <[email protected]> flavor, containing: > > Anyone else have any reports, good or bad? > > > > FWIW: For the types of things I do the latest code has been stable for me. > > > > We're getting close to a release and Tom will most likely be the one doing > > it. No target date has been mentioned. If we run into any nasty bugs that > > might delay. > > Let's set a date right now. I can set aside the time to do the release > on only a few days in the upcoming weeks (it doesn't take long, but it's > a process that takes some attention, and is documented in > README.developers.md). > > The days I could do it are: > Friday, 31 May > Friday, 14 June > Sometime on the weekend of 21-23 June.
Can we pick one? I propose we just rip off the band-aid and do it Friday 31 May. I can take care of the git work if you'll handle doing all the various announcements. > I think that we are already at a point where there has been sufficient time > to shake out the code on master, and we could release today if we wanted > to. Next friday is the earliest I have the opportunity to spend on it. > > If someone else wanted to try out the release process, it's all documented > in gory detail in README.developers.md, and if followed precisely would > produce a new release that would be ready (down to file names of tarballs) > to slot into the package creation processes various distros use, just by > changing the version number. Or pick a date and I'll do it then. > > > On Fri, May 17, 2019 at 6:16 PM Lee Bengston <[email protected]> wrote: > > > > > I've played with it some and and have not found any issues. I put together > > > a BPQ packet node in January, and I haven't fully back-filled what I had > > > "stolen" from aprs, so testing capability is fairly limited. From what I > > > can tell, though, it's nice and stable. > > > > > > I do have a few questions about the source ( yeah, always one in the crowd > > > :-) ) > > > > > > - In dlm.c noticed references to "curl-multi" and evidently the capability > > > to leverage parallel downloading of map tiles as supported by libcurl. Is > > > whether or not that is supported in our platform based on what version of > > > curl is installed? > > > > > > - now that dlm.c handles downloading tiles, is there anything left in > > > tile_mgmnt.c that is still needed or could tile_mgmnt.h and tile_mgmnt.c > > > be > > > removed? It seems at a minimum the "getOneTile" portion of tile_mgmnt.c > > > is > > > no longer needed. > > > > > > Looks like you guys are doing a lot of cleanup in this release, so brought > > > that up just in case there's some stuff there that could be streamlined a > > > bit. > > > > > > Fyi, my Odroid XU4 (arm based) beats the pants off my Intel Celeron based > > > laptop in terms of map download speed. Both are on Ubuntu 18.04 with the > > > MATE desktop. Am wondering if the fact that the XU4 has an octa-core cpu > > > makes a difference with respect to curl-multi. > > > > > > The cleaner compiling is very noticeable, and the earlier note about newer > > > compilers spitting out more warnings matches what I saw. Compiling is > > > cleaner in Debian Stretch and Ubuntu 16.04 than it is in Ubuntu 18.04, but > > > it still builds fine. (And even in Ubuntu 18.04 the new code still > > > compiles a lot cleaner that the older code did) > > > > > > Thanks, > > > > > > Lee > > > K5DAT > > > > > > > > > On Thu, May 9, 2019 at 9:57 AM Curt Mills <[email protected]> wrote: > > > > > > > We're planning to do a release within a few weeks. It might be as few as > > > 2 > > > > weeks. > > > > > > > > Please check out / compile / thrash on the latest Github Xastir code. > > > Find > > > > anything that broke with our latest code fixes. Exercise all types of > > > > interfaces, messaging, bulletins, weather stations, tracking, following > > > > stations, maps, etc. Anything you can think of. > > > > > > > > The latest code compiles much cleaner and a lot of fixes went in to make > > > > that possible. We'd like this release to function well, so whatever you > > > can > > > > do to exercise the code would be most appreciated. > > > > > > > > If you find a bug or odd operation, report it here: > > > > > > > > https://github.com/Xastir/Xastir/issues > > > > > > > > Thanks! > > > > > > > > -- > > > > Curt, WE7U http://we7u.wetnet.net > > > > http://www.sarguydigital.com > > > > _______________________________________________ > > > > Xastir mailing list > > > > [email protected] > > > > http://xastir.org/mailman/listinfo/xastir > > > > > > > _______________________________________________ > > > Xastir mailing list > > > [email protected] > > > http://xastir.org/mailman/listinfo/xastir > > > > > > > > > -- > > Curt, WE7U http://we7u.wetnet.net http://www.sarguydigital.com > > _______________________________________________ > > Xastir mailing list > > [email protected] > > http://xastir.org/mailman/listinfo/xastir > > -- > Tom Russo KM5VY > Tijeras, NM > > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] > > _______________________________________________ > Xastir-dev mailing list > [email protected] > http://xastir.org/mailman/listinfo/xastir-dev -- Tom Russo KM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
