#2441 F34 System-Wide Change: RPM-level auto release and changelog bumping
Closed: Insufficient data 3 years ago by bcotton. Opened 3 years ago by bcotton.

Note: this was mistakenly announced as an F33 change on the mailing list. The owner corrected this in the thread.

redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping.


Hoping that somebody will implement necessary infra changes (as pointed on the ML) is clearly no-go.

-1

I think it would be nice, in the interest of others, that you disclosed you are not a neutral party (I don’t want to dig up recent dirt, but there is enough of it an honest broker would abstain from involving himself here).

I feel completely ill-equipped to make a decision here. I don't fully understand what's going on here and I'm having trouble wrapping my brain around it.

Unfortunately, this means I'm -1 until I understand this.

If I understand this correctly (macros monkey-patching / recreating SRPM files during the build process), it sounds like a bad idea.

This is also worrisome to me:

It is not possible to reproduce a build from the SRPM as it existed at the start of last build, since that SRPM does not know the date at which the next build occurred.

It also only works for packages that use macro framework, asking to be introduced in https://pagure.io/fesco/issue/2440

With all the limitations and caveats that are presented in the proposal, I don't think we can (or should) approve this, particularly since 2440 isn't even approved yet.

If I understand this correctly (macros monkey-patching / recreating SRPM files during the build process), it sounds like a bad idea.

You’re not understanding this part correctly, there is zero monkey-patching involved, and the main reason there are additional files involved is to avoid any form of monkey patching in the process, and separate cleanly input and output parts.

All the alternatives you’re seeing discussed on the list try to avoid the additional files requirement either by monkey-patching in place, or by hiding the additional data autobumping requires in various dark corners of the build infrastructure, creating SRPMs that do not contain the complete information needed for reproducibility or for export to other build systems.

It also only works for packages that use macro framework

Yes, sure that’s also a consequence of monkey patching avoidance. If you do not add the logic to bump within the spec (and the macros it uses), adding bumping involves injecting this logic externally ie monkey patching.

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

3 years ago

Since this is for F34 and #2440 needs to be decided first anyway, I think we can postpone the discussion of this without any harm. I'll unset the meeting tag.

Metadata Update from @zbyszek:
- Issue untagged with: meeting

3 years ago

Metadata Update from @cverna:
- Issue tagged with: stalled

3 years ago

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

3 years ago
  • AGREED: We need more information from the Change owner who is out of contact. We will wait until they return. (+6, 0, -0) (sgallagh, 14:09:10)

Metadata Update from @sgallagh:
- Issue untagged with: meeting

3 years ago

Metadata Update from @bcotton:
- Issue untagged with: F34
- Issue set to the milestone: Fedora 34

3 years ago

@nim are you still interested to implement this change ? and are you available to provide more info to FESCO ?

It's been months without any updates. I'm going to assume this proposal is dropped and will be resubmitted later if the owner desires.

Metadata Update from @bcotton:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.