#2046 Change process: Releng impact tickets are tedious and possibly contribute to overwhelm releng
Closed: Accepted 5 years ago by psabata. Opened 5 years ago by churchyard.

Our changes policy demands a releng ticket for any change.

For all changes you need to file an issue in releng pagure to check if your change requires Release Engineering involvement:

  • You must work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.
  • File a ​ticket with Release Engineering when working on your change and link to it in your change page, with a detailed breakdown of changes needed.
  • Work must be substantially complete and in place by Branch point or FESCo might decide to apply the Contingency Plan.

How am I supposed to work with releng exactly? It seems that releng is overwhelmed with other tasks. The tickets are opened without responses (example).

I feel that requiring the releng ticket is just adding more to the releng's plate. Sometimes it feels even like a joke filling out issues for nothing.

Can we change the process? I see the following problem:

  • Change proposals authors might not always be aware that their change impacts releng.

The current solution is: Require a ticket, always. -- however that clearly doesn't work and doesn't scale.

Isn't FESCo a good enough proxy to decide whether a releng ticket is needed or not? I.e. wouldn't it work better if FESCo approves changes and decides whether releng needs to approve them as well?


I like the suggestion of having FESCo proxy for Releng. @mohanboddu and @nirik, what do you think?

If I remember correctly, this was requested by releng at some point. If they no longer feel this is useful, I'm in favor of dropping the requirement for changes without explicit releng involvment.

I think the request was that any Change that requires relent involvement had to have their approval first. So, anything that changes deliverables or the build/release toolchain. I think that part of this should stay.

any Change that requires releng involvement had to have their approval first

This should definitively remain so. What I see problematic is: Not all change owners can decide accurately whether their change requires releng involvement.

Hence, the process requires releng ticket for all changes. Note that the process doesn't require approval, just the ticket.

I propose we change the process so the ticket (and approval) is only needed when FESCo says so (and FESCo IMHO has the ability to recognize what changes (might) require releng involvement).

So yeah, this was added because people were filing and getting changes approved and then blindsiding releng with things late in the cycle.

I agree they are often not worthwhile, but also that it is sometimes hard to tell if there is releng impact.

I'm ok with the idea of fesco deciding if a ticket is needed, but I would like those points to definitely stay in the change guidelines (ie, tell people to work with releng early if there is any chance their change needs releng work).

I'll also try and work with @mohanboddu to close these out. I think there has been a workflow issues here too where releng acks the work, but forgets to close the ticket when work is done.

Since we don't have a formal proposal, I'll suggest one:

Proposal: Responsibility for determining a dependency on release-engineering changes for a Change Proposal is moved to the FESCo approval process. In cases where FESCo believes that releng needs to be involved, they will reach out to them prior to approving the Change.

+1

I'd like to here from @mohanboddu before I vote, but I'm inclined to +1.

The same.

@mohanboddu is it enough for you if we "@mention" you in the fesco ticket?

I was actually brought this up in my DevConf talk today, I didn't realize FESCo was already considering a change. My idea was to require a RelEng ticket for System-Wide changes and not for Self-Contained changes. (Change Owners or FESCo could still opt to request RelEng review, but we would not require it).

I'm fine with the proposed change, with some clarifications. Will FESCo request RelEng review before approving the change? If that's the case, we should give it a separate state that way I can easily pester RelEng if tickets sit for too long (we'd have to decide what too long is). Alternatively, will FESCo approve change proposals conditional on RelEng signoff? In that case, we would want to define a timeout period after which proposals default to accepted. In either case, we may also want to move change proposal deadlines ahead a week to account for this.

Another option would be to rely on RelEng to look at changes as they are announced and weigh in on Change proposals that impact them. I can add their mailing list to the announcements so that they don't have to wade through the devel{,-announce} traffic.

From the perspective of minimizing the process burden on Change Owners, I like this last option the best. But it does require RelEng to more actively track proposals and flag ones they are concerned about, which increases the risk of unexpected last-minute work.

My idea was to require a RelEng ticket for System-Wide changes and not for Self-Contained changes

I think that neither all System-Wide changes are relevant to RelEng nor all Self-Contained changes are irrelevant. I think it's better to judge this case-by-case.

Will FESCo request RelEng review before approving the change?

@sgallagh's proposal states "[FESCo] will reach out to [RelEng] prior to approving the Change". I think this is good enough: we'll open a ticket, and simply wait for a reply. We already do decide to wait for more input from various parties regularly, so this would be just another instance of that. If RelEng does not reply in a reasonable time-frame, we might simply vote anyway. But hopefully RelEng would normally reply promptly. With the much smaller number of tickets this should be easier for them.

I spoke with both @mohanboddu and @churchyard about this at DevConf.cz this weekend. Mohan said he would be on board with keeping it mandatory for System-Wide changes and optional for Self-Contained. Of course, FESCo could always request it for Self-Contained changes if they feel it's necessary.

The advantages of this method are that it cuts down dramatically on the number of tickets RelEng needs to address without introducing more delay in the process (I often announce changes if the RelEng ticket is open but not yet responded to so that the community discussion and RelEng verification can happen in parallel).

My concern with the

We already do decide to wait for more input from various parties regularly, so this would be just another instance of that.

(not just for this issue but generally) is that the voting policy doesn't cleanly account for that. When does the 7 day clock start if not from when the time the ticket is open? That's not to say that we can't adjust things to make this work, but there does need to be some kind of clarification of how that will work, otherwise tickets will languish (see ticket 2044 as another example of this)

Proposal:

System wide changes remain the same for now. For self contained changes if the proposal owner(s) think releng involvement is needed, they open a ticket, but it is not mandatory. If at least 2 FESCo members request releng ticket during the vote on the change, any agreement based on time is stopped and restarts when a link to the releng ticket is posted to the fesco ticket.

Miro's proposal addresses my concerns. I am in favor.

We're already starting to get some F31 Change proposals in. Can we get a vote on Miro's proposal? (and @mohanboddu are you in favor?)

I'm +0 at most currently. It seems too complicated and strict. If everybody else think it's necessary, I won't protest, but I think we could cut down the red tape a bit.

How about a less red-tape version:

proposal:

System wide changes remain the same for now. For self contained changes if the proposal owner(s) think releng involvement is needed, they open a ticket, but it is not mandatory.
Anyone who feels releng should be notified of and discuss the change can file a releng ticket anytime.

I think it's a little complex as well. Why not just let FESCo vote as usual, and part of that vote can include whether FESCo thinks it needs a releng ticket?

I'm on board with kevin's proposal.

+1 to @kevin's proposal

(I would support something along @bowlofeggs's comment too.)

Anyone who feels releng should be notified of and discuss the change can file a releng ticket anytime.

This is true already. FESCo should be able to hold the "automatically approved in a week" thing in such cases and that is what my red tape was trying to solve. Yet I guess a "-1" from a FESCo member can stop that as well, so we don't need that red tape.

So I am +1 to @kevin's proposal. I would also support a shorter proposal (without the last sentence). I would also support what @bowlofeggs says. it all IMHO means the same.

Metadata Update from @psabata:
- Issue tagged with: meeting

5 years ago
  * AGREED: System wide changes remain the same for now. For self
    contained changes if the proposal owner(s) think releng involvement
    is needed, they open a ticket, but it is not mandatory, Anyone who
    feels releng should be notified of and discuss the change can file a
    releng ticket anytime. (+8, 0, -0)  (contyk, 16:04:36)

Metadata Update from @psabata:
- Issue untagged with: meeting
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata