On Fri, 4 Apr 2025 at 17:36, Herve Boutemy <hbout...@apache.org> wrote: > > 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)
-1, it will break the banner detection code (see PR) > 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é > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
