comm-release repository resurrection
Categories
(Developer Services :: Mercurial: hg.mozilla.org, task)
Tracking
(Not tracked)
People
(Reporter: rjl, Assigned: sheehan)
References
Details
The Thunderbird team is bringing back monthly stable releases, and will need comm-release again.
Rather than un-read-onlying the old repository, I'd prefer a clone of comm-beta but, using the name "comm-release".
For now, the permissions should be the same as comm-beta (scm_level_3)
This may be confusing no matter what we do (it already is).
Can the old comm-release just be moved out of plain sight so the fresh clone of beta (named comm-release) is the only one under /releases?
The reason for using a fresh clone is to not have the old old release branches making clutter -- represent the "new" Thunderbird now with less cruft!
Note there will be a follow-up bug for a comm-unified repository that works the same as the mozilla-unified repository.
|
Reporter | |
Comment 1•1 year ago
|
||
After further reflection, it's probably best to just un-readonly the old comm-release. That way the unified repo will have everything.
|
Assignee | |
Comment 2•1 year ago
|
||
Removed the .hg/readonlyreason file from comm-release.
|
|
Reporter | |
Comment 3•1 year ago
|
||
FYI, I don't know what this will affect.
/ansible/roles/hg-web/templates/mirror-filters.j2 -- does comm-release need to be on the "include.releases" line?
|
|
Assignee | |
Comment 4•1 year ago
|
||
(In reply to Rob Lemley [:rjl] from comment #3)
FYI, I don't know what this will affect.
/ansible/roles/hg-web/templates/mirror-filters.j2 -- does comm-release need to be on the "include.releases" line?
No, you're all set now.
Description
•