Re: [Xastir-dev] [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
Rgr. Will post announcement today then. On Thu, May 30, 2019 at 10:33 AM km5vy Tom Russo wrote: > On Thu, May 30, 2019 at 11:12:03AM -0600, we recorded a bogon-computron > collision of the flavor, containing: > > On Mon, May 27, 2019 at 11:52:53AM -0700, we recorded a bogon-computron > collision of the flavor, containing: > > > Fine by me. I can do all the announcements. > > > > It is likely that I'll go ahead and walk through the git steps of doing > > the release tonight instead of tomorrow. > > Or now. > > It is done. > > https://github.com/Xastir/Xastir/releases/tag/Release-2.1.2 > > > My "friday off" turns out to be a > > day of household chores. > > > > Actually stepping through the release process is only a few minutes, and > the > > longest steps are those that verify that the easy steps were done > correctly. > > > > I'll shoot a message to the lists when it's done, and then the proper > announcing > > can happen. > > > > > On Mon, May 27, 2019, 10:07 AM Tom Russo wrote: > > > > > > > On Thu, May 23, 2019 at 01:05:53PM -0600, we recorded a > bogon-computron > > > > collision of the flavor, containing: > > > > > On Thu, May 23, 2019 at 07:15:52AM -0700, we recorded a > bogon-computron > > > > collision of the 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 < > lee.bengs...@gmail.com> > > > > 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 > > > > > > >
Re: [Xastir-dev] [Xastir] ATTENTION: Preparing for next release: Please thrash on the code
On Mon, May 27, 2019 at 11:52:53AM -0700, we recorded a bogon-computron collision of the flavor, containing: > Fine by me. I can do all the announcements. It is likely that I'll go ahead and walk through the git steps of doing the release tonight instead of tomorrow. My "friday off" turns out to be a day of household chores. Actually stepping through the release process is only a few minutes, and the longest steps are those that verify that the easy steps were done correctly. I'll shoot a message to the lists when it's done, and then the proper announcing can happen. > On Mon, May 27, 2019, 10:07 AM Tom Russo wrote: > > > On Thu, May 23, 2019 at 01:05:53PM -0600, we recorded a bogon-computron > > collision of the flavor, containing: > > > On Thu, May 23, 2019 at 07:15:52AM -0700, we recorded a bogon-computron > > collision of the 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 > > 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 > > 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 > > > > > >
