-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Template for design docs #601
base: main
Are you sure you want to change the base?
Changes from 1 commit
46e89a8
eea2b4d
ac37672
6d8d4a9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
# Title | ||
|
||
Updated by: [0000-this-doc-does-not-exist]() | ||
|
||
Obsoleted by: [0000-this-doc-does-not-exist]() | ||
|
||
*(these sections should only be added when necessary, and should always include the links to the relevant documents)* | ||
|
||
## Introduction | ||
|
||
This section should bring a short summary of what this document is covering, the main points it is going to describe, and why it is important. Ideally should be kept under two paragraphs. | ||
|
||
## Context [optional] | ||
|
||
Explains the context outside the mere technical aspects of the design that existed when it was written. It must make clear what other influences where at play that affected the decisions that were taken. In case there is nothing relevant to mention about the context, this section can be skipped. | ||
|
||
## [Free-form sections] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I responded to the Go sample, I don't think this main H2 section should be free-form, its subsections sure can be. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's concentrate this discussion in this thread. |
||
|
||
The actual content of the design should be placed under one or more sections that can be named freely. Note that they should be level 2 headings (H2), but each section can also be subdivided by nested headings (H3, H4, H5 or H6) if needed. Only a single level 1 heading (H1) should exist, and it is strictly reserved for the title. | ||
Comment on lines
+18
to
+19
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not convinced there should be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree this looks good on the template, as it is more standardized, but having a large document with many subsections forced into a H2 brings a horrible result, at least IMO. As an example, check the Ruby design in this commit, and how I changed it in the following ones. For smaller docs, I believe a single H2 works perfectly. I am not sure what's the best option here. If nobody minds the excessive nesting (and the hard limit on the H5), then let's just make it a single H2. (I even considered a separate template for new package manager designs, although I think I still prefer to keep things simple). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We can agree that it's a matter of taste. On the other hand...
... if we ever need to go past H5 then I guess we need to rethink whether a given design really needs it, I don't expect that to be a regular thing, but I might be wrong here. |
||
|
||
## Decision/Outcome [pick one] | ||
|
||
Document here what decision was made, or what outcome is expected out of the design that was created. In case several options were presented in the design, this section must clearly state which one was chosen and the reasons for it. In case of a new package manager design, or a completely new feature to an existing package manager, this section can only include a brief summary of what the implementation will cover, since it is implied that the decision. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nitpick: Is the description of the intended content for these sections being purposefully done so that it can be rendered online? I mean, the only thing I expect from a template is to be copy-pasted, renamed, filled out and proposed. So, if we make these description commentaries, people can even keep those comments in their proposed doc and that information won't be rendered, just a bit of thinking out loud. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,26 +1,25 @@ | ||
# Initial Design for the Rubygems Package Manager | ||
|
||
- [Overview](#overview) | ||
- [Introduction](#introduction) | ||
- [Context](#context) | ||
- [Ruby ecosystem overview](#i-ruby-ecosystem-overview) | ||
- [Current implementation overview (Cachito)](#ii-overview-of-the-current-implementation-in-cachito) | ||
- [Design for the Cachi2 implementation](#iii-design-for-the-implementation-in-cachi2) | ||
- [Decision](#decision) | ||
- [Ruby ecosystem overview](#ruby-ecosystem-overview) | ||
- [Current implementation overview (Cachito)](#overview-of-the-current-implementation-in-cachito) | ||
- [Design for the Cachi2 implementation](#design-for-the-implementation-in-cachi2) | ||
- [Outcomes](#outcomes) | ||
|
||
## Overview | ||
## Introduction | ||
|
||
Design that covers the initial implementation of the Rubygem/Bundler package manager in Cachi2. It takes inspiration from the original implementation done in [Cachito](https://github.com/containerbuildsystem/cachito). | ||
Design that covers the initial implementation of the Rubygem/Bundler package manager in Cachi2. It takes inspiration from the original implementation done in [Cachito](https://github.com/containerbuildsystem/cachito). | ||
|
||
| | | | ||
|---------|---------| | ||
|Author |[Michal Šoltis]([email protected]) | | ||
|Co-author |[Bruno Pimentel]([email protected]) | | ||
|Proposed on |August 01, 2024 | | ||
This document has three main parts: | ||
- An overview on how the Ruby ecosystem works, touching only the parts that are relevant to the Cachi2 implementation | ||
- A quick overview on how the implementation was done in Cachito | ||
- The actual design for the implementation in Cachi2 | ||
|
||
## Context | ||
In the effort to evolve Cachi2 to be a full solution for the prefetching feature of Cachito, we have decided to implement support to the currently missing package managers: Rubygems and Yarn v1. This design covers only the implementation of Rubygems, and the Yarn v1 design will follow. | ||
|
||
## I. Ruby ecosystem overview | ||
## Ruby ecosystem overview | ||
|
||
### Development prerequisites | ||
In order to execute the commands in the examples below, make sure you have the following packages installed in your | ||
|
@@ -240,7 +239,7 @@ CHECKSUMS | |
This feature is available since Bundler [v2.5.0](https://github.com/rubygems/rubygems/blob/master/bundler/lib/bundler/lockfile_parser.rb#L55), | ||
from this [PR](https://github.com/rubygems/rubygems/pull/6374) being merged on Oct 21, 2023. | ||
|
||
## II. Overview of the current implementation in Cachito | ||
## Overview of the current implementation in Cachito | ||
|
||
[cachito/workers/pkg_mangers/rubygems.py](https://github.com/containerbuildsystem/cachito/blob/master/cachito/workers/pkg_managers/rubygems.py) | ||
|
||
|
@@ -258,7 +257,7 @@ which is vendored from | |
Source code for "official" Bundler lockfile parsing in Ruby: | ||
<https://github.com/rubygems/rubygems/blob/master/bundler/lib/bundler/lockfile_parser.rb> | ||
|
||
## III. Design for the implementation in Cachi2 | ||
## Design for the implementation in Cachi2 | ||
|
||
### Prefetching | ||
|
||
|
@@ -517,9 +516,7 @@ PATH | |
my-path-dependency (1.0.0) | ||
``` | ||
|
||
## Decision | ||
|
||
The support for Rubygems will be implemented as currently described in this design document. | ||
## Outcomes | ||
|
||
### Scoping of the initial implementation | ||
- design high-level code structure into multiple modules | ||
|
@@ -535,7 +532,7 @@ The support for Rubygems will be implemented as currently described in this desi | |
- add integration and e2e tests | ||
- add documentation | ||
|
||
### Potential follow-up features | ||
### Out of scope | ||
- implement checksum parsing and validation when prefetching from the registry | ||
- downloading the Bundler version specified in the `Gemfile.lock` | ||
- support for pre-compiled binaries (platforms other than `ruby`) | ||
|
|
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to have back links too? I.e. "Updates: 9999-this-doc-does-not-exist"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we do.