On Sat, 5 Apr 2025 at 15:09, Herve Boutemy <hbout...@apache.org> wrote: > > 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?
Of course it's possible, but there is at least one reference to SVN source that you have overlooked. Generating the website from Git instead of SVN is relatively easy (but it's not trivial, e.g. dealing with deletions) However that is only part of it. The Attic banners are handled by Infra code, which expects to find the files in specific places. There needs to be a plan to show that these have been allowed for. > 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é > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
