On Mon, 2020-09-14 at 08:54 -0700, Kevin Fenzi wrote: ...snip... > I'll add that in addtion to some maintainers not wanting to maintain > their fedora packages also in epel, the timelines involved sometimes > make it so a package that was branched/maintained in epelX, makes no > sense in epelY. ie, Xfce 4.14 would be fine now, but in 3 years, 4.16 > or > whatever would make more sense and the package set may well not be > the > same. > Right, that's also a good reason for why branching by default is not a good option for all packages. > I wonder... could we somehow let maintainers indicate "I want my > package > branched for the next epel as soon as it's available"? I suppose in > part > thats what adding epel-sig would do? With the addition of 'epel-sig > should build by packages as soon as those branches are ready'. > I wonder if these are two separate concerns though? I agree that being able to indicate a package should always be branched would be great, but... epel-sig / epel-wranglers might not find a package relevant in a new EL release (e.g. say we care about neovim, and want to carry it by default in new releases, and thus we also care about some of its dependencies that are not in (RH)EL core -- but the set of dependencies we care about in EPEL7 != the set in EPEL8 etc. ^ if that seems explicit that's because it, uh, is from personal experience. Maybe package.cfg might be where such a metadata live? e.g. if the epel8 branch of the package has a package.cfg that says "branch for next release" it gets branched for epel9 -- and inherits that package.cfg by default. If a package gets opted in once and at some point is no longer needed in the next epel, just delete that. This might also suggest we want to have a delay before automatically branching so EPEL SIG / Wranglers have time to adjust that package.cfg after testing the next EL beta. > > There are several changes we can make to both streamline the > > process, > > and not increase the maintenance burden on the (other) maintainers > > of > > these packages: > > > > * Have an EPEL SIG modeled after the SIGs centered around > > programming > > language stacks (e.g. Python, Haskell, Java) > > * Have an expedited flow where this SIG can request EPEL branches > > and > > admin access to packages if there are no response from package > > maintainers for a set period (3 days? 1 week?) > > Both of those are really short... I guess a week or two might be ok. > 1-2 weeks is probably fine, yes, esp. as over time the need for such manual requests should go down. > > * whether it should be full admin access or whether such access > > should be scoped to epel* branches can be discussed. Full admin > > would > > make it possible to adjust the spec in Rawhide to be more EPEL > > friendly, for example > > * Members of the EPEL SIG can then branch these packages early when > > the > > next EL release is branched > > * The member of the SIG doing the branching should be designated as > > the > > primary EPEL assignee for that package > > How would that be designated? > Hmm. So right now (correct me if I'm wrong), it seems that only the main admin for a package can override the bugzilla assignee? I'm not sure about how this part would work yet. If at the beginning we try this out with manual infra ticket, I could imagine the EPEL SIG member that requests EPEL-SIG comaintainership for a package should ask the main admin to make them the EPEL assignee, or if it goes through an infra ticket, ask for infra to make that change? > > One deviation we might want to have from how Python SIG works is... > > we > > probably don't want to encourage packagers to add this EPEL SIG as > > a > > comaintainer preemptively, but only as needed. > > That would defeat the purpose of using epel-sig packages as 'always > branch' wouldn't it? > Right - I wasn't thinking of the 'always branch' case (once EPEL-SIG has commit access requesting a new branch is not a significant delay anyway). So 'branch for next' in package.cfg might be a better solution all around. How much tooling change would we need to get collaborators the ability to request branches if the branch name matches their whitelist, incidentally? > The other hazard if that different maintainers have different > workflows > and epel-sig folks would need to adjust to those. ie, some people > want > master to have epel conditionals and merge back to epel branches, > some > don't want that at all. I wonder if it wouldn't make sense to have > some > way to indicate to people what workflow is in effect for the package > (I > guess spec file comments?) > Maybe spec file comments as well as only granting collaborator (whitelisting epel* branches) instead of commit / admin access if they don't want EPEL conditionals? Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
