docs: proposed TRG 7.09 #1045
docs: proposed TRG 7.09 #1045
Conversation
|
@eclipse-tractusx/automotive-tractusx-committers Please check |
|
@tom-rm-meyer-ISST should not the project leads deprecate the product? Not the committer it self. I would say the committer needs to inform the project leads |
There was a problem hiding this comment.
Hi @tom-rm-meyer-ISST thank you for proposing the TRG! Looks really good so far, just some comments.
If possible, I'd like to discuss the process in Committers Meeting this Friday (Oct. 11, 2024).
docs/release/trg-7/trg-7-09.md
Outdated
|
|
||
| ## Description | ||
|
|
||
| Deprecation applies to repositories of type `product`. This information is maintained in the repository metafile (see [TRG 2.05](../trg-2/trg-2-5.md)).Deprecation of a repository means that **the repository is beeing archived**. It's still accessible from within the project, so that it could be revived. Please refer to [this list for examples of archived repositories within Eclipse Tractus-X](https://github.com/eclipse-tractusx/?q=&type=archived&language=&sort=). |
There was a problem hiding this comment.
| Deprecation applies to repositories of type `product`. This information is maintained in the repository metafile (see [TRG 2.05](../trg-2/trg-2-5.md)).Deprecation of a repository means that **the repository is beeing archived**. It's still accessible from within the project, so that it could be revived. Please refer to [this list for examples of archived repositories within Eclipse Tractus-X](https://github.com/eclipse-tractusx/?q=&type=archived&language=&sort=). | |
| Deprecation of a repository means that **the repository is being archived**. It's still accessible from within the project, so that it could be revived. Please refer to [this list for examples of archived repositories within Eclipse Tractus-X](https://github.com/eclipse-tractusx/?q=&type=archived&language=&sort=). |
docs/release/trg-7/trg-7-09.md
Outdated
|
|
||
| **\*** The *past year's major release cycle* is the time span between the breaking change releases YY.06 e.g., 24.05 till 24.05. | ||
|
|
||
| ### Process |
There was a problem hiding this comment.
| ### Process | |
| ### Deprecation Process |
docs/release/trg-7/trg-7-09.md
Outdated
| A[1: Prepare list of unmaintained repositories] --> B[2-1 Inform Eclipse Tractus-X community] | ||
| B --> C[2-2: Draft critical issue for committer meeting] |
There was a problem hiding this comment.
maybe switch 2.1 and 2.2
| B --> C[2-2: Draft critical issue for committer meeting] | ||
| C --> D[3: 2 week period: Comment on issue for criteria discussion] | ||
| D --> E[4-1: Committer meeting: Discuss list] | ||
| E --> F[4-2: Send email to mailing list] |
There was a problem hiding this comment.
Isn't this already covered by step 2?
There was a problem hiding this comment.
My idea was like: make the committers and the community aware of the issue. Wait for a grace period (at least one meeting in between) and then inform community "these are subject to deprecation"
I really want to emphasize, that this also somehow should be aligned best to the release cycle as it makes most sense to make persons prior to planning aware of this. One might also consider to trigger the evaluation always in the .03 releases.
There was a problem hiding this comment.
The problem with the dependency to releases (or open plannings) is that that'll extend the grace period to multiple months in the worst case. Do we want that?
There was a problem hiding this comment.
Fair point. Likely not. If it's a platform component, we likely will stretch the grace period a little - but not by default.
Nevertheless, then we just need to align on whether we want to have the step 5 to communicate the deprecation planning during the open planning. I'm also fine if we don't do it.
Two mails (inform via mail that there are products that might be subject to deprecation in step 2 and in step 4 we would send a verified list of deprecation ready products) would still be OK, I think
Co-authored-by: Evelyn Gurschler <[email protected]> Co-authored-by: Arno Weiß <[email protected]>
|
Incorporated requested changes. Clearlydefined seems to be down. |
Description
Proposed a TRG for product deprecation including a process and criteria to close #1037
I didn't create a draft as I don't want to create two PRs following non-merged process within this PR.
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review: