Discussion: What approach to use for migrating extensions
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- git, xml
- Domain
- documentation
Research direction
Start with this strategy discussion and the originating php/doc-extensions#11 issue; no file or test is named. Review the proposed bulk migration, preservation of Git history, DTD-to-XML entity fixes, and docbook-cs sweep. Done means the migration approach is agreed and a follow-up plan covers infrastructure and redirects.
Written by the indexing model from the issue text.
Description
Moving this out of php/doc-extensions#11 as it allows for a bit more room to plan strategy regarding migrating the extensions. And might reach a more broad audience.
First of all, what would be the very best method of migrating all extensions.
All in bulk with shared git commit history
Individually with git history
Don’t care about the git history
The primary reason we should preserve git history is to not lose the credibility that previous contributors have done over the years.
Migrating extensions individually would give the benefit of having a better understanding of what’s going on, and allow fixing what’s broken more easily but it will break those commits as some commits may have touched multiple extensions. Which is not the most positive outcome for existing contributors.
The suggested approach I have in mind is:
- Migrate all extensions at once assuming it will break
- See what's broken
- Fix it (which likely will be DTD entities that we need to change to XML entities
Once that's done, I suggest we do a docbook-cs sweep so it will help contributors to make changes. We don't need to care about translators being overwhelmed by big changes.
Then finally we can prepare to publish this new doc-extensions repo by making a plan for:
- Infastructure
- Redirects
- Etc, etc (will be a separate discussion once we are more ready for it).
- Dominant language
- XML
- Stars
- 2
- Forks
- 6
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 5
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from php/doc-extensions
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
php/doc-extensions#23 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
php/doc-extensions#28 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
php/doc-extensions#22 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
php/doc-extensions#27 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
php/doc-extensions#21 · 1 comment ·
All issues in php/doc-extensions
Similar issues
-
area:docs area:render bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1618 ·
Maintainers usually reply within 1 day
-
curriculum documentation quality
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
githubnext/gh-aw-workshop#3897 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
siderolabs/docs#791 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
nestjs/docs.nestjs.com#3554 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 98/100
huggingface/course#1320 ·
Maintainers usually reply within 1 day