asf-tooling commented on issue #469:
URL: 
https://github.com/apache/tooling-trusted-releases/issues/469#issuecomment-4410256538

   <!-- gofannon-issue-triage-bot v2 -->
   
   **Automated triage** — analyzed at `main@2da7807a`
   
   **Type:** `discussion`  •  **Classification:** `no_action`  •  
**Confidence:** `high`
   **Application domain(s):** `project_committee_management`, 
`shared_infrastructure`
   
   ### Summary
   Issue #469 is a tracking/epic issue organizing the 'Project model track' — a 
multi-phase effort to make ATR the authoritative source for PMC project and 
release data. It groups ~25 sub-issues across schema refactoring, update 
process changes, PMC update workflows, and new models. Several sub-issues have 
been completed recently: migration 0074 (2026-05-04) implements #912 
(ProjectCycle + version metadata), and migration 0076 (2026-05-06) implements 
#914 (LifecycleEvent). Many sub-issues remain open. @hboutemy suggested 
projects should have a distribution area path; @dave2wave redirected that to 
issue #460.
   
   ### Where this lives in the code today
   
   #### `atr/models/sql.py` — `Project` (lines 714-722)
   _currently does this_
   The Project model now includes version-scheme metadata fields 
(version_method, version_pattern, cycle_match, branch_template) added by 
sub-issue #912.
   
   ```python
   class Project(sqlmodel.SQLModel, table=True):
       key: str = sqlmodel.Field(primary_key=True, unique=True, 
**example("example"))
       name: str | None = sqlmodel.Field(default=None, **example("Apache 
Example"))
       status: ProjectStatus = sqlmodel.Field(default=ProjectStatus.ACTIVE, 
**example(ProjectStatus.ACTIVE))
       ...
       version_method: VersionMethod = 
sqlmodel.Field(default=VersionMethod.SIMPLE, **example(VersionMethod.SIMPLE))
       version_pattern: str | None = sqlmodel.Field(default=None, 
**example(r"^\d+\.\d+\.\d+$"))
       cycle_match: str | None = sqlmodel.Field(default=None, 
**example(r"^(\d+)\.\d+\.\d+$"))
       branch_template: str | None = sqlmodel.Field(default=None, 
**example("release-{cycle}"))
   ```
   
   #### `atr/models/sql.py` — `ProjectStatus` (lines 163-167)
   _currently does this_
   ProjectStatus enum already includes lifecycle statuses relevant to tracking 
PMC projects.
   
   ```python
   class ProjectStatus(enum.StrEnum):
       ACTIVE = "active"
       DORMANT = "dormant"
       RETIRED = "retired"
       STANDING = "standing"
   ```
   
   #### `atr/models/sql.py` — `VersionMethod` (lines 244-247)
   _currently does this_
   VersionMethod enum added as part of sub-issue #912 to support different 
version scheme types.
   
   ```python
   class VersionMethod(enum.StrEnum):
       SIMPLE = "simple"
       SEMVER = "semver"
       CALVER = "calver"
   ```
   
   #### `atr/models/sql.py` — `LifecycleEventType` (lines 262-268)
   _currently does this_
   LifecycleEventType enum added as part of sub-issue #914 for tracking release 
lifecycle events.
   
   ```python
   class LifecycleEventType(enum.StrEnum):
       RELEASE = "release"
       ARCHIVE = "archive"
       WITHDRAW = "withdraw"
       EOD = "eod"
       EOS = "eos"
       EOL = "eol"
   ```
   
   #### `migrations/versions/0074_2026.05.04_0d6e9554.py` — `upgrade` (lines 
22-37)
   _currently does this_
   Migration implementing sub-issue #912 (ProjectCycle table and version 
metadata), created just 4 days ago.
   
   ```python
   def upgrade() -> None:
       # project: add version-scheme metadata. Existing rows default to 
"simple".
       with op.batch_alter_table("project", schema=None) as batch_op:
           batch_op.add_column(
               sa.Column(
                   "version_method",
                   sa.Enum("SIMPLE", "SEMVER", "CALVER", name="versionmethod"),
                   nullable=False,
                   server_default="SIMPLE",
               )
           )
           ...
       op.create_table(
           "projectcycle",
           ...
       )
   ```
   
   #### `migrations/versions/0076_2026.05.06_e5fa9b30.py` — `upgrade` (lines 
39-52)
   _currently does this_
   Migration implementing sub-issue #914 (LifecycleEvent table), created just 2 
days ago.
   
   ```python
   def upgrade() -> None:
       op.create_table(
           "lifecycleevent",
           sa.Column("id", sa.Integer(), nullable=False),
           sa.Column("project_key", sa.String(), nullable=False),
           sa.Column("cycle_key", sa.String(), nullable=True),
           sa.Column("version_key", sa.String(), nullable=True),
           sa.Column(
               "event",
               sa.Enum("RELEASE", "ARCHIVE", "WITHDRAW", "EOD", "EOS", "EOL", 
name="lifecycleeventtype"),
               nullable=False,
           ),
           ...
       )
   ```
   
   #### `atr/get/projects.py` — `projects` (lines 47-54)
   _currently does this_
   Project directory page already exists, serving as the basis for the 'source 
for finding out about PMC projects'.
   
   ```python
   @get.typed
   async def projects(_session: web.Public, _projects: Literal["projects"]) -> 
str:
       """
       URL: /projects
       Main project directory page.
       """
       async with db.session() as data:
           projects = await 
data.project(_committee=True).order_by(sql.Project.name).all()
   ```
   
   #### `atr/db/__init__.py` — `Session.project_cycle` (lines 432-441)
   _currently does this_
   Query builder for the new ProjectCycle model, supporting the version cycle 
tracking from sub-issue #912.
   
   ```python
       def project_cycle(
           self,
           cycle_key: Opt[str] = NOT_SET,
           project_key: Opt[str] = NOT_SET,
           cycle: Opt[str] = NOT_SET,
           _project: bool = False,
           _releases: bool = False,
       ) -> Query[sql.ProjectCycle]:
           query = sqlmodel.select(sql.ProjectCycle)
           ...
   ```
   
   ### Proposed approach
   This is a tracking/epic issue with no single implementation. Work proceeds 
through individual sub-issues. Recent activity shows sub-issues #912 and #914 
were implemented in the last few days (migrations 0074 and 0076). The remaining 
open sub-issues (#465, #462, #470, #473, #510, #507, #498, #468, #443, #433, 
#478, #640, #479, #184, #180, #139, #911, #913, #614) should be addressed 
individually. No single diff is appropriate for this tracking issue.
   
   ### Open questions
   - What is the status of sub-issues #911 and #913 (the other two items under 
'4. Models')?
   - Are any of the remaining unchecked sub-issues blocked or deprioritized?
   - The distribution area path suggestion from @hboutemy — is it being tracked 
in #460 or does it need its own sub-issue under this track?
   
   _The agent reviewed this issue and is not proposing patches in this run. 
Review the existing-code citations and open questions above before deciding 
next steps._
   
   ### Files examined
   - `atr/models/sql.py`
   - `migrations/versions/0074_2026.05.04_0d6e9554.py`
   - `migrations/versions/0076_2026.05.06_e5fa9b30.py`
   - `atr/db/__init__.py`
   - `atr/get/projects.py`
   - `atr/post/projects.py`
   - `migrations/versions/0001_2025.05.15_1d3ee5a0.py`
   - `atr/docs/database.md`
   
   ---
   *Draft from a triage agent. A human reviewer should validate before merging 
any change. The agent did not run tests or verify diffs apply.*


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to