Thanks, Jeffery, Thomas! I would summarize the result as follows:
We 1) move our SVN repos to Git. Turbine SVNs as is (almost), Fulcrum as well using different repos (I follow Thomas' argument, git is not svn), but remove some components to the attic / archive or declare it dormant (as Apache Commons components currently inactive): Check list below *. I would suggest to clean up this as much as possible, before moving. Currently I count 20 fulcrum (including site, and excluding all in the list below) 2) release Turbine Core later after this is done ASAP. 3) use whatever is appropriate and supported by INFRA to publish our website, may it be Github tooling, Jenkins or what else. I am not sure, if we could follow Github tooling to the end .. I'll start with the process in INFRA-22176, see below as soon as possible.. @Thomas, thanks for helping out later with git modules, which may be not required, if we actually move/set up a separate repo "master build" (eg. a repo fulcrum-build from trunk/pom.xml +xdocs), as you suggested. Fulcrum-parent may be also an archive candidate, as I can't find any usages anywhere (?). If you think anything's missing here/wrong or have another idea, please don't hesitate .. Thanks so far! Best regards, Georg * Searching https://lists.apache.org/[email protected]:lte=3y:attic I found this list of candidates to archive: ( https://lists.apache.org/thread.html/50d1e77fb93dd290803347a5bfff00ccc1709ef31d3e59fb64d361cd%40%3Cdev.turbine.apache.org%3E : commonsemail configuration/impl hsqldb pbe naming resourcemanager groovy script spring xmlrpc xslt + jetty has a comment in master pom "needs upgrade to eclipse jetty", but may be as well archived? + bsf, osworkflow, dvsl, parent - Is this appropriate or should be more/less removed? To archive means IMO: Keep it in svn and do not migrate it to git; declare it like this. Von: Thomas Vandahl <[email protected]> An: Turbine Developers List <[email protected]> Datum: 15.08.2021 11:52 Betreff: Re: [VOTE] Migrate SVN Repos to Git, How to Migrate Site Building + Publishing +1 See comments below. > Am 12.08.2021 um 10:23 schrieb Georg Kallidis <[email protected]>: > > Hi Turbine Devs, > > I propose this as a vote, which allows us to get an overview of what we > want to do or have to do, the workload, and how to communicate with INFRA. > > SVN->Git > > (1.1) Move Turbine-core and Turbine-site from SVN to Git as detailed > below. Turbine-Core is currently mirrored only in GitHub/Gitbox. > > (1.2) Move Fulcrum components from SVN to Git. Fulcrum is currently > mirrored only in GitHub. > a) try to keep it in one git repo or if not possible split up. b) split it > up in any case. Find more information below! I'm in favour of 1.2b because releases from GIT use signed tags and in the future it would be difficult to know, which component release is meant by which tag. My understanding of GIT is, that, if in doubt, use more repos. > (1.3) Move Turbine Maven from SVN to Git as detailed below. > Turbine-Archetypes is already a GIT repo. > > (2) Performing a Turbine-core release v5.1: As this might take some time > depending on workload, should we release before the migration? If the release is not needed urgently by anyone (which I assume), a release after the migration might help to prove that everything works again. > We probably want still use the maven scm plugin to publish releases, but > for building and publishing web content we have to change more (as it > seems): > > (3) For each Git repo with a maven-site-configuration to build and publish > web content, we should define either > a) a Jenkins Build file(s) and/or b) a build directive within the > .asf.yaml-file (supports jekyll and pelican) c) an instruction, how to do > it locally, similar how it is explained here [2], but with additional > restrictions (see below .asf.yml file, web root folder). The last > alternative might be too much effort. It might be possible to do this > even for mirrored git-repos (we have to ask INFRA). Whether I like it or not: I see a lot of movement into the direction of Github tooling. Probably less maintenance, dunno. Shall we follow that road? > - Fulcrum components could be kept as currently in a single git repo or > split up each into a separate git repo. As consistent the latter approach > would be I would prefer keeping them together (if possible, see below!). > Reasons are: The master module pom will be "lost". This could be solved > with git modules, but requires some additional effort and advanced git > knowledge + documentation/testing IMO. Who will help? - Maintenance effort > increases (e.g. an update of a shared dependency has to be done in x (x= > number of git repos) commits versus 1 commit, if we keep them as a > collection also in version control. On the other side publishing has to be > discussed with INFRA and is not done out-of-the-box, see below. What do > you prefer? As stated above, I'm in favour for the one-component/one-repo solution. The parent POM is just another module - similar to the Turbine parent POM. If your concern is about local builds, it's just a matter of building the parent first. GIT modules are easy, I can help with that. I propose to create a separate "master build" repo with a layout suitable for building everything at once. I also support Jeffs idea of an attic of Fulcrum components. Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
