#2559 F34 Change: BIND 9.16
Closed: Accepted a month ago by zbyszek. Opened a month ago by bcotton.

BIND 9 would be updated to the upcoming stable version BIND 9.16.


+1

Prerelease is available on COPR.

That's always nice.

Prerelease is available on COPR.

It's also available in rawhide as of 4 days ago :smiling_imp:

+1 I guess

@pemensik In the future, would you please wait for an accepted change before doing the update, or let us know if the update needs to land more urgently?

I am sorry, this is my first change announced. I thought it works similar way to bodhi and three +1 are enough. I think I did not get correctly, what should I be waiting for once proposed the update.
Change Process Milestones mentions bug state, but my change does not have bug even assigned. I thought maybe it is not required for self-contained changes.

Is there change submission guide for developers I forgot to read?

I am sorry, this is my first change announced.

Don't worry about it, no harm done. That's why I've asked about the future.

I thought it works similar way to bodhi and three +1 are enough. I think I did not get correctly, what should I be waiting for once proposed the update.
Change Process Milestones mentions bug state, but my change does not have bug even assigned. I thought maybe it is not required for self-contained changes.

The change proposal is approved by FESCo following policy for any other tickets: https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy

tl;dr we will explicitly say once this is approved here

I agree that from the change policy it is not quite clear what happens after the Program Manager presents the change proposal to FESCo. Especially it does not mention at all that FESCo may accept the proposal, decline it or ask for modifications. Or that the approval needs to be explicit. @bcotton Can we extend that bit? Should I open a ticket?

The tracking bug is created only if/after the change is accepted.

Is there change submission guide for developers I forgot to read?

I don't think there is anything better than https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process

Thanks for the feedback about the documentation, I now see that it is not quite understandable by people who have not doe it before.

New version of package X changes are also a bit odd here... I mean what does it mean if FESCo rejects the change? The maintainer can never update the package again? It's just not advertised as a change?

Sometimes there's reasons to get upgrades done sooner rather than later too, like before mass rebuild or something.

But yeah, I agree in general it's good to wait for approval. :)

It would be nice do document, how should approval look like. For people like me, who never did it, it is not clear when approval is given or still pending. From tags in other issues here, it seems to me approved tag would be better than "pending announcement". It really does not help, because that change was already announced on devel list. It should be documented, what different announces are used and what they differ in.

Anyway, green tag approved and red rejected would be nice. Just a comment at the end of an issue is not very visible IMO. Because for me as a developer, pending announcement not very important. Approval is.

Basically, the ticket is closed as Accepted or Rejected once everything is ready. But decisions in tickets with "pending announcement" are already considered official.

The documentation is constantly evolving. :-) I'll make some improvements based on the feedback in this ticket.

After a week, the vote is (+8,0,-0). Processing the change as approved.

Metadata Update from @bcotton:
- Issue tagged with: pending announcement

a month ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a month ago

Login to comment on this ticket.

Metadata