I want to do the work, with your help (as we already documented quite a few topics)
I prepared a Git filtered "main" branch with docs/ output removed: https://github.com/hboutemy/attic-site/tree/main = source only, that should be maintained in Git for ease of external contributions (exact command run is "git-filter-repo --path docs --invert-paths") If we just change the build script to get its source from such Git branch and commit output to existing svn: https://svn.apache.org/repos/asf/attic/site/docs/ and https://svn.apache.org/repos/asf/attic/site/cwiki_retired/ We don't need to change the infrastructure visible svn for html and flags = what would be harder and more risky. I'm not a buildbot expert, I don't know how to update https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/attic-site.py but I can do it with Jenkins (I have experience with such source in Git + Jenkins build to html checked-in to svnpubsub) looks feasible, isn't it? Regards, Hervé On 2025/04/04 22:12:41 sebb wrote: > I've just noticed that Puppet code fetches the cwiki_retired/ files from SVN. > > That would also need to be addressed if the code were moved to Git. > > Maybe there are other references still lurking. > > On Fri, 4 Apr 2025 at 17:51, sebb <seb...@gmail.com> wrote: > > > > On Fri, 4 Apr 2025 at 16:54, Herve Boutemy <hbout...@apache.org> wrote: > > > > > > fair questions > > > > > > On 2025/04/04 13:04:57 sebb wrote: > > > > On Fri, 4 Apr 2025 at 12:49, Herve Boutemy <hbout...@apache.org> wrote: > > > > > > > > > > > Git does not store empty directories, so that would require a change > > > > > > to the way the flagged/ tree is maintained. > > > > > > (note that the enitre flagged/ tree is missing from the mirror under > > > > > > xdocs and docs) > > > > > > > > > > > > Not a blocker, but it would have to be sorted first. > > > > > yes > > > > > perhaps the opportunity to document where the site HTML content is > > > > > stored, as we are currently discovering that Attic is not maintaining > > > > > retired projects, but de-facto is having a minimum level of > > > > > maintenance of HTML websites > > > > > = something we did not really organize until now > > > > > > > > > > > > > > > > > > and choose what we do with the html output in doc: either keep it > > > > > > > in svn for > > > > > > > svnpubsub or switch it to Git branch for GitPubSub (or any name > > > > > > > this mechanism > > > > > > > has nowadays) > > > > > > > > > > > > The site is currently built using buildbot, which assumes SVN for > > > > > > source and target. > > > > > > That would also have to be fixed. > > > > > yes > > > > > > > > > > > > > > > > > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > > > > > > What is important to me is to split the source xdocs from the > > > > > > > generated HTML > > > > > > > > > > > > Why? > > > > > because mixing source and output html in the same svn tree creates > > > > > confusion, double commits > > > > > We got that situation from history: once we clearly split the source > > > > > + build instructions vs output, it will also ease for example > > > > > thinking at updating the build tool and source format (xdoc + Ant + > > > > > Velocity) > > > > > > > > > > this step will really be an enabler for the future > > > > > > > > It's no easier to update two separate repos with build output than one. > > > true: it's just more clear if build output is not inside source structure > > > > > > having: > > > - source = https://github.com/apache/attic-site/tree/main (= like trunk > > > but without the docs/ directory content as it is not source code) > > > - html output = https://svn.apache.org/repos/asf/attic/site/docs/ (as > > > current) > > > > > > is more clear than > > > - source = https://svn.apache.org/repos/asf/attic/site/ > > > - html output = https://svn.apache.org/repos/asf/attic/site/docs/ > > > > To you maybe, but I am used to source and output being in the same repo. > > > > I find it confusing to have source and output in the different > > branches of the same Git repo, because they don't share any history. > > This causes some difficulties with GH, but some people seem to like it. > > > > > and I'm ok if html output = > > > https://github.com/apache/attic-site/tree/asf-site > > > I just fear that changing where html output is stored will cost more > > > migration work than letting it in the current > > > https://svn.apache.org/repos/asf/attic/site/docs/ > > > > > > > > > > > > > > > > > > > > > > > > > > docs to clarify: whatever we choose should not impact user > > > > > > > workflow, then I > > > > > > > think we should do what is easiest from a migration perspective > > > > > > > > > > > > Moving to Git will definitely affect the workfllow, so I don't > > > > > > understand the above paragraph. > > > > > users contribute to source, mainly in xdocs/ directory = where we > > > > > need Git PRs > > > > > > > > > > the build process that generates output html to docs/, commit and > > > > > distribution to target systems is completely hidden behind CI and CD > > > > > (HTML and other flag files deploy to target machines is CD) > > > > > > > > The standard build process for Git project websites also hides the > > > > build process behind CI. > > > I don't really get what is "standard build process": I suppose that it is > > > something provided by infra to build some sites like www.apache.org > > > (i fear it is based on buildbot = something I do not really master > > > personally...) > > > > > > > > > > I don't know what CD means. > > > continuous deployment = in the current case what pushes the html form svn > > > or Git to live machines with HTTP servers > > > > > > > > > > > > contributors to source don't really look at it > > > > > > > > ??? > > > > > > > > I'm not saying we should not move to Git, but I think we need to be > > > > clear that it is not a panacea, and it will involve quite a lot of > > > > work. > > > > We've not mentioned documentation yet. > > > > > > > > Who is going to do the work? > > > sure, there is a non trivial work to be done: I want to invest my own > > > time on it. > > > But I'll need help because I don't know everything on how Attic content > > > has been used beyond the pure https://attic.apache.org/ website > > > > As I wrote: who is going to do this? > > > > > > And how do we test that the new setup works OK? > > > > For example, we don't want to find that the Attic banners suddenly > > > > disappear from websites and wikis. > > > sure, the flag mechanism is exactly one topic I know I don't know > > > sufficiently to do it myself without your help and review = part of what > > > i called previously "how Attic content has been used beyond the pure > > > https://attic.apache.org/ website" > > > > > > my idea about keeping content in > > > https://svn.apache.org/repos/asf/attic/site/docs/ is exactly to limit the > > > risk when we change the source and build system: output and deployment to > > > live machines remain as it is > > > > > > did I miss something? > > > > Documentation and scripts, maybe more; I don't know. > > > > > do you find it reasonable enough that you give this plan a chance? > > > > I'm not convinced that the benefits are sufficient to offset the work > > involved. > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > Also, what about the current JIRA workflow that Attic uses? > > > > > > Would that be moved to Git somehow? > > > > > > Note that Attic would still need to use Jira for raising Infra > > > > > > issues. > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
