Because the svn-based solution is hitting operational snags. It MUST be replaced.
svn itself has no problem with a repository measured in dozens of terabytes. But that totally blows up operational concerns. Status quo is not a forgone benefit. Things must sometimes change, CLR. And to repeat: there is no mandate to use ATR. Ask again in five years. Might change at that point. Cheers, -g On Thu, Dec 18, 2025 at 7:23 PM Craig Russell <[email protected]> wrote: > My main issue is why the ATR objective is not to simply make it easier for > projects to create dist/download artifacts that have been used successfully > for years. I have seen no reason to rearchitect the entire process. > > Craig > > > > On Dec 18, 2025, at 07:53, Craig Russell <[email protected]> wrote: > > > > Thanks for that. > > > > Was there a discussion focused on why dist/downloads was not fit for > task? What are the reasons for migration to a new system instead of simply > integrating with the current system? > > > > Warm regards, > > Craig > > > > > >> On Dec 18, 2025, at 07:47, Dave Fisher <[email protected]> wrote: > >> > >> https://tooling.apache.org/svn-dist > >> > >> I recently figured out a way to use mermaid charts with pelican. The > site needs more updates. We currently plan to reach transition 2b for beta. > >> > >> Best, > >> Dave > >> > >>> On Dec 17, 2025, at 5:39 PM, Craig Russell <[email protected]> > wrote: > >>> > >>> I've heard talk of the dist mechanism being replaced. I cannot find > the documentation on what the replacement might look like. > >>> > >>> This is part of a broader question about the high level architecture > of the ATR system. I've looked at the github repo as well as > https://tooling.apache.org/ and can't find anything. > >>> > >>> Craig > >>> > >>> Craig L Russell > >>> [email protected] > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > Craig L Russell > > [email protected] > > > > Craig L Russell > [email protected] > >
