notes about the opinions of the participants at the "Committer Round Table" at adaptTo() in berlin this year:
status report from robert: - scripts to split existing svn repo in multiple git repos including (most of) the history are ready - history is not correctly preserved for modules that where moved in svn from other paths (e.g. moved from contrib) - only the first move is preserved - robert did some research on alternatives to include this further history like git surgeon and a script from stack overflow - but they are now easy solutions, esp. because the SVN source repo is so big (all apache) - robert created a few migrated test git repos - there types of asf-github integrations: "mirroring" and "dual master". on the latter also allows pushes on github and directly merging of PRs there. discussed topics: - it's ok to loose some history in the migrated modules further down after several moves - the SVN is still in place (though should is put to read-only after the migration), so it's there for forensic analysis if needs arises. no need to invest more time here. - no need to migrate modules to git that are already in the attic - they are still in svn. - we have some special cases where we maintain non-trunk release branches (e.g. mocks 1.x, fsresource 1.x) - it's ok to not migrate them, and later create a release branch manuell for them in the git repo. the history for them is in SVN as well, and there is not lot activity on those branches. - use artifactid for git repository name plus prefix "sling-" (which is anyway mandatory) - do not include additional prefixes like "contrib-" or "attic-" etc. - if this status changes the git repo would need to be moved/renamed which is bad. instead, include a good-visible and status in each git repo's readme, linked to a documentation page (more on this laster) - if we create a repository accidentally or with a wrong name it can be deleted via infra and we can create a new one - whiteboard should be one single repo. personal gibhub spaces should only be used for preparing apache staff if the owner is a committer and only he pushes to this repo. if there are more than one or other contributions it should go to the whiteboard repo. - the preference is definitely for "dual master" because it's more convenient and easier to integrate PRs from outside and using all the github features. and there does not seem to be a drawback. - searching in the sling codebase will be limited - we assume it is not possible in the "apache" github organization to search only in "sling-*" repos. we accept this downside. search can be down locally in a checkout of all sling git repos. - we will create for convenience a repo which allows to clone all sling git repos e.g. with a tool like repo. we may also create group repos e.g. for all sling model modules, all mock modules etc. which allow to clone a set of directly related repos, and ideally also manage to have a reactor pom to build them with one command line call. - if we want to move a module to attic after migration to git we can do it like this: rename the master branch to "attic", and create a master branch that contains only a README informing about the attic status. thus it is clear this module is no longer maintained, not need to make it explicit read-only. github project settings - open questions - the github projects are automatically created by the INFRA tooling - we do not have administrative access on the github repos. but we may need to tweak some settings - is this possible for us to control this somehow in the repo creation process or later? examples: - switch off "issues", "projects", "wiki" in the github repos - in favor of our JIRA, confluence - set "tags" on the github repos which may be helpful to filter e.g. all sling repos, perhaps more finegrained as well like all "contrib" modules, all "models" repos etc.? READMEs for git repos - the current README.txt in the sling modules are in great majority really outdated (e.g. recommending using Maven 2, Java 5 or higher etc.) - on the git migration we should rename the old READMEs with a prefix for individual cleanup later, and generate a new README for each git repo - this README contains a unified preamble stating it's a sling module, link to the sling website etc. for all module - it should also include a status badge (different for each module) e.g. from: "core", "contrib", "attic" - this status should linked to a documentation page explaining what the status means plans for the further steps - do a full test migration of all sling modules into a test github organization (robert) - robert will write a mail to the mailing list and invite all to test them out (esp. modules they are most time working with), and give feedback if they see any problems - if all is will these repos and the test organization are thrown away, and the real migration is done to the ASF git with the same tooling and settings. a mail announcement is sent to do not commits on svn during the migration. after this the svn can be set to readonly by infra. - open question: if we do a test migration on a test github organization we create ourselves we cannot test the dual master stuff specific to apache. or should we create the test repos directly in the asf git? - once migrated to git we can add more features to the auto-generated jenkins CI jobs - like automatic building feature branches as well, perhaps switching to a "declarative pipeline mode" etc. do we need a vote before starting the real git migration? if anyone committer thinks we need this please raise a hand. otherwise the plan is to start this quite soon. stefan
