[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-12-07 15:10:39 +0100, Branko Čibej wrote:
> >> Did you have some specific change you wanted to propose?  (Other than
> >> making the 'author' column's width configurable)
> > I just wanted to have more than 8 characters for the authors names
> > (without changing the "file size" column).
> 
> Yes, the default width is still 8 columns but that will expand to up to
> 16 as needed, without any additional options.

OK, fine. Thanks for the information.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn commit: r1848393 - in /subversion/site: publish/.message-ids.tsv tools/haxx-url-to-message-id.sh

[Daniel Shahaf]

julianf...@apache.org wrote on Fri, Dec 07, 2018 at 12:29:56 -:
> Add a tool for generating a svn.haxx.se archive URL to message-id mapping.

Yay!

> +++ subversion/site/publish/.message-ids.tsv Fri Dec  7 12:29:56 2018
> @@ -1,3 +1,5 @@
> +# Message-ids of archived emails that are referenced by a svn.haxx.se URL.
> +# Generated by tools/haxx-url-to-message-id.sh on 2018-12-07

Could we run this periodically unattended?  We could teach the svn-role
bot to checkout the site source, run this script and commit the results.

The cron job would be —

fn=publish/.message-ids.tsv
cd ~/src/svn/site
svn up -q
tools/haxx-url-to-message-id.sh > $fn
svn ci -m "* $fn: Automatically regenerated" $fn

That's it, I think.  (There's no 'svn st' call because, when there are
no changes to commit, 'svn ci' does nothing and exits 0.)

Cheers,

Daniel

Re: truncated author names in 'svn ls -v' output

[Branko Čibej]

On 07.12.2018 14:58, Vincent Lefevre wrote:
> On 2018-12-07 12:06:08 +, Daniel Shahaf wrote:
>> Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100:
>>> the issue with the suffix solution (B/K/M/G) is that it is actually
>>> less readable when one has many files in the list. I mean that with
>>> the full file size displayed, it is very easy to see which files take
>>> the most space, or similar information: the number of digits gives the
>>> order of magnitude of the file size; this can be found in a fraction
>>> of second. With the suffix form, one needs to look at all the sizes
>>> one by one.
>> The output with SI suffixes is not the default.  If you don't opt-in to
>> it by passing a new-in-1.12 option, you will never see it in the first
>> place.
> I'm a bit lost. :( I thought that this was the solution to make
> more space for the author names (as the SI suffixes were discussed
> under this thread).

Note that with what's on trunk now, the author column will adjust its
width within limits anyway.

>> Did you have some specific change you wanted to propose?  (Other than
>> making the 'author' column's width configurable)
> I just wanted to have more than 8 characters for the authors names
> (without changing the "file size" column).

Yes, the default width is still 8 columns but that will expand to up to
16 as needed, without any additional options.

-- Brane

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-12-07 12:06:08 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100:
> > the issue with the suffix solution (B/K/M/G) is that it is actually
> > less readable when one has many files in the list. I mean that with
> > the full file size displayed, it is very easy to see which files take
> > the most space, or similar information: the number of digits gives the
> > order of magnitude of the file size; this can be found in a fraction
> > of second. With the suffix form, one needs to look at all the sizes
> > one by one.
> 
> The output with SI suffixes is not the default.  If you don't opt-in to
> it by passing a new-in-1.12 option, you will never see it in the first
> place.

I'm a bit lost. :( I thought that this was the solution to make
more space for the author names (as the SI suffixes were discussed
under this thread).

> Did you have some specific change you wanted to propose?  (Other than
> making the 'author' column's width configurable)

I just wanted to have more than 8 characters for the authors names
(without changing the "file size" column).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Integrate archives / logs, permalinks, searching

[Branko Čibej]

On 07.12.2018 12:14, Julian Foad wrote:
> Branko Čibej wrote:
>> On 07.12.2018 11:50, Julian Foad wrote:
>>> (From my thoughts on svn community development: 
>>> https://cwiki.apache.org/confluence/display/SVN/What%27s+In+My+Head#What'sInMyHead-Integratearchives/logs,permalinks,searching
>>>  )
>> The way to start would be to post permalinks to Confluence pages. I can
>> break that link right now by renaming your head ... I mean the page
>> about what's in it. :)
> Yes, yes. But it's less functional: Confluence doesn't seem to provide a 
> permalink for a subsection. Here's one for the whole page:
> https://cwiki.apache.org/confluence/x/U4rQBQ


Paste the anchor onto that and it "just works":

https://cwiki.apache.org/confluence/x/U4rQBQ#What'sInMyHead-Integratearchives/logs,permalinks,searching

Of course that's a completely moronic way to identify resource
fragments. Clearly the low-budget developers who invented this scheme
for Atlassian don't have a clue about usability in hypertext.

-- Brane

P.S.: Is there a plain-text editor for Confluence with visible markup?
The WYSIWYMPGIYVL one is less than perfect.

Re: truncated author names in 'svn ls -v' output

[Daniel Shahaf]

Vincent Lefevre wrote on Fri, Dec 07, 2018 at 12:43:42 +0100:
> the issue with the suffix solution (B/K/M/G) is that it is actually
> less readable when one has many files in the list. I mean that with
> the full file size displayed, it is very easy to see which files take
> the most space, or similar information: the number of digits gives the
> order of magnitude of the file size; this can be found in a fraction
> of second. With the suffix form, one needs to look at all the sizes
> one by one.

The output with SI suffixes is not the default.  If you don't opt-in to
it by passing a new-in-1.12 option, you will never see it in the first
place.

Did you have some specific change you wanted to propose?  (Other than
making the 'author' column's width configurable)

Re: Integrate archives / logs, permalinks, searching

[Johan Corveleyn]

On Fri, Dec 7, 2018 at 12:39 PM Daniel Shahaf  wrote:
>
> Julian Foad wrote on Fri, 07 Dec 2018 11:14 +:
> > https://cwiki.apache.org/confluence/x/U4rQBQ
>
> Will this link be valid in a year or three when the cwiki installation
> has been migrated to another host?  Or will it be invalidated upon the
> next server reboot, or in 90 days, or something like that?
>
> Is there a permalink format that includes the title of the linked page?
> A link that includes only a database identifier is poor from a usability
> point of view.

Just as a data point for the discussion: using links with page names,
where the page has been renamed, are handled quite gracefully by
Confluence. No automatic redirect, but a "Page not found" with "The
page you were looking for may have been renamed to the following:
".

See for example:
https://cwiki.apache.org/confluence/display/SVN/FrontPage

Of course, in that case you also lose any "fragment" part (#section1)
of the incoming link.

-- 
Johan

Re: truncated author names in 'svn ls -v' output

[Vincent Lefevre]

On 2018-11-26 18:19:59 +0100, Stefan Sperling wrote:
> On Mon, Nov 26, 2018 at 04:30:27PM +0100, Vincent Lefevre wrote:
> > On 2018-11-26 15:18:47 +0100, Branko Čibej wrote:
> > > Do please read the rest of the thread. A solution has already been
> > > implemented on trunk.
> > 
> > Except that this solution is not satisfactory for me. I guess that
> > the ultimate solution is to use --xml + a wrapper (thus one could
> > add things like coloring), though that's still limited as one
> > doesn't get the MIME type (svn:mime-type).
> 
> Please don't poke our grumpy Brane bear; we need him to stay in a good mood.
> You see, if you don't like Brane's solution, and you already have a
> working alternative of your own invention which you prefer anyway, then
> pointing out that Brane's solution is unsatisfactory to you just comes
> across as... kind of rude. Even if not meant that way, this was certainly
> not a constructive comment to make on a mailing list such as this one.

Well, if you want a constructive comment, the issue with the suffix
solution (B/K/M/G) is that it is actually less readable when one has
many files in the list. I mean that with the full file size displayed,
it is very easy to see which files take the most space, or similar
information: the number of digits gives the order of magnitude of the
file size; this can be found in a fraction of second. With the suffix
form, one needs to look at all the sizes one by one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Integrate archives / logs, permalinks, searching

[Daniel Shahaf]

Julian Foad wrote on Fri, 07 Dec 2018 11:14 +:
> https://cwiki.apache.org/confluence/x/U4rQBQ

Will this link be valid in a year or three when the cwiki installation
has been migrated to another host?  Or will it be invalidated upon the
next server reboot, or in 90 days, or something like that?

Is there a permalink format that includes the title of the linked page?
A link that includes only a database identifier is poor from a usability
point of view.

Re: Integrate archives / logs, permalinks, searching

[Julian Foad]

Branko Čibej wrote:
> On 07.12.2018 11:50, Julian Foad wrote:
> > (From my thoughts on svn community development: 
> > https://cwiki.apache.org/confluence/display/SVN/What%27s+In+My+Head#What'sInMyHead-Integratearchives/logs,permalinks,searching
> >  )
> 
> The way to start would be to post permalinks to Confluence pages. I can
> break that link right now by renaming your head ... I mean the page
> about what's in it. :)

Yes, yes. But it's less functional: Confluence doesn't seem to provide a 
permalink for a subsection. Here's one for the whole page:
https://cwiki.apache.org/confluence/x/U4rQBQ

And here's a start on a URL resource map:

https://cwiki.apache.org/confluence/x/-4vQBQ "Project Resource URLs"

-- 
- Julian

Re: Integrate archives / logs, permalinks, searching

[Branko Čibej]

On 07.12.2018 11:50, Julian Foad wrote:
> (From my thoughts on svn community development: 
> https://cwiki.apache.org/confluence/display/SVN/What%27s+In+My+Head#What'sInMyHead-Integratearchives/logs,permalinks,searching
>  )

The way to start would be to post permalinks to Confluence pages. I can
break that link right now by renaming your head ... I mean the page
about what's in it. :)

-- Brane

Integrate archives / logs, permalinks, searching

[Julian Foad]

(From my thoughts on svn community development: 
https://cwiki.apache.org/confluence/display/SVN/What%27s+In+My+Head#What'sInMyHead-Integratearchives/logs,permalinks,searching
 )

Problem: Past communications are scattered across systems and storage 
locations, with no consistent archives or permalinks, so cross-referencing is 
difficult and non-permanent. Our issue tracker and wiki provide only links that 
are tied to their current provider technology.

The types of information include:

Short-form chat (IRC) archives: Matrix-Static, irclogger, ASF Wilderness 
IRC logs.
Email/forum archives: haxx.se, ASF Pony Mail, the old Tigris lists. (The 
old Tigris mailing-lists system used to provide a permalink to the archived 
version at the bottom of each mail delivered.)
Issue Tracker: the current Jira issues, the old issuezilla.
Wiki pages: the current Confluence, the old MoinMoin.

An important step is to develop a URL "permalink" scheme to refer to our 
various resources. These would be technology-ignorant URLs, all under 
subversion.apache.org, like "/issue/1234".

A baby step is the '.message-ids.tsv' file in our web site directory, holding a 
mapping from haxx archive URLs used in our web pages to email message ids, with 
(in the commit log message) a script to generate it. There is, as yet, no 
automation to use the mapping in any way.

Initial tasks:

start documenting a URL-space map for our resources
populate one entry, e.g. "/issue/ → issue "
implement some simple automated handling (e.g. redirects) for that
well, well... we already have this in our .htaccess which covers that 
exact case along with some aliases:
"RedirectMatch ^/issue[^A-Za-z0-9]?(\d+)$ 
https://issues.apache.org/jira/browse/SVN-$1;
start using it: update existing direct links to point here instead; 
publicize it

Deeper integration: A permalink URL should not merely redirect the user to its 
technology-specific target URL, but present the target in such a way that other 
inbound and outbound URLs also use the permalink form. With a big third-party 
system like Jira or Confluence the feasibility of that is going to depend 
entirely on whether the system has built-in support for that usage.

-- 
- Julian

Re: Configuration file syntax

[Johan Corveleyn]

On Thu, Dec 6, 2018 at 5:50 PM Branko Čibej  wrote:
...
> Whilst doing that, I found out that Confluence has an "Excerpt" macro
> that can mark part of the page content for reuse; and it has a "Children
> Display" macro that can show the title and excerpt of child pages. So,
> the contents of this page:
>
> https://cwiki.apache.org/confluence/x/6ojQBQ
>
> are completely automatically generated and will be updated as we add new
> documents. Surely that's a great motivation to write them? :)

Awesome! It's nice to see our wiki documentation coming more and more
to life :-).

Thanks for all the documentation efforts (especially to you and Julian).

--
Johan