Re: migrating Attic website source from svn to Git
On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy wrote: > Attic website is currently in svn: > https://svn.apache.org/repos/asf/attic/site/ > > with Git read-only mirror > https://github.com/apache/attic-site/ > > we are facing 2 issues: > - viewvc is not working any more on svn, which makes svn even less usable > nowadays than ever before: https://svn.apache.org/viewvc/attic > - people propose PRs on Git as it is common knowledge nowadays (who > remembers > how to do Jira issue with svn patch attached? who takes time to do it?) > > > I'd like that we switch to Git read-write for site's source maintenance > particularly the xdocs source > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > 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) > = https://svn.apache.org/repos/asf/attic/site/docs/ > What is important to me is to split the source xdocs from the generated > HTML > docs to clarify: whatever we choose should not impact user workflow, then > I > think we should do what is easiest from a migration perspective > > > WDYT? > Personally I would be in favour of moving the website to a more supported toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs and split out the two "flagged" parts that the banner stuff relies on Niall > > Regards, > > Hervé > > > > >
Re: migrating Attic website source from svn to Git
sure, this website modernization does not change anything to retirement process: it's just a side improvement to not desperate new joiners Jira issues serie created: https://issues.apache.org/jira/browse/ATTIC-239 https://issues.apache.org/jira/browse/ATTIC-240 https://issues.apache.org/jira/browse/ATTIC-241 working on ATTIC-239 for now: svn copy done, infrastructure-p6 PR 2145 https://github.com/apache/infrastructure-p6/pull/2145 in progress, which will be followed by cleanup On 2025/04/10 14:52:22 sebb wrote: > On Thu, 10 Apr 2025 at 11:47, Niall Pemberton > wrote: > > > > On Thu, 10 Apr 2025 at 08:52, sebb wrote: > > > > > On Thu, 10 Apr 2025 at 07:09, Hervé Boutemy wrote: > > > > > > > > Le mercredi 9 avril 2025, 13:33:08 CEST Niall Pemberton a écrit : > > > > > On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy > > > wrote: > > > > > > Attic website is currently in svn: > > > > > > https://svn.apache.org/repos/asf/attic/site/ > > > > > > > > > > > > with Git read-only mirror > > > > > > > > > > > > https://github.com/apache/attic-site/ > > > > > > > > > > > > we are facing 2 issues: > > > > > > - viewvc is not working any more on svn, which makes svn even less > > > usable > > > > > > nowadays than ever before: https://svn.apache.org/viewvc/attic > > > > > > - people propose PRs on Git as it is common knowledge nowadays (who > > > > > > remembers > > > > > > how to do Jira issue with svn patch attached? who takes time to do > > > it?) > > > > > > > > > > > > > > > > > > I'd like that we switch to Git read-write for site's source > > > maintenance > > > > > > particularly the xdocs source > > > > > > > > > > > > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > > > > > > > > > > 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) > > > > > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > > > > > What is important to me is to split the source xdocs from the > > > generated > > > > > > HTML > > > > > > docs to clarify: whatever we choose should not impact user workflow, > > > then > > > > > > I > > > > > > think we should do what is easiest from a migration perspective > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > Personally I would be in favour of moving the website to a more > > > supported > > > > > toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs > > > and > > > > > split out the two "flagged" parts that the banner stuff relies on > > > > > > > > yes, it also needs modernization to have a chance to get contributions/ > > > > contributors. > > > > > > But does the Attic website really need contributions? > > > What's needed is people to do the work, which is largely independent > > > of the website. > > > > > > > You're right that it currently works and the current people are more than > > capable of doing the work. However, people move on and for the long term, > > Attic would be in a better place maintenance-wise to move to Git and update > > the tech used. > > My point is that the need for maintenance of the site is minimal. > > > I agree with Hervé - lets take the first step of moving the site to Git. I > > think once thats done we should look at using Jekyll to generate the > > retired project pages. I can take a look at doing a PoC for that. > > I think the first step should be separating the banner flagging code > from the website. > The website can then be moved without hindrance. > > Indeed, I don't see how the website can be moved to Git without some > changes to how the banner code works. > > But someone needs to produce a plan as to what needs to be done to > ensure continuity. > > > Niall > > > > > > > > > > > it's a question of chicken and egg: ease contribution (particularly > > > review > > > > process) before changing all the source code and build? > > > > or change all the source code and build before easing contribution? > > > > > > > > Changing the build tool is my hope for future too: it's just not that > > > simple, > > > > more complex than going to Git for maintaining source code > > > > > > > > that's why I deliberately chose to start the modernization journey by > > > svn to > > > > Git, which will help us try and review the toolset > > > > > > > > Hervé > > > > > > > > > > > > > > Niall > > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > > > > >
Re: migrating Attic website source from svn to Git
Le dimanche 6 avril 2025, 00:17:19 CEST sebb a écrit : > > > > 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/ > > See else thread. cwiki_retired. yes, this was cited, unless there is something I did not understand > > I don't get what this all means: the concept is that nothing changes in > > svn as a result of the build, isn't it? > Infra tooling makes use of both source and generated output. I suppose this is another way to say the same - https://svn.apache.org/repos/asf/attic/site/docs/ - https://svn.apache.org/repos/asf/attic/site/cwiki_retired/ > The reference to SVN is to the SOURCE, which is being proposed for change. just call cwiki_retired in svn "output", as a copy of a source somewhere, and nothing changes we can also update cwiki_retired to be maintained like flagged: - source in https://svn.apache.org/repos/asf/attic/site/xdocs/ - output in https://svn.apache.org/repos/asf/attic/site/docs/ with copy from source to output done in build.sh then we'll have something consistent between the 2 types of flags > > There needs to be a plan to ensure that Infra tooling relating to > Attic banners can still access the files it needs, and if any of its > sources are changed, that there is a plan for how to migrate without > breaking anything. > > I don't know if there are any other references to Attic data files > apart from the ones used for adding banners. > > Have you had a look in the sources for the various Infra tools? > I think these are all now in Git repos. > > Should be easy enough, as there is currently only one Attic repo > (though you may need to allow for http(s) and alternate hosts such as > svn-master.a.o). yes, searching for "attic/" gives a good feeling we have everything https://github.com/search?q=repo%3Aapache%2Finfrastructure-p6+attic%2F&type=code > > > > > Regards, > > > > > > > > Hervé
Re: migrating Attic website source from svn to Git
On Thu, 10 Apr 2025 at 11:47, Niall Pemberton wrote: > > On Thu, 10 Apr 2025 at 08:52, sebb wrote: > > > On Thu, 10 Apr 2025 at 07:09, Hervé Boutemy wrote: > > > > > > Le mercredi 9 avril 2025, 13:33:08 CEST Niall Pemberton a écrit : > > > > On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy > > wrote: > > > > > Attic website is currently in svn: > > > > > https://svn.apache.org/repos/asf/attic/site/ > > > > > > > > > > with Git read-only mirror > > > > > > > > > > https://github.com/apache/attic-site/ > > > > > > > > > > we are facing 2 issues: > > > > > - viewvc is not working any more on svn, which makes svn even less > > usable > > > > > nowadays than ever before: https://svn.apache.org/viewvc/attic > > > > > - people propose PRs on Git as it is common knowledge nowadays (who > > > > > remembers > > > > > how to do Jira issue with svn patch attached? who takes time to do > > it?) > > > > > > > > > > > > > > > I'd like that we switch to Git read-write for site's source > > maintenance > > > > > particularly the xdocs source > > > > > > > > > > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > > > > > > > > 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) > > > > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > > > > What is important to me is to split the source xdocs from the > > generated > > > > > HTML > > > > > docs to clarify: whatever we choose should not impact user workflow, > > then > > > > > I > > > > > think we should do what is easiest from a migration perspective > > > > > > > > > > > > > > > WDYT? > > > > > > > > Personally I would be in favour of moving the website to a more > > supported > > > > toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs > > and > > > > split out the two "flagged" parts that the banner stuff relies on > > > > > > yes, it also needs modernization to have a chance to get contributions/ > > > contributors. > > > > But does the Attic website really need contributions? > > What's needed is people to do the work, which is largely independent > > of the website. > > > > You're right that it currently works and the current people are more than > capable of doing the work. However, people move on and for the long term, > Attic would be in a better place maintenance-wise to move to Git and update > the tech used. My point is that the need for maintenance of the site is minimal. > I agree with Hervé - lets take the first step of moving the site to Git. I > think once thats done we should look at using Jekyll to generate the > retired project pages. I can take a look at doing a PoC for that. I think the first step should be separating the banner flagging code from the website. The website can then be moved without hindrance. Indeed, I don't see how the website can be moved to Git without some changes to how the banner code works. But someone needs to produce a plan as to what needs to be done to ensure continuity. > Niall > > > > > > > it's a question of chicken and egg: ease contribution (particularly > > review > > > process) before changing all the source code and build? > > > or change all the source code and build before easing contribution? > > > > > > Changing the build tool is my hope for future too: it's just not that > > simple, > > > more complex than going to Git for maintaining source code > > > > > > that's why I deliberately chose to start the modernization journey by > > svn to > > > Git, which will help us try and review the toolset > > > > > > Hervé > > > > > > > > > > > Niall > > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > > > > >
Re: migrating Attic website source from svn to Git
On Thu, 10 Apr 2025 at 08:52, sebb wrote: > On Thu, 10 Apr 2025 at 07:09, Hervé Boutemy wrote: > > > > Le mercredi 9 avril 2025, 13:33:08 CEST Niall Pemberton a écrit : > > > On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy > wrote: > > > > Attic website is currently in svn: > > > > https://svn.apache.org/repos/asf/attic/site/ > > > > > > > > with Git read-only mirror > > > > > > > > https://github.com/apache/attic-site/ > > > > > > > > we are facing 2 issues: > > > > - viewvc is not working any more on svn, which makes svn even less > usable > > > > nowadays than ever before: https://svn.apache.org/viewvc/attic > > > > - people propose PRs on Git as it is common knowledge nowadays (who > > > > remembers > > > > how to do Jira issue with svn patch attached? who takes time to do > it?) > > > > > > > > > > > > I'd like that we switch to Git read-write for site's source > maintenance > > > > particularly the xdocs source > > > > > > > > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > > > > > > 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) > > > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > > > What is important to me is to split the source xdocs from the > generated > > > > HTML > > > > docs to clarify: whatever we choose should not impact user workflow, > then > > > > I > > > > think we should do what is easiest from a migration perspective > > > > > > > > > > > > WDYT? > > > > > > Personally I would be in favour of moving the website to a more > supported > > > toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs > and > > > split out the two "flagged" parts that the banner stuff relies on > > > > yes, it also needs modernization to have a chance to get contributions/ > > contributors. > > But does the Attic website really need contributions? > What's needed is people to do the work, which is largely independent > of the website. > You're right that it currently works and the current people are more than capable of doing the work. However, people move on and for the long term, Attic would be in a better place maintenance-wise to move to Git and update the tech used. I agree with Hervé - lets take the first step of moving the site to Git. I think once thats done we should look at using Jekyll to generate the retired project pages. I can take a look at doing a PoC for that. Niall > > > it's a question of chicken and egg: ease contribution (particularly > review > > process) before changing all the source code and build? > > or change all the source code and build before easing contribution? > > > > Changing the build tool is my hope for future too: it's just not that > simple, > > more complex than going to Git for maintaining source code > > > > that's why I deliberately chose to start the modernization journey by > svn to > > Git, which will help us try and review the toolset > > > > Hervé > > > > > > > > Niall > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > >
Re: migrating Attic website source from svn to Git
On Thu, 10 Apr 2025 at 07:09, Hervé Boutemy wrote: > > Le mercredi 9 avril 2025, 13:33:08 CEST Niall Pemberton a écrit : > > On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy wrote: > > > Attic website is currently in svn: > > > https://svn.apache.org/repos/asf/attic/site/ > > > > > > with Git read-only mirror > > > > > > https://github.com/apache/attic-site/ > > > > > > we are facing 2 issues: > > > - viewvc is not working any more on svn, which makes svn even less usable > > > nowadays than ever before: https://svn.apache.org/viewvc/attic > > > - people propose PRs on Git as it is common knowledge nowadays (who > > > remembers > > > how to do Jira issue with svn patch attached? who takes time to do it?) > > > > > > > > > I'd like that we switch to Git read-write for site's source maintenance > > > particularly the xdocs source > > > > > > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > > > > 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) > > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > > What is important to me is to split the source xdocs from the generated > > > HTML > > > docs to clarify: whatever we choose should not impact user workflow, then > > > I > > > think we should do what is easiest from a migration perspective > > > > > > > > > WDYT? > > > > Personally I would be in favour of moving the website to a more supported > > toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs and > > split out the two "flagged" parts that the banner stuff relies on > > yes, it also needs modernization to have a chance to get contributions/ > contributors. But does the Attic website really need contributions? What's needed is people to do the work, which is largely independent of the website. > it's a question of chicken and egg: ease contribution (particularly review > process) before changing all the source code and build? > or change all the source code and build before easing contribution? > > Changing the build tool is my hope for future too: it's just not that simple, > more complex than going to Git for maintaining source code > > that's why I deliberately chose to start the modernization journey by svn to > Git, which will help us try and review the toolset > > Hervé > > > > > Niall > > > > > Regards, > > > > > > Hervé > > > >
Re: migrating Attic website source from svn to Git
Le mercredi 9 avril 2025, 13:33:08 CEST Niall Pemberton a écrit : > On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy wrote: > > Attic website is currently in svn: > > https://svn.apache.org/repos/asf/attic/site/ > > > > with Git read-only mirror > > > > https://github.com/apache/attic-site/ > > > > we are facing 2 issues: > > - viewvc is not working any more on svn, which makes svn even less usable > > nowadays than ever before: https://svn.apache.org/viewvc/attic > > - people propose PRs on Git as it is common knowledge nowadays (who > > remembers > > how to do Jira issue with svn patch attached? who takes time to do it?) > > > > > > I'd like that we switch to Git read-write for site's source maintenance > > particularly the xdocs source > > > > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > > 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) > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > What is important to me is to split the source xdocs from the generated > > HTML > > docs to clarify: whatever we choose should not impact user workflow, then > > I > > think we should do what is easiest from a migration perspective > > > > > > WDYT? > > Personally I would be in favour of moving the website to a more supported > toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs and > split out the two "flagged" parts that the banner stuff relies on yes, it also needs modernization to have a chance to get contributions/ contributors. it's a question of chicken and egg: ease contribution (particularly review process) before changing all the source code and build? or change all the source code and build before easing contribution? Changing the build tool is my hope for future too: it's just not that simple, more complex than going to Git for maintaining source code that's why I deliberately chose to start the modernization journey by svn to Git, which will help us try and review the toolset Hervé > > Niall > > > Regards, > > > > Hervé
Re: migrating Attic website source from svn to Git
On Mon, 7 Apr 2025 at 22:15, Hervé Boutemy wrote: > > Le dimanche 6 avril 2025, 00:17:19 CEST sebb a écrit : > > > > > 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/ > > > > See else thread. cwiki_retired. > yes, this was cited, unless there is something I did not understand > > > > I don't get what this all means: the concept is that nothing changes in > > > svn as a result of the build, isn't it? > > Infra tooling makes use of both source and generated output. > I suppose this is another way to say the same > - https://svn.apache.org/repos/asf/attic/site/docs/ > - https://svn.apache.org/repos/asf/attic/site/cwiki_retired/ > > > The reference to SVN is to the SOURCE, which is being proposed for change. > just call cwiki_retired in svn "output", as a copy of a source somewhere, and > nothing changes > > > we can also update cwiki_retired to be maintained like flagged: > - source in https://svn.apache.org/repos/asf/attic/site/xdocs/ > - output in https://svn.apache.org/repos/asf/attic/site/docs/ > with copy from source to output done in build.sh > then we'll have something consistent between the 2 types of flags Of course you can move cwiki_retired but then you will have to change Puppet to use the new location, and make sure there is a smooth changeover. You don't appear to have considered that. Equally, one could move flagged. If anything is to be moved, I think that would make more sense, as flagged does not really need to be part of the Attic website, it just needs to be available to the web server somewhere. But again this would mean changes to Puppet and planning for a smooth changeover. > > > > There needs to be a plan to ensure that Infra tooling relating to > > Attic banners can still access the files it needs, and if any of its > > sources are changed, that there is a plan for how to migrate without > > breaking anything. > > > > I don't know if there are any other references to Attic data files > > apart from the ones used for adding banners. > > > > Have you had a look in the sources for the various Infra tools? > > I think these are all now in Git repos. > > > > Should be easy enough, as there is currently only one Attic repo > > (though you may need to allow for http(s) and alternate hosts such as > > svn-master.a.o). > > yes, searching for "attic/" gives a good feeling we have everything > > https://github.com/search?q=repo%3Aapache%2Finfrastructure-p6+attic%2F&type=code No, it does not. That only searches Puppet code. What about all the other Infra tools? Are there any other references? > > > > > > > Regards, > > > > > > > > > > Hervé > > >
Re: migrating Attic website source from svn to Git
On Wed, 9 Apr 2025 at 12:35, Niall Pemberton wrote: > > On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy wrote: > > > Attic website is currently in svn: > > https://svn.apache.org/repos/asf/attic/site/ > > > > with Git read-only mirror > > https://github.com/apache/attic-site/ > > > > we are facing 2 issues: > > - viewvc is not working any more on svn, which makes svn even less usable > > nowadays than ever before: https://svn.apache.org/viewvc/attic > > - people propose PRs on Git as it is common knowledge nowadays (who > > remembers > > how to do Jira issue with svn patch attached? who takes time to do it?) > > > > > > I'd like that we switch to Git read-write for site's source maintenance > > particularly the xdocs source > > https://svn.apache.org/repos/asf/attic/site/xdocs/ > > > > > > 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) > > = https://svn.apache.org/repos/asf/attic/site/docs/ > > What is important to me is to split the source xdocs from the generated > > HTML > > docs to clarify: whatever we choose should not impact user workflow, then > > I > > think we should do what is easiest from a migration perspective > > > > > > WDYT? > > > > Personally I would be in favour of moving the website to a more supported > toolset (markdown & Jekyll or Pelican?) and away from ant/anakia/xdocs and Note that the website build relies on Anakia code (e.g. xdocs/stylesheets/site.vsl) to construct the pages from XML sources. Someone would need to design, code, test and document a replacement, and update the scripts that generate the sources. > split out the two "flagged" parts that the banner stuff relies on That would be easier to do, but needs to be co-ordinated with Puppet changes to ensure continuity. I agree that things could be simplified, but it all currently works. > Niall > > > > > > > Regards, > > > > Hervé > > > > > > > > > >
Re: migrating Attic website source from svn to Git
On 2025/04/07 21:55:06 sebb wrote: > On Mon, 7 Apr 2025 at 22:15, Hervé Boutemy wrote: > > > > Le dimanche 6 avril 2025, 00:17:19 CEST sebb a écrit : > > > > > > 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/ > > > > > > See else thread. cwiki_retired. > > yes, this was cited, unless there is something I did not understand > > > > > > I don't get what this all means: the concept is that nothing changes in > > > > svn as a result of the build, isn't it? > > > Infra tooling makes use of both source and generated output. > > I suppose this is another way to say the same > > - https://svn.apache.org/repos/asf/attic/site/docs/ > > - https://svn.apache.org/repos/asf/attic/site/cwiki_retired/ > > > > > The reference to SVN is to the SOURCE, which is being proposed for change. > > just call cwiki_retired in svn "output", as a copy of a source somewhere, > > and nothing changes > > > > > > we can also update cwiki_retired to be maintained like flagged: > > - source in https://svn.apache.org/repos/asf/attic/site/xdocs/ > > - output in https://svn.apache.org/repos/asf/attic/site/docs/ > > with copy from source to output done in build.sh > > then we'll have something consistent between the 2 types of flags > > Of course you can move cwiki_retired but then you will have to change > Puppet to use the new location, and make sure there is a smooth > changeover. > You don't appear to have considered that. of course I considered, please consider I'm reasonable as you are > > Equally, one could move flagged. > If anything is to be moved, I think that would make more sense, as > flagged does not really need to be part of the Attic website, it just > needs to be available to the web server somewhere. > But again this would mean changes to Puppet and planning for a smooth > changeover. I'll do it: having consistent approach will clarify maintenance over time, so it's important for future maintenance by the whole team > > > > > > > There needs to be a plan to ensure that Infra tooling relating to > > > Attic banners can still access the files it needs, and if any of its > > > sources are changed, that there is a plan for how to migrate without > > > breaking anything. > > > > > > I don't know if there are any other references to Attic data files > > > apart from the ones used for adding banners. > > > > > > Have you had a look in the sources for the various Infra tools? > > > I think these are all now in Git repos. > > > > > > Should be easy enough, as there is currently only one Attic repo > > > (though you may need to allow for http(s) and alternate hosts such as > > > svn-master.a.o). > > > > yes, searching for "attic/" gives a good feeling we have everything > > > > https://github.com/search?q=repo%3Aapache%2Finfrastructure-p6+attic%2F&type=code > > No, it does not. > That only searches Puppet code. > What about all the other Infra tools? > Are there any other references? ok, extending the search to the whole org https://github.com/search?q=org%253Aapache+attic%252F&type=code and reviewing: found one interesting additional case: Whimsy with 2 matches: - https://github.com/apache/whimsy/blob/2a48953dbeb6350f5aaccae14873318daffa58a7/repository.yml#L37 - https://github.com/apache/whimsy/blob/2a48953dbeb6350f5aaccae14873318daffa58a7/lib/spec/lib/svn_wunderbar_spec.rb#L85 > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > >
Re: migrating Attic website source from svn to Git
On Sat, 5 Apr 2025 at 18:45, Herve Boutemy wrote: > > > > On 2025/04/05 15:00:46 sebb wrote: > > On Sat, 5 Apr 2025 at 15:09, Herve Boutemy 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. > which one, please? > playing cat and mouse? See else thread. cwiki_retired. > > > > 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. > I don't get what this all means: the concept is that nothing changes in svn > as a result of the build, isn't it? Infra tooling makes use of both source and generated output. The reference to SVN is to the SOURCE, which is being proposed for change. There needs to be a plan to ensure that Infra tooling relating to Attic banners can still access the files it needs, and if any of its sources are changed, that there is a plan for how to migrate without breaking anything. I don't know if there are any other references to Attic data files apart from the ones used for adding banners. Have you had a look in the sources for the various Infra tools? I think these are all now in Git repos. Should be easy enough, as there is currently only one Attic repo (though you may need to allow for http(s) and alternate hosts such as svn-master.a.o). > > > > > Regards, > > > > > > Hervé
Re: migrating Attic website source from svn to Git
On 2025/04/05 15:00:46 sebb wrote: > On Sat, 5 Apr 2025 at 15:09, Herve Boutemy 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. which one, please? playing cat and mouse? > > 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. I don't get what this all means: the concept is that nothing changes in svn as a result of the build, isn't it? > > > Regards, > > > > Hervé
Re: migrating Attic website source from svn to Git
On Sat, 5 Apr 2025 at 15:09, Herve Boutemy 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 wrote: > > > > > > On Fri, 4 Apr 2025 at 16:54, Herve Boutemy wrote: > > > > > > > > fair questions > > > > > > > > On 2025/04/04 13:04:57 sebb wrote: > > > > > On Fri, 4 Apr 2025 at 12:49, Herve Boutemy > > > > > 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
Re: migrating Attic website source from svn to Git
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 wrote: > > > > On Fri, 4 Apr 2025 at 16:54, Herve Boutemy wrote: > > > > > > fair questions > > > > > > On 2025/04/04 13:04:57 sebb wrote: > > > > On Fri, 4 Apr 2025 at 12:49, Herve Boutemy 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
Re: migrating Attic website source from svn to Git
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 wrote: > > On Fri, 4 Apr 2025 at 16:54, Herve Boutemy wrote: > > > > fair questions > > > > On 2025/04/04 13:04:57 sebb wrote: > > > On Fri, 4 Apr 2025 at 12:49, Herve Boutemy 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
Re: migrating Attic website source from svn to Git
On Fri, 4 Apr 2025 at 08:04, Hervé Boutemy wrote: > > Attic website is currently in svn: > https://svn.apache.org/repos/asf/attic/site/ > > with Git read-only mirror > https://github.com/apache/attic-site/ > > we are facing 2 issues: > - viewvc is not working any more on svn, which makes svn even less usable Hoever, the Git mirror helps here. > nowadays than ever before: https://svn.apache.org/viewvc/attic > - people propose PRs on Git as it is common knowledge nowadays (who remembers > how to do Jira issue with svn patch attached? who takes time to do it?) > > > I'd like that we switch to Git read-write for site's source maintenance > particularly the xdocs source > https://svn.apache.org/repos/asf/attic/site/xdocs/ > 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. > 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. > = 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? > 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. > 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é > > > >
Re: migrating Attic website source from svn to Git
On Fri, 4 Apr 2025 at 16:54, Herve Boutemy wrote: > > fair questions > > On 2025/04/04 13:04:57 sebb wrote: > > On Fri, 4 Apr 2025 at 12:49, Herve Boutemy 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 > h
Re: migrating Attic website source from svn to Git
On Fri, 4 Apr 2025 at 17:36, Herve Boutemy 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 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
Re: migrating Attic website source from svn to Git
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 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/ webs
Re: migrating Attic website source from svn to Git
fair questions On 2025/04/04 13:04:57 sebb wrote: > On Fri, 4 Apr 2025 at 12:49, Herve Boutemy 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é > > > > > > > > > > > > > > > > > > > >
Re: migrating Attic website source from svn to Git
On Fri, 4 Apr 2025 at 12:49, Herve Boutemy 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. > > > > > 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 know what CD means. > 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? 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. > > > > > 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é > > > > > > > > > > > > > >
Re: migrating Attic website source from svn to Git
> 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 > > > 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) contributors to source don't really look at it > > > 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é > > > > > > > > >
