Re: further iterations on the release process and user experience
Hi Dirk, I’ll try to click around in the next couple of days. What I did notice on my Mac was a 404 error on the current release page: Not Found The requested URL was not found on this server. Apache/2.4.52 (Ubuntu) Server at subsurface-divelog.org Port 443 Kind regards, Martin de Weger > Op 16 jan 2024, om 04:40 heeft Dirk Hohndel via subsurface > het volgende geschreven: > > Yet another iteration. I followed many of Michael's suggestions. > > I'm curious what others think? > > It's a bit lonely here when no one comments on the work we do. There's a few > hundred people on this mailing list (and with the recent bout of emails, > three unsubscribed 藍) > > None of this requires a lot of work or any understanding other than that of a > user. I guess maybe I should ask on the User Forum. > > "current / weekly" release page: > https://subsurface-divelog.org/current-release/ > "latest / bleeding edge" release: > https://subsurface-divelog.org/latest-release/ > > The Ubuntu / Copr instructions are still the same on both pages - once we > have settled on good names I'll create corresponding names for those and have > differentiated instructions as well. > > Thanks > > /D > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: further iterations on the release process and user experience
Hi Dirk. On 16/01/24 16:40, Dirk Hohndel via subsurface wrote: Yet another iteration. I followed many of Michael's suggestions. I'm curious what others think? It's a bit lonely here when no one comments on the work we do. There's a few hundred people on this mailing list (and with the recent bout of emails, three unsubscribed 藍) None of this requires a lot of work or any understanding other than that of a user. I guess maybe I should ask on the User Forum. "current / weekly" release page: https://subsurface-divelog.org/current-release/ "latest / bleeding edge" release: https://subsurface-divelog.org/latest-release/ The Ubuntu / Copr instructions are still the same on both pages - once we have settled on good names I'll create corresponding names for those and have differentiated instructions as well. Me again. We're getting there! One thing I noticed this time round was that when I clicked onto the link I got the page with the previous design. We might have to make sure we re-generate the ETag when the latest release for the respective track is changed. Cheers Michael Keller ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: further iterations on the release process and user experience
Yet another iteration. I followed many of Michael's suggestions. I'm curious what others think? It's a bit lonely here when no one comments on the work we do. There's a few hundred people on this mailing list (and with the recent bout of emails, three unsubscribed 藍) None of this requires a lot of work or any understanding other than that of a user. I guess maybe I should ask on the User Forum. "current / weekly" release page: https://subsurface-divelog.org/current-release/ "latest / bleeding edge" release: https://subsurface-divelog.org/latest-release/ The Ubuntu / Copr instructions are still the same on both pages - once we have settled on good names I'll create corresponding names for those and have differentiated instructions as well. Thanks /D___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Update form win 10/11
I'm surprised and mildly confused that it would update to an unsigned binary without complaining and making you click on a few dialogues... But I'll admit that I don't understand at all how this is supposed to work exactly.. /D On January 15, 2024 10:03:45 AM PST, Eric Tanguy via subsurface wrote: >___ >subsurface mailing list >subsurface@subsurface-divelog.org >http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface -- From my phone___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Update form win 10/11
Hi all, i just see the 6.0.5053 version available from winget (Chocolatey rep) and it updated without any question (elevated privileges). Regards Eric ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: O2 sensors on Divesoft Liberty
Jef, thanks a lot for your help. > On 12. Jan 2024, at 09:22, Jef Driesen wrote: > > Libdivecomputer reports the sensor number, or DC_SENSOR_NONE if the data is > not from a sensor (for example the voted/average ppO2): > > https://github.com/libdivecomputer/libdivecomputer/blob/master/src/divesoft_freedom_parser.c#L911 > https://github.com/libdivecomputer/libdivecomputer/blob/master/src/divesoft_freedom_parser.c#L1023 > > You can use this info to distinguish between the different sensors. > > Libdivecomputer does not support reporting whether a sensor was voted out. > The freedom dive computers do record this info, so this is something that > could be added (although no other dive computers supports this). Currently we > only use the sensor state bits to exclude sensors that are not available or > not calibrated. I am still trying to make up my mind about the best way to handle this situation. The problem is: There is no straight forward solution to a voting logic when you have more than three sensors. You cannot simply say: If the spread is too big, throw away the outlier. Yes, you can always try to bring the spread of values into a smaller range by deleting the largest or smallest. But then there is more than one parameter to quantify the spread (should you tread spread of four values more liberally than just of three?, do you look at the overall spread (larges minus smallest) or pairwise distances? average distance?). In any case, since there are so many choices, we would almost certainly do something different that the dive computer itself. The jury is still out on how bad this is. On the other hand, I think, the best way to report what the Liberty thinks what is going on, would be an event that is emitted when one of the sensor bits changes (in any direction). From what I see from the promotional videos on youtube (I have never seen the actual unit in real life nor have I seen an actual log file so far, only reports about those), the computer seems to raise an alarm for the diver to decide what to do (including bringing back a sensor into the game that was disabled before). Do you think this is the right path? I am not really familiar with the inner workings of libdivecomputer, so for me to produce a patch has some learning curve (plus I might end up to do the wrong thing or the right thing in a wrong way). But if you want, I can give it a try. Best Robert signature.asc Description: Message signed with OpenPGP ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: further iterations on the release process and user experience
Hi Dirk. On 15/01/24 19:57, Dirk Hohndel via subsurface wrote: I would probably add a link to the other page to the top of each page, 'if you want the latest version, go [here]' / 'if you want a more stable version, go [here]', or else users will get locked in once they have bookmarked one of the pages. There are links in the menu on the left. But we can of course make it more explicit. I think allowing users to compare what they are getting from each track on a single page (irrespective of which track's page they are on) will make it easier for users to decide what is right for them. Also, I am wondering if the iOS paragraph should be above 'Linux' - this will make it show above the fold for most users, and reduce the number of users posting questions after not finding it. The reason I have it on the bottom is because it doesn't really give people anything. And they already get notifications from the AppStore, assuming I keep my promises Agreed. Maybe that was just me making biased assumptions around how much text iOS users vs. linux users are willing to read through until they give up and ask in the forum. And I am wondering if it would be better to use more distinguishable names for the 'release tracks' than 'latest' / 'current' - I suspect that users will confuse these when talking about them in support posts. Maybe 'nightly' vs. 'weekly'? Not a fan because I don't think those really will be the timeframes that these builds will happen at. Certainly not nightly. unstable and stable ? edge and tested ? Yeah, using the time frames as names is certainly aspirational, but I think that it will also give users an idea of the relative frequency of updates / update notifications that they can expect - which will really be the main difference between the tracks from a user perspective. I think 'unstable' and 'stable' implies a difference in quality that is likely not going to be there in reality - if we are pushing changes that we expect to require more changes to stabilise we should really use a 'feature branch' to complete the work and then push into `master`. And `unstable` will scare users off using the 'bleeding edge' track even if they are willing to take _some_ risk. And 'tested' is the opposite - implying that there has been an effort at testing the releases, and not just an absence of negative feedback. 'bleeding edge' vs. 'stable'? Cheers Michael Keller /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: further iterations on the release process and user experience
Am Montag, 15. Januar 2024, 01:34:05 CET schrieb Dirk Hohndel via subsurface: > Not being able to leave your house, a laptop and internet connection... > ideal conditions to keep dinking around with stuff :) > > On Jan 13, 2024, at 10:53, Dirk wrote: > > > > In order to address some of these concerns, I built a new download page > > and some automation that keeps it updated. This happens with, at a > > minimum, a 1h time lag so that all binaries show up at the same time; > > this also gives us some margin of error if we merge something that fails > > that allows us to not post a release. And of course there's a mechanism > > to manually point at a different release. > So this should now be the https://subsurface-divelog.org/latest-release/ > page - clearly showing that this is the Latest CICD Release. > > In addition, there is a https://subsurface-divelog.org/current-release/ > Current Release page. With the goal to iterate this more slowly - maybe > once a week. And, now that I had the time to figure out how this can work > (see above), this even links to a SIGNED macOS DMG. > > Finally, app signing. > > Given how painful macOS makes it to install unsigned apps, I think I'll > > need to figure out how to sign at least the "weekly" builds. I doubt that > > I can truly automate that, but maybe I can figure out a way to keep up > > with things. > Done > > > As for Windows - that's a harder problem. The signing mechanisms for > > Windows are either prohibitively expensive (even with the generous > > donations from some of you - we are talking around $300-500 a year plus > > hardware cost (as I would need an actual real Windows machine for this -- > > apparently doing this in a VM no longer works) for what is essentially a > > blessed random number. The old system that was more affordable > > (~$100/year) has been killed by Microsoft when they started making > > additional requirements (including allowing signing certificates only > > when they are on hardware keys). And as I mentioned before, I'm seeing a > > lot more companies release unsigned apps for Windows again. If a better > > and more realistically priced solution pops up, I'll happily revisit this > > topic. > Also, some googling and following countless broken links later... it appears > there is a not quite as expensive option: > https://cheapsslsecurity.com/fastssl/code-signing-certificate.html > > With the required hardware token, a three year certificate is about $500 > with shipping - so $170/yr. That is still a lot, but seems more doable. Now > all I would need is a Windows PC 藍 AFAIK you don't need a windows pc for this. At work, I'm able to sign windows apps on my linux system using a hardware token. that works just fine. it's even possible to let more people use that token if you make it available over the network (usb over it)... /martin ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
