I did not see: example of confusion between xdocs and docs: https://github.com/apache/attic-site/pull/2/files PR proposed updates output HTML docs/*.html instead of source xdocs/*.xml
as a first step, converting flagged from dirs to files: small PR to review https://github.com/apache/attic-site/pull/3 (I'll merge in svn once review is ok in GitHub) On 2025/04/04 15:30:10 Herve Boutemy 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/ > > 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 > > > 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? > do you find it reasonable enough that you give this plan a chance? > > > > > > > > > > > > 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é > > > > > > > > > > > > > > > > > > > > > > > > > > >
