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 <dbar...@apache.org> Date: Tuesday, June 14, 2022 at 3:11 PM To: jb...@vmware.com.invalid <jb...@vmware.com.INVALID> Cc: dev@geode.apache.org <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 <jb...@vmware.com.invalid> 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 <dbar...@apache.org> > Date: Tuesday, June 14, 2022 at 12:15 PM > To: dev@geode.apache.org <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 when critical last-minute doc changes > are needed, but such changes are forbidden due to the code freeze. > > I have participated in the Geode project since its inception, and can > confidently state that this conflict arises with nearly every Geode > release. Setting up the docs in a separate repo would alleviate this > regularly-recurring, counter-intuitive situation. > > Of note: The docs directories and toolset are almost entirely independent > of directories and tools needed for code development and release, so > removal of the doc sources from the Geode code repo should be painless for > developers. > > Observations and opinions welcome... > > Dave Barnes > > ________________________________ > > ⚠ External Email: This email originated from outside of the organization. > Do not click links or open attachments unless you recognize the sender. > ________________________________ ⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
