08:41:03 <ErCiccione[m]> fluffypony: please update the server when you can
09:08:39 <ErCiccione[m]> More i think about it more i don't see the point of having a different version for every download. I think it would be extremely confusing for everybody to have a release for a single build/platform. Wouldn't be just much easier to just make a point release rebuilding the single binaries and leaving the others as they are?
09:09:33 <ErCiccione[m]> i'm referring to https://repo.getmonero.org/monero-project/monero-site/merge_requests/1159#note_7749
09:11:45 <ErCiccione[m]> my point is, instead of having, for example, 0.15.0.2 for Linux 64 bit and 0.15.0.1 for Windows and all the others. Wouldn't be just easier to bump all builds, but without actually change the build, just retag it? so we would have the fixed 0.15.0.2 linux 64 bit and 0.15.0.2 windows, but the latter would be the same as 0.15.0.1
09:12:02 <ErCiccione[m]> Sounds easier and less confusing.
09:12:08 <ErCiccione[m]> hyc fluffypony ^
09:13:32 <ErCiccione[m]> To be clear, it's not a problem at all to add a version for each build, i just don't see it as a useful thing to have. But maybe i'm still missing something
09:23:50 <selsta> usually we bump the version and release for all OS
09:23:57 <selsta> but gui and cli are seperate
09:24:03 <selsta> separate*
09:28:47 <ErCiccione[m]> yes, that's my point selsta. I separed gui and cli, and each have its own version. That's why i don't see the point of adding versions for every single build. Seems more confusing than helpful
10:42:24 <selsta> fluffypony: https://downloads.getmonero.org/cli/freebsd64 seems to redirect to v0.14
10:42:31 <selsta> the other ones seem correct
10:46:32 <fluffypony> tks selsta, good catch
10:46:35 <fluffypony> not sure how I missed that
10:52:06 <fluffypony> should be fixed
11:20:23 <ErCiccione[m]> somebody opened an issue about it, but when i tested it i didn't see any issue: https://repo.getmonero.org/monero-project/monero-site/issues/1018
11:20:28 <ErCiccione[m]> anyway, good it's fied
11:21:11 <ErCiccione[m]> oh, you fixed after i checked :P
11:24:37 <ErCiccione[m]> *before
11:35:57 <hyc> There's a fine line between being user-friendly and catering to user ignorance. We should at all times be aiming towards educating users, not allowing them to remain ignorant.
11:43:09 <ErCiccione[m]> hyc: that's not what's happening. As i said in the comments i think is counterproductive to shove a list of hashes to the face of the people and it's much more effective to go progressively. If people see hashes they will just ignore them, if they see a "verify" section, they may read it instead.
11:47:33 <hyc> Fine, don't show the complete list, just show the hash for the particular download they selected in the dropdown
11:47:56 <hyc> but don't make them click something else in addition, to show it
11:50:59 <ErCiccione[m]> That was my first idea (along with listing the hash when you click to download), but i don't think it's possible to implement it without using javascript. The current method was the best trade-off IMO.
11:51:29 <hyc> bummer
11:52:41 <ErCiccione[m]> yeah, being strictly no-javascript complicated things, but i think it worth it.
17:24:27 <hyc> I 'm thinking "Show hashes" should be "Show details" and also include the file sizes
17:24:39 <hyc> perhaps also a timestamp, just like a regular directory listing
17:25:13 <hyc> I still don't like the fact that the hashes are separated from their corresponding download link
17:25:51 <hyc> would consider putting them in tooltips but that doesn't help mobile
17:28:38 <hyc> failing that, at least make the hash list a Dictionary list, the current formatting doesn't really make it clear that a particular has belongs to a particular heading