Re: svn commit: r1891065 - in /subversion/site/staging-ng: ./ docs/community-guide/ docs/release-notes/ security/
Den sön 11 juli 2021 kl 17:53 skrev Nathan Hartman : > On Fri, Jul 9, 2021 at 4:22 PM Daniel Sahlberg > wrote: > > I merged the staging-ng branch to staging yesterday evening but forgot > to notify dev@. Please check https://subversion-staging.apache.org/ and > report any issues. > > > It's a big improvement for readability on mobile! > > One slight issue: It seems the viewport is set just *slightly* too > wide, at least on my device. This causes a little bit of unwanted > left/right scroll. > > In landscape orientation it is barely discernible (but it's there). > > In portrait orientation, a few pixels are cut off the right edge (but > can be scrolled horizontally into view). > > How many pixels? I think 8. I think it's caused by style/site.css, > where "#site-banner" has a padding of 8px. (Though there may be other > paddings that contribute.) > It was actually 7 pixels, caused by a padding in the site-nav . I've moved it to the site-nav-menu in r1891461. It has the side effect that the hamburger is slightly closer to the left edge but I think it is acceptable. > Why I think so: At the top of the page, the ASF banner, which appears > above the Subversion banner, seems to have the final N cut off from > the word "FOUNDATION" so that it appears to read "FOUNDATIO" until the > screen is scrolled slightly sideways. At first I thought it was caused > by the banner being too wide. But then I noticed that the viewport is > a little too wide in landscape orientation too, even though the banner > is narrower than the viewport in that orientation. Then I noticed that > the little gray gradient under the banners seems to have this extra > white padding on its right edge (so the blue "border-top" of > #site-content, and beneath it, the green "border-top" of #site-nav, > are wider than the #site-banner gradient) and that seems to be the > exact amount of unwanted scroll. > The ASF logo contained an explicit size which broke the CSS media queries. I've removed it in r1891462. Looks much better now. I can see it on my computer using Firefox once the window is made > narrow enough to switch to hamburger view. > I saw it as well on my computer using Edge, if I just looked close enough. Thanks for reviewing and drawing my attention to it. Kind regards, Daniel Sahlberg
Re: svn commit: r1891065 - in /subversion/site/staging-ng: ./ docs/community-guide/ docs/release-notes/ security/
On Fri, Jul 9, 2021 at 4:22 PM Daniel Sahlberg wrote: > I merged the staging-ng branch to staging yesterday evening but forgot to > notify dev@. Please check https://subversion-staging.apache.org/ and report > any issues. It's a big improvement for readability on mobile! One slight issue: It seems the viewport is set just *slightly* too wide, at least on my device. This causes a little bit of unwanted left/right scroll. In landscape orientation it is barely discernible (but it's there). In portrait orientation, a few pixels are cut off the right edge (but can be scrolled horizontally into view). How many pixels? I think 8. I think it's caused by style/site.css, where "#site-banner" has a padding of 8px. (Though there may be other paddings that contribute.) Why I think so: At the top of the page, the ASF banner, which appears above the Subversion banner, seems to have the final N cut off from the word "FOUNDATION" so that it appears to read "FOUNDATIO" until the screen is scrolled slightly sideways. At first I thought it was caused by the banner being too wide. But then I noticed that the viewport is a little too wide in landscape orientation too, even though the banner is narrower than the viewport in that orientation. Then I noticed that the little gray gradient under the banners seems to have this extra white padding on its right edge (so the blue "border-top" of #site-content, and beneath it, the green "border-top" of #site-nav, are wider than the #site-banner gradient) and that seems to be the exact amount of unwanted scroll. I can see it on my computer using Firefox once the window is made narrow enough to switch to hamburger view. (Still, it is a big improvement over publish, where making the viewport narrow causes the banners to get totally messed up.) Cheers, Nathan
Re: svn commit: r1891237 - in /subversion/site/staging/docs: ./ api/ api/1.13/ api/1.13/search/ api/1.14/ api/1.14/search/ javahl/ javahl/1.13/ javahl/1.13/org/ javahl/1.13/org/apache/ javahl/1.13/org
Nathan Hartman wrote on Fri, 09 Jul 2021 19:54 +00:00:
> On Thu, Jul 8, 2021 at 9:36 PM Daniel Shahaf wrote:
> > Generating the site API docs from _any_ revision of branches/1.A.x
> > (whether @HEAD, @${MAGIC_REVISION}, or anything else) would mean
⋮
> > Also, HACKING doesn't define the term "magic revision" (= the revision
> > that's tagged, visible as the copyfrom of the tag in the repository and
> > the value of SVN_VER_REVISION in the tag's source tree). The term is used
> > in
> > https://subversion.apache.org/docs/community-guide/how-to-roll-releases-in-private.txt,
> > though.
>
> That's the 'revnum' arg to the 'roll' subcommand of release.py. Is
> there a reason it should be termed a "magic revision" here? I didn't
> see this terminology except in how-to-roll-releases-in-private.txt.
>
> Ah, perhaps it was renamed in the past, or was simply called that in a
> discussion way back... Don't know if it's worth digging for it though.
>
> I suppose it's best fixed by defining it where it's first used, in
> how-to-roll-releases-in-private.txt, with something like:
>
> [[[
>
> Index: docs/community-guide/how-to-roll-releases-in-private.txt
> ===
> --- docs/community-guide/how-to-roll-releases-in-private.txt (revision
> 1891418)
> +++ docs/community-guide/how-to-roll-releases-in-private.txt (working copy)
> @@ -17,12 +17,13 @@
>for 1.9 would add not only 1.9.7 but also 1.8.19.
>[TODO: And how are the patches to be committed to trunk, then?]
>
> -- You'll be rolling a 1.a.b release with b>0, so for the magic
> - revision argument pass the magic revision of 1.a.c where c=b-1. You
> - can find the magic revision by running 'svn log -v' on the 1.a.c
> - tag. Run 'release.py roll' and pass '--patch DIR' where DIR
> - contains the CVE and CHANGES patches. The names of the patch files
> - should include '1.a' and end 'patch'. Example rolls:
> +- You'll be rolling a 1.a.b release with b>0, so for the magic revision
> + argument pass the magic revision of 1.a.c where c=b-1. (The magic revision
> + is the tag's copyfrom revision, which you can find by running 'svn log -v'
> + on the 1.a.c tag. It is also the value of SVN_VER_REVISION in the tagged
> + sources.) Run 'release.py roll' and pass '--patch DIR' where DIR contains
> + the CVE and CHANGES patches. The names of the patch files should include
> + '1.a' and end 'patch'. Example rolls:
>
> release.py roll --patch .../security/CVE-2017-9800 1.8.19 1800620
> release.py roll --patch .../security/CVE-2017-9800 1.9.7 1800392
>
> ]]]
>
> However, if there's a reason this term should be more widely used and
> defined in HACKING, let me know...
That term is part of the terminology around releases. It's been in use
since 2005 at least [1], and in this thread it came up naturally in
a discussion about release procedures. I agree it hasn't been used
much recently, but that's likely because frequency nowadays is on
the low side.
Overall, I think that term belongs in the release process documentation
(= in HACKING).
Cheers,
Daniel
[1] https://svn.haxx.se/dev/archive-2005-10/1060.shtml
(found by grepping a backup of svn.haxx.se's spool)
