Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
The Geode project comprises several repos already, include geode, geode-examples, geode-benchmarks, geode-native, and geode-kafka-connector, and geode-site, so it’s not unreasonable to add another. However, we still release all at the same time, so any “code freeze” applies equally to all geode repos. Conceptually, “code freeze” applies to *code we ship*. Test-only or docs-only commits are welcome anytime. Actually, any commits are welcome at any time -- “freeze” just means the branch is tagged at the point in time the release manager creates RC1; any commits after that tag will simply become part of a future release (in the event we go to RC2, post-freeze commits may or may not be pulled into the current release, at the release manager’s discretion). Although the User Guide source files are currently part of the Geode source release, most users probably find the published website [1] more convenient. In my opinion, it should be fine to publish improvements to the doc site post-release (taking care to exclude commits related to unreleased new features, if any)...would that resolve the issue? > examples and usage guidelines can be finalized only AFTER the code, with all > its version numbers, naming conventions, etc, are in place. Chasing a moving target is definitely be frustrating; luckily there are things we can all do to minimize it. I’ve seen many PRs that update the docs at the same time as they change the product -- reviewers should check for this when reviewing any PR that affects a public API, config setting, etc. We also cut the support branch well in advance of planned release date and limit changes on the support branch to critical fixes only. Whenever necessary, anyone should feel free to file blocker tickets for missing/incorrect docs to ensure the release does not ship prematurely without meeting Geode’s standard of documentation. [1] https://geode.apache.org/docs/ From: Dave Barnes Date: Tuesday, June 14, 2022 at 3:11 PM To: jb...@vmware.com.invalid Cc: dev@geode.apache.org Subject: Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo ⚠ External Email John, Thanks for acknowledging that docs are just as important as code! As a career tech-writer, the "docs=code" model appeals to me. I get what you're saying, and have worked in environments where release managers have enforced such constraints. In this vein, the Geode code is well-supplied with embedded Javadoc comments that behave exactly as you describe, providing a reference that is updated as the code is updated. The difference with a user guide (as opposed to reference material), is that examples and usage guidelines can be finalized only AFTER the code, with all its version numbers, naming conventions, etc, are in place. Delaying code freeze until docs are complete, in my experience, engenders feature-creep and introduces delays, often resulting in compromises that allow the release to go out with mis-matched docs. IMO, a separate user-guide repo promotes a better and more timely match-up between the software and the user guide. On Tue, Jun 14, 2022 at 1:15 PM John Blum wrote: > Personally, I believe doc is a critical component to any software project, > especially a project like Apache Geode, and so, is the project really > “complete “(or should thee codebase really be frozen during a release) if > the doc is not done or consistent yet? > > Having the doc be part of the source allows the doc to be (theoretically) > in-sync with the codebase as it evolves, as it should be. On the other > hand, with a separate repo, it does allow corrections or other alterations > to be made at the risk of growing inconsistency, which is a huge impediment > IMO. In Asciidoc, doc can even be based on the source in part (e.g. > interfaces). > > Ideally, I don’t see code and doc being separate or even fundamentally > different. > > This sounds more like a process problem and a workaround to a broken > process, to me. > > $0.02 > -John > > > From: Dave Barnes > Date: Tuesday, June 14, 2022 at 12:15 PM > To: dev@geode.apache.org > Subject: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo > ⚠ External Email > > I'd like to move the doc sources for the Geode User Guide from the code > repo ( > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode&data=05%7C01%7Conichols%40vmware.com%7C90f35f9a69e9429c221c08da4e52c542%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637908414805059869%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w%2FOjA9CKepainPMniHOjz0kJ5TZE7VCFOetwcIojwsE%3D&reserved=0) > to a separate geode-docs repo. > > The primary reason is to allow docs to cycle at their own rate, rather than > in lock-step with the code. The present arrangement causes problems during > releases, when code is frozen (including doc sources) to prepare a release > candidate. This is exactly the time wh
Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo
Adopting a policy that allows changes to doc sources after code freeze would address my primary complaint about the present system. Updating the User Guide at the time a user-visible code change is implemented is a helpful step toward keeping the docs up-to-date with the code, but is not sufficient. Above and beyond individual enhancements, the user guide addresses topics such as system configuration, upgrades, and the like. Such higher-level topics are often modified asynchronously from code releases, as are typo and format repairs. For such asynchronous updates, the fact that the doc sources are located in the source repo is of little consequence. In fact, separate repos would allow separate revision histories, an advantage to both. One more consideration is the possibility of breaking the monolithic user guide into smaller separate publications, such as an installation guide, system management/administration guide, developer's guide, advanced topics, etc. A change like this would be easier if it started from a docs-only repo. Did any of those thoughts change anyone's mind? On Wed, Jun 15, 2022 at 12:29 AM Owen Nichols wrote: > The Geode project comprises several repos already, include geode, > geode-examples, geode-benchmarks, geode-native, and geode-kafka-connector, > and geode-site, so it’s not unreasonable to add another. However, we still > release all at the same time, so any “code freeze” applies equally to all > geode repos. > > Conceptually, “code freeze” applies to *code we ship*. Test-only or > docs-only commits are welcome anytime. Actually, any commits are welcome at > any time -- “freeze” just means the branch is tagged at the point in time > the release manager creates RC1; any commits after that tag will simply > become part of a future release (in the event we go to RC2, post-freeze > commits may or may not be pulled into the current release, at the release > manager’s discretion). > > Although the User Guide source files are currently part of the Geode > source release, most users probably find the published website [1] more > convenient. In my opinion, it should be fine to publish improvements to > the doc site post-release (taking care to exclude commits related to > unreleased new features, if any)...would that resolve the issue? > > > examples and usage guidelines can be finalized only AFTER the code, with > all its version numbers, naming conventions, etc, are in place. > Chasing a moving target is definitely be frustrating; luckily there are > things we can all do to minimize it. I’ve seen many PRs that update the > docs at the same time as they change the product -- reviewers should check > for this when reviewing any PR that affects a public API, config setting, > etc. We also cut the support branch well in advance of planned release > date and limit changes on the support branch to critical fixes only. > Whenever necessary, anyone should feel free to file blocker tickets for > missing/incorrect docs to ensure the release does not ship prematurely > without meeting Geode’s standard of documentation. > [1] https://geode.apache.org/docs/ > > From: Dave Barnes > Date: Tuesday, June 14, 2022 at 3:11 PM > To: jb...@vmware.com.invalid > Cc: dev@geode.apache.org > Subject: Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo > ⚠ External Email > > John, > Thanks for acknowledging that docs are just as important as code! As a > career tech-writer, the "docs=code" model appeals to me. > I get what you're saying, and have worked in environments where release > managers have enforced such constraints. > In this vein, the Geode code is well-supplied with embedded Javadoc > comments that behave exactly as you describe, providing a reference that is > updated as the code is updated. > The difference with a user guide (as opposed to reference material), is > that examples and usage guidelines can be finalized only AFTER the code, > with all its version numbers, naming conventions, etc, are in place. > Delaying code freeze until docs are complete, in my experience, engenders > feature-creep and introduces delays, often resulting in compromises that > allow the release to go out with mis-matched docs. IMO, a separate > user-guide repo promotes a better and more timely match-up between the > software and the user guide. > > > On Tue, Jun 14, 2022 at 1:15 PM John Blum > wrote: > > > Personally, I believe doc is a critical component to any software > project, > > especially a project like Apache Geode, and so, is the project really > > “complete “(or should thee codebase really be frozen during a release) > if > > the doc is not done or consistent yet? > > > > Having the doc be part of the source allows the doc to be (theoretically) > > in-sync with the codebase as it evolves, as it should be. On the other > > hand, with a separate repo, it does allow corrections or other > alterations > > to be made at the risk of growing inconsistency, which is a huge > impediment > >
