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é > > > > > > > > > > > > > > > > > > > > > > > > > >
