I have just checked again if general Fedora-wide milestones have been created towards F39. So far, there are none, but F39 has been already branched. So I assume the related teams will this time not maintain gitlab milestones which we can “just adapt” to keep our gitlab calendar “compliant by default” to their schedule. I don’t see a sense in creating Docs-specific milestones since we would need to maintain and, if applicable, update/adjust them ourselves, which creates just more work.
But to be on time and to be able to plan sufficiently in advance, I just wanted to raise the tickets we have established towards the next Fedora release and which are currently in triage:
Indication about when to do what can be derived from the ticket #26 (this ticket for F40 still expects the milestones as they have existed in the past; but it thus also documents comprehensively when to do what, also for F39).
When taking into account that F39 is actually already branched, we are overdue with the tickets that relate to the notional “F39 branch from rawhide”-milestone:
Branch release notes for upcoming release
Branch guides for upcoming release
Create new branches on all related Docs repositories
Concerning new branches for repos in GitLab: is it correct that /fedora-linux-documentation/release-docs-home and /https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide are the only two remaining repos that have release-specific branches?
I wonder if that really makes sense at the moment. We would have several times as many tickets as people who could take over one. We would have a bunch of tickets that no one cares about and that we delete in a few weeks. The only one who could work on them are darknao, pbokoc and me. And I don’t think any of us need the Tickets. And no one else has shown up in the last 8 weeks who would and could take over such work.
That may look different again in six months if we are successful with the onboarding efforts.
Well, ensuring that the Fedora Docs pages/repos refer to the current
Fedora release and don’t hinder other teams’ tasks is a top priority,
above most other things. That’s the reason why I currently invest some
time for that. The question is of course what is really necessary (and
if anything is necessary at all) in the current infra organization. The
tickets were back then agreed to cover the necessities. But I know there
have been changes in the infra organization, which I don’t know
sufficiently. That’s why I opened the ticket.
I created the f39 branches in GitLab, but I don’t know what else is
necessary in the current infra organization (and generally what is
necessary in pagure). With necessary I mean of course “really
necessary”. I remember that in the past we had a big issue and
complaints where developers could no longer document their work for the
then-coming release because some branches in pagure were not created by
Fedora Docs (I think it was F36 or F37, but I don’t remember details).
This led us to create the tickets. I think avoiding such bottlenecks
that affect other teams is critical. However, I am not sure if the
current infra organization still depends on Docs this way.
My focus is currently on SELinux and kernel issues as well as Anaconda
in the second line, but when it comes to critical stuff that could have
such an impact, I could increase my work load temporarily. But I have
never focused on the pagure stuff, so I cannot help much there.
The relevant question is: does Fedora Docs need to do anything for F39,
which impacts the work of other teams towards the F39 release (except
the two mentioned GitLab repo branches)? So, does the work towards the
F39 release still depend on Docs in some way? I cannot answer this at
the moment.
As far as I know, we have to create a new branch in the release notes repo to enable developer to create their release notes contribution. pbokoc takes care of that. And additionally, we try to create the release notes by program. We discussed that with fesco a year ago or so. So, I think we have to do that, but currently we don’t need a ticket, IMHO.
And we have to branch our Linux homepage. But the only persons who write there were Hanku, you and me. And I guess, this release I’ll be the only one who writes some adjustments, if at all. I’m planning to add some text, but maybe I can’t make it for F39.
Cool. I closed all related tickets. I add to my schedule to create new f40 branches in the GitLab repos once F40 is branched. If the pagure issues are already handled by someone else, new tickets for all related activities seem obsolete anyway.
If I understand you right, the critical stuff is anyway the release notes-related branching pbokoc takes care of in pagure. But if there is anything else time-critical GitLab-sided, let me know if I can help to foster a smooth release transition in these realms.
Just to avoid that I missed something.