Re: further iterations on the release process and user experience

[Simeon Geiger via subsurface]

Hi all,

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 藍)



I liked the increased activity on the mailing list. So here is my feedback:

1. The download pages look good to me, I find the needed file more 
quickly than on the github page. But as an experienced user, I was also 
happy with the github page.


As an android user, I have taken the new release process as a reason to 
switch from the google play beta channel to the sideloaded apk. I 
noticed the following regarding the android-mobile-release:


2.  App runs well, on my Sony Xperia 5 II (XQ-AS52) with Android 12 and 
display with 21:9-format


3. First time I uninstalled the google play version, then updating 
worked by just downloading a newer apk. Very nice.


4. In a previous mobile version, there was an integrated GPS tracker, 
that I used. It is now not available anymore. I guess it is due to the 
fact that background services are difficult to implement. They often get 
killed on android due to battery saving restrictions.


For this point, the documentation needs some adaption. The user manual 
for the mobile version 
(https://subsurface-divelog.org/documentation/subsurface-mobile-v3-user-manual/) 
does not advertise the GPS tracking feature, but the manual for the 
desktop version does 
(https://subsurface-divelog.org/documentation/subsurface-4-user-manual/):


*Dive coordinates from a mobile device with GPS using 
Subsurface-Mobile.* Most smartphones have an integrated GPS, useful 
for collecting the coordinates of dive sites. The user manual for 
/Subsurface-mobile/ 
 
(accessible from within that app) contains detailed instructions for 
performing the collection of GPS data and for managing, uploading and 
synchronising the coordinates with a dive log.


5. I am running Arch Linux and used the desktop version until it was 
removed from the repositories. Since then, I was using the appimage. I 
downloaded the newest appimage to test it, but it failed:



./Subsurface-v6.0.5059-CICD-release.AppImage
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could 
be initialized. Reinstalling the application may fix this problem.


Available platform plugins are: xcb.

[1]    34490 IOT instruction (core dumped) QT_QPA_PLATFORM=wayland 
./Subsurface-v6.0.5059-CICD-release.AppImage


I cloned the repo and built subsurface, and it runs without problems:


./subsurface --verbose
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

QSocketNotifier: Can only be used with threads started with QThread
Subsurface v6.0.5059-local,
built with libdivecomputer v0.8.0-devel-Subsurface-NG 
(577b6940874c76cfc9b1adb0b0e51e26349b5a8f)

built with Qt Version 5.15.12, runtime from Qt Version 5.15.12
built with libgit2 1.7.1
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 4.6."
loading "de-DE" translations
QObject::connect(QQuickWindow, QDeclarativeGeoMap_QML_6): invalid 
nullptr parameter

DivePixmaps DPR: 1.00 metrics: 24 16 sz_bigger: 40
loading dive data from


Hoping the comments and testing is of some use. I am always happy to 
give feedback, if I experience problems, which is luckily rarely the case.


Thank you all for your work on this very helpful app for divers.
Simeon Geiger


On 16.01.24 04: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.


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

[Robert Helling via subsurface]

Hi everyone,

> On 16. Jan 2024, at 04: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.
> 

tried it and liked it. I think it’s very clear. Just one nitpick: In the iOS 
section, maybe you can change the wording that it is clear that it is about 
distributing „versions for iOS“ rather than „iOS versions“.

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

[Martin de Weger via subsurface]

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

[Michael Keller via subsurface]

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

[Dirk Hohndel via subsurface]

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: further iterations on the release process and user experience

[Michael Keller via subsurface]

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

[Martin Gysel via subsurface]

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

Re: further iterations on the release process and user experience

[Dirk Hohndel via subsurface]

>
>>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 

Oh, and I do think that the update language for the Linux distros is much 
nicer, if I may say so.

I ended up ordering an ultra cheap Windows 11 PC on Amazon. That way hopefully 
I can experiment with the Windows user experience as well.

/D
___
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

[Dirk Hohndel via subsurface]

On January 14, 2024 6:16:44 PM PST, Michael Keller  wrote:
>
>
>Looking good!

Thank you

>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.

>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 

>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 ?

/D
___
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

[Michael Keller via subsurface]

Hi Dirk.

On Mon, Jan 15, 2024 at 1:35 PM Dirk Hohndel via subsurface
 wrote:
>
> Not being able to leave your house, a laptop and internet connection... ideal 
> conditions to keep dinking around with stuff :)

Sounds like the perfect weekend. :-P

> 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.

Looking good!
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.
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.
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'?
>
> 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 藍
>
> So, question to the Windows users here... how often do you see unsigned apps? 
> How much of an issue is it to have the Subsurface installer not signed. As I 
> keep saying, I don't use Windows myself, so it's really hard to judge for 
> me...
>
> 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

[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 藍

So, question to the Windows users here... how often do you see unsigned apps? 
How much of an issue is it to have the Subsurface installer not signed. As I 
keep saying, I don't use Windows myself, so it's really hard to judge for me...

Thanks

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

further iterations on the release process and user experience

[Dirk Hohndel via subsurface]

I have been chatting off-list with Michael but really should be having these 
conversations here.

Initial feedback on the CICD release process has been overwhelmingly positive, 
but there were a few really good pieces of criticism as well

- the GitHub release page is not very user friendly and feels far more like 
something targeting developers, not end users / divers
- in the same context, it's hard for some of our users to figure out which 
binaries to download - which one is the Windows installer, which one is for 
Android, etc
- depending on how many things get merged / pushed, this process creates a LOT 
of new releases which most people will not want to upgrade to all the time
- unsigned binaries are far less convenient than signed binaries, especially on 
macOS, but also on Windows
- it would be nice to get better update notifications in the apps, and to 
include Android in that list (as it no longer gets store notifications)
- what about iOS?

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.

You can see the current version of this download page here: 
https://subsurface-divelog.org/current-release/ 
This is NOT linked into the overall website, yet, as I wanted to collect a bit 
more feedback, first.
(and yes, I am not a good web designer... tell me something I don't know)

This should address the first couple of concerns listed above.

To deal with the third one, I am thinking through options to semi-automatically 
create weekly releases with a different landing page (that clearly identifies 
these as "weekly", but is otherwise very similar to the page above). And I'm 
hoping to find a rhythm to also update the iOS app roughly in that cadence.

In this context I am hoping to overhaul the update mechanism for the apps (and 
add the mobile apps to the mix) and set things up so people can pick if they 
want the water-hose or the weekly update reminders. That hasn't happened, yet, 
and obviously will also require some changes in the apps (while at the same 
time not breaking older apps). So this may take a little longer :)

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.
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.


/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface