Re: Fedora rawhide compose report: 20241218.n.0 changes
On 12/18/24 03:07, Fedora Rawhide Report wrote: = DROPPED PACKAGES = Package: libtimezonemap-0.4.5.3-2.fc41 Summary: Time zone map widget for Gtk+ RPMs:libtimezonemap libtimezonemap-devel Size:12.34 MiB libtimezonemap seems to have been prematurely retired. While anaconda no longer requires it (which was the justification for retirement), cinnamon still does: https://src.fedoraproject.org/rpms/cinnamon/blob/rawhide/f/cinnamon.spec#_118 https://github.com/linuxmint/cinnamon/blob/master/files/usr/share/cinnamon/cinnamon-settings/modules/cs_calendar.py#L10 Please unretire the package immediately, and if you are no longer interested in maintaining it, put it up for adoption instead. -- Yaakov Selkowitz Principal Software Engineer, Emerging RHEL Red Hat, Inc. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Council update [was Re: On revoking provenpackager from probinson]
The Fedora Council met today. After our regular meeting (where we're taking the next formal step in the gitforge process!) [1], we had a private video call for about half an hour on this topic. As transparency is part of what's at issue, we intentionally did not make any decisions in that call; we just needed the higher bandwidth to help understand the situation. After, we followed up with another ad-hoc public meeting [2]. >From this, we have two actions: First, we ask FESCo to put their decision on hold while we investigate, and to restore Peter's proven-packager access in the meantime. Second, we are going to compile a factual report of what happened and when. This is going to take some time (and would even without the holidays), and I appreciate your patience. The specific situation connects into broad questions about what "proven packager" should be — and even bigger ones about what it means to be a package maintainer in Fedora. I hope that we can improve how we collaborate and communicate overall. Once we have a full understanding, we will make recommendations on next steps, and possibly adjust Council policies. [1]: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-12-18/fedora-council-meeting.2024-12-18-15.03.html [2]: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-12-18/ad-hoc-council-meeting-about-the-proven-packager-process-and-recent-fesco-decision-on-proven-packager-rights-removal.2024-12-18-16.10.html -- Matthew Miller Fedora Project Leader -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On Tue, Dec 17, 2024 at 02:28:09PM +0100, Vít Ondruch wrote:
>
> Dne 16. 12. 24 v 23:13 Miroslav Suchý napsal(a):
> >Dne 16. 12. 24 v 7:03 odp. Miro Hrončok napsal(a):
> >>
> >>And based on my experience, I doubt this particular
> >>provenpackager status was stripped based on something like that.
> >>
> >>Sure, I guess we all agree that the line is fuzzy and probably
> >>not very well documented/defined. That does not mean we use that
> >>to justify problematic provenpackager behavior.
> >
> >I agree with Miro.
> >
> >I doubt anyone complains about release-bumps.
> >
> >In past, I complained about other PP commits (not probinson) -
> >they changed somehow random parts of spec. E.g. URL in SOURCEX. Or
> >/usr/bin to %{_bindir}. This changes were either problematic for
> >my workflow or simply incorrect. And these changes (directly done
> >in dist-git) were not triggered by any issue. Though, I was alway
> >able to resolve it with the author without the need to reach
> >FESCO.
> >
>
> This is not recent example, but really bad example of PP's work IMHO:
>
> https://src.fedoraproject.org/rpms/ruby/c/c31c7edb6913eb7417ee68c59997548df2943dde
>From 2014, when the pull-request workflow didn't exist. I'm not sure
what the alternative was back then. Send a specfile patch to the
maintainer by email? Discuss it on IRC? (We don't actually know
whether or not those things occurred.)
I suspect given the year and the context, Peter was probably doing
this to add Arm support.
Anyway about the content of the change, rather than the communication:
- The use of wildcards in .gitignore is a large change, but also an
improvement.
- Renumbering the patch lines is invasive perhaps, but the result is
cleaner. I probably wouldn't have done this to someone else's
spec.
- A new patch was added with a clear reference to upstream status.
- Forcing the Tcl/Tk version needs an explanation.
It would be nice if these had been done as separate commits, but again
this was back in 2014 when things were looser.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On 12/18/24 8:26 PM, Kevin Fenzi wrote: Since I have not chimed in on this yet, let me just say that I am deeply sorry how the communication/timing/process went here. At the least I should have realized that many fesco members would be already away this week, so with lack of quorum, it's hard for fesco as a whole to respond or take actions. I too am one of those who is supposed to be away, but I've found this week far from relaxing. ;( Please make sure to 'plug out' and take time for yourself and others that are important to you as well. A bit of history for those that haven't been around a long time: (at least from my memory, please do let me know if I misremember here!) ...snip.. I *really* like tidbits like this. Thank you for the story it contains many things on why people might have different ideas of the roles and process for provenpackagers depending on when they joined the Fedora project. I personally kind of like the idea of telling provenpackagers to use pull requests, but I don't thats sufficent. It should be a pull request that also explains why. "Update to new version" isn't good enough communication. It should be "Update to fix build because this is needed for foo which has a serious bug which I am trying to fix before users hit it" or something similar would be much better. I wonder if perhaps now (or with a new gitforge) we could also raise visibility somehow? A weekly report of "here's the things provenpackagers did" and we can get more data on who is doing what for what reason. If there's packages that provenpackagers are often committing on perhaps they need more help? We could, but it's might be difficult to tell which hat someone was wearing at the time a certain PR was made. I don't think we can change the policy with hard timelines. Urgency and importatance will be subjective and could be wildly different between cases. However, again something to think about with a new gitforge is perhaps we should have a lifecycle for everything? ie, if you submit a pull request right now, it just sits there until closed or merged. Even if it has conflicts. Even if it's against f37 or something. What I'd like to see is to remove provenpackagers, do everything through PRs and have a separate SIG/group that can fast-track and merge any PR. This lets us verify that the changes are clean, minimal, and still allows some human fast-track to skip some checks and balances if we must. There could of course be some sort of exception(s) for mass rebuilds or such. Finally we should clarify the arch teams. When aarch64/ppc64le/s390x were moving into primary we did have a ton of activity and there were things that needed pushed quickly to get things working. Likely the same will be the case for riscv. At the start of them being primary we still sent arch teams bugs and issues to deal with, but I think slowly over time thats eroded and since most of those are just mainstream now, maintainers often just handle issues themselves with upstream help. Do we still want provenpackagers from those arches to push fixes? I would argue yes, but again communication is very important. I do think a new gitforge may be a good chance for us to adjust our workflows both to it and to better serve everyone. Perhaps a lot can be done with the new forge but we shouldn't ascribe it mythical properties. A PR-like workflow will hopefully be easier in ForgeJo and managing ACLs likely as well. For the rest we'd need a bunch of CI and bots (however: I really like the idea of auto-closing/rebasing PRs against old branches). There's definitely a lot we can gain here. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
Oh, one additional item I wanted to mention... I wonder if we could encourage maintainers/community members to do something like this: https://cassidoo.co/post/remote-intros/ TLDR: a small page listing your contact prefs, timezones, etc. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Hi, > On 18. Dec 2024, at 17:51, Fabio Valentini wrote: > > On Wed, Dec 18, 2024 at 10:43 AM Clemens Lang wrote: >> >> See https://src.fedoraproject.org/rpms/stunnel, or >> https://src.fedoraproject.org/rpms/gnutls, owned by @crypto-team. > > Looks like there are multiple different things being conflated here: > > The "main admin" of neither of these packages is the @crypto-team > group - groups *cannot* be the "main admin”. > […] > > Then there is the default bugzilla assignee, which *can* be a group > too, but the default bugzilla assignee is not the "main admin". Being > orphaned means that the "main admin" is "orphan", the default bugzilla > assignee is set independent of that. I realized that after I clicked send, but I don’t think it really makes a difference. The main admin for many of the packages maintained by the crypto team is no longer the person that takes care of the tickets by default. For example, Sahana used to maintain stunnel, but I am now the main maintainer. OpenSSL’s officially owned by Sahana, but Dima is doing most of the work. ca-certificates is now by default handled by Frantisek, not Bob. We never bothered changing this in pagure. We shuffle packages around roughly once a year depending on workload and interest. What matters is that somebody reacts to tickets filed against a package, and we do that. -- Clemens Lang RHEL Crypto Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Wed, Dec 18, 2024 at 10:55:13AM -0600, Jason Tibbitts wrote: > > maxwell--- via devel-announce > > writes: > > > fedscm-admin cqi, ignatenkobrain, limb, 3 weeks > > ago > > mohanboddu, orphan, tibbs > > > > I can't think of any reason this shouldn't simply be retired. All of > the SCM processing is now handled via a completely different method, and > I doubt the tool has any utility at all now. Yeah. I have retired it. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 6:35 PM Clemens Lang wrote: > > I realized that after I clicked send, but I don’t think it really makes a > difference. > The main admin for many of the packages maintained by the crypto team is no > longer the person that takes care of the tickets by default. > > For example, Sahana used to maintain stunnel, but I am now the main > maintainer. OpenSSL’s officially owned by Sahana, but Dima is doing most of > the work. ca-certificates is now by default handled by Frantisek, not Bob. We > never bothered changing this in pagure. We shuffle packages around roughly > once a year depending on workload and interest. What matters is that somebody > reacts to tickets filed against a package, and we do that. In that case, your group is obviously not one of the problematic cases here :) Still, it might make sense to just "give" the packages to the person who currently does the bulk of the maintenance, just so it's clear for people who look at the package who to contact in case going through the group is not possible. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forming a lightweight SIG around MkDocs
On Wed, Dec 18, 2024 at 6:31 PM Matthew Miller wrote: > > On Wed, Dec 18, 2024 at 11:17:12AM -0600, Michel Lind wrote: > > but the only document I see for creating a SIG is still only a wiki page > > https://fedoraproject.org/wiki/Creating_a_Fedora_SIG > > This all desperately needs a refresh. All I ask is: please, please don't > create a new mailing list. :) Well ... Just making a SIG is the easy part. But where more bureaucracy comes into play is when you want to have the SIG also be a group in FAS, and in dist-git. For the latter (i.e. also be able to add the group with commit access to packages), you actually *MUST* create a mailing list, which needs to be associated with the bugzilla account of the group, and where bugzilla will send bugmail for packages associated with the group. This requirement might well go away with the new forge / bug tracker, but for now, that's all still necessary. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[heads up] update to astyle 3.6.6 with a soname bump in rawhide
Hi, I am going to update astyle to the latest 3.6.6 version that changes ABI and also changes soname. The 2 dependent packages (codeblocks and kdevelop) will be rebuilt in a side-tag. Dan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Council update [was Re: On revoking provenpackager from probinson]
On 12/18/24 6:27 PM, Matthew Miller wrote: The Fedora Council met today. After our regular meeting (where we're taking the next formal step in the gitforge process!) [1], we had a private video call for about half an hour on this topic. As transparency is part of what's at issue, we intentionally did not make any decisions in that call; we just needed the higher bandwidth to help understand the situation. After, we followed up with another ad-hoc public meeting [2]. ForgeJo is indeed very exciting, I'm looking forward to it. From this, we have two actions: First, we ask FESCo to put their decision on hold while we investigate, and to restore Peter's proven-packager access in the meantime. Second, we are going to compile a factual report of what happened and when. This is going to take some time (and would even without the holidays), and I appreciate your patience. The specific situation connects into broad questions about what "proven packager" should be — and even bigger ones about what it means to be a package maintainer in Fedora. I hope that we can improve how we collaborate and communicate overall. Once we have a full understanding, we will make recommendations on next steps, and possibly adjust Council policies. Sounds good. Perhaps this mail also deserves a new thread on its own? It seems there's still some things simmering in the other threads :) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 09:03:45AM +, Daniel P. Berrangé wrote: > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > > The following packages are orphaned and will be retired when they > > > are orphaned for six weeks, unless someone adopts them. If you know for > > > sure > > > that the package should be retired, please do so now with a proper reason: > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > I see lots of packages that are orphaned, but have one or more > > co-maintainer. Sometimes they may quickly take the package, sometimes they > > may be on holidays. > > > > Would you object if promote a co-maintainer to main maintainer for orphaned > > packages and make it a rule? > > Broadly it is a good idea, but with impl questions due to Pagure. > > IIUC Pagure only allows for 1 "main admin" (owner). What would you suggest > if there are currently 2 (or more) "admin"s (co-maintainers). Arbitrarily > pick 1 of the many to promote? Or do nothing and let them choose ? > > This is a problem I would hope our Pagure replacement will trivially fix > for us, on the dist-git side at least. Other forges don't typically have > a distinction between a single "main admin" and other "admins". Repos are > "owned" by the collective of all admins who are equal peers. So there's > no problem until the very last admin wants to leave. It's not actually a pagure problem, the reason we have a main admin is basically bugzilla. You can have as many CC as you want in a bugzilla bug, but there can only be 1 account assigned to the ticket. This is why in pkgdb we had an "owner" which got changed to "point of contact" in pkgdb2 and "main admin" in pagure. Pierre -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
* Miroslav Suchý [18/12/2024 12:59] : > > emails. And instead of putting the package on the list, it would the API > call to pagure and assign the package to another co-maintainer. So there > will be alway one main-maintainer. If there are several co-maintainers, which one do you choose? If one of those co-maintainers is there to maintain a specific part of the package (a given feature, bindings to $LANGUAGE, ...), how do you ensure he is not promoted to main admin? Emmanuel -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 2:25 odp. Emmanuel Seyman napsal(a): If there are several co-maintainers, which one do you choose? Anyone. If one of those co-maintainers is there to maintain a specific part of the package (a given feature, bindings to $LANGUAGE, ...), how do you ensure he is not promoted to main admin? If it is not best decision (very likely) then they have all time in the world to swap places. But without the 6-week presure that the package will be retired. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 13:18 Miroslav Suchý napsal(a): Dne 18. 12. 24 v 10:53 dop. Daniel P. Berrangé napsal(a): I don't accept that co-maintainers are (or should be assumed to be) "typically" non-responsive. That is a depressing denigration of many Fedora co-maintainer's work. During this year, as part of my work on SPDX, I opened several hundreds PR at src.fedoraproject.org. Only fraction of the maintainers reacted. I do not have hard data on my hand, It could be about 20-30% of maintainer that responded. Definitelly way bellow of 40%. That is the reality. I wish it would be different. But I cannot change it. And we should not deny it. BTW what problem do you want to fix actually? Having orphaned packages on itself is not a problem IMHO. Having owned packages with unresponsive maintainers *is* real problem OTOH. I your SPDX case, you should be happy that packages are removed from Fedora faster. Vít Yes, there will be cases where a co-maintainer is not responsive, but we shouldn't design our policy to assume our maintainers are doing a bad job by default. Hold on. Non-responsive maintainer != bad job. Fedora is made of volunteers. They have they own work. They own priorities. Maybe they just become parent. Or they have hard times. And they do not want to be connected right now. And then we have a package that have release every few years. The spec changelog consists of "mass rebuild for FXX". And the package works without problem. And we have many of such packages. And suddenly main maintainer orphans the package. And we have 6 weeks window where we need to find a new maintainer. In situation where there is co-maintainer - likely willing to take over the package. But if he did not read emails in 6 weeks, does it make them doing a bad job? I do not think so. OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
aprsd orphan 4 weeks ago xdemorse orphan 4 weeks ago xpsk31orphan 4 weeks ago I've taken these. Cheers Davide -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On 18. 12. 24 12:53, Miroslav Suchý wrote: Dne 18. 12. 24 v 10:53 dop. Miro Hrončok napsal(a): When the package is orphaned (e.g. because the buzgilla that said it does not install was ignored by all 8 maintainers), it would be assigned to one of them, we are at 7 maintainers. It would take 8 another weeks to orphan it again, and again, and again. In such case the package should be retired, isn't it? No. It's should be orphaned, so it can get a maintainer to fix it. This maintainer may or may not be from the co-maintainers list. Only if it gets no new main admin in 6 weeks, it's retired. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
Since I have not chimed in on this yet, let me just say that I am deeply sorry how the communication/timing/process went here. At the least I should have realized that many fesco members would be already away this week, so with lack of quorum, it's hard for fesco as a whole to respond or take actions. I too am one of those who is supposed to be away, but I've found this week far from relaxing. ;( On Mon, Dec 16, 2024 at 12:01:11PM +, Daniel P. Berrangé wrote: ...snip... > While there can be reasons to push directly to git, I think it should be > considered very exceptional. Again I think this would be helped if the > guidelines explicitly said that opening a PR is the strongly favoured > default approach. > > Personally, I would aim to mandate PR is used exclusively for everything > done in Fedora. Even if that PR gets immediately almost approved & merged > by the same person, it at least enables automated CI to catch clearly > FTBFS problems. This would need very good automation to make it scale > in the scenarios where large distro wide changes are needed. So today I'd > be fine with just saying PRs are simply the default strongly preferred > option. It'd be better than the vague language used today about how > PP should communicate with maintainers. I think it's pretty clear we need to try and get some more clarity around communication here, so I think this subthread is worth continuing. A bit of history for those that haven't been around a long time: (at least from my memory, please do let me know if I misremember here!) In the 'fedora extras' days anyone in the packager group could commit (cvs!) to any package. (ie, everyone was provenpackagers) At the start of fedora/extras merge, anyone in the packager group could commit to lots of things. However there were a few ex core packages that were locked down. In 2008 ish, this was changed: https://fedoraproject.org/wiki/User:JesseKeating/NewMaintainerContainment https://fedoraproject.org/wiki/User:JesseKeating/NewMaintainerContainment and as part of that a new group was made: uberpackager! https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EFZWNCWZTU33B3YWXJNZRBQEH7YZLRI5/ (and a 99 post thread about the name, which was changed to provenpackager). As part of this some packages could still choose to not allow provenpackagers commit. The early docs had: "To become a provenpackager, you must ask an existing provenpackager to sponsor you into the group. This is a much less involved process than initial sponsorship. Usually just asking is all it will take. Most maintainers probably will not need to be provenpackagers, so you shouldn't apply for this access unless you need it." https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group&oldid=81650 I remember (but can't find my meeting logs from, so I might be mistaken) that the idea at the time was that provenpackager should be very easy to get. You just needed someone to vouch for you that you knew. Also, the initial provenpackager group was seeded from packagers with > 5 packages (or something similar). Anyhow, not sure thats too useful, but I thought it might inform on things we have done/tried in the past. There's a bunch more of course. I personally kind of like the idea of telling provenpackagers to use pull requests, but I don't thats sufficent. It should be a pull request that also explains why. "Update to new version" isn't good enough communication. It should be "Update to fix build because this is needed for foo which has a serious bug which I am trying to fix before users hit it" or something similar would be much better. I wonder if perhaps now (or with a new gitforge) we could also raise visibility somehow? A weekly report of "here's the things provenpackagers did" and we can get more data on who is doing what for what reason. If there's packages that provenpackagers are often committing on perhaps they need more help? I don't think we can change the policy with hard timelines. Urgency and importatance will be subjective and could be wildly different between cases. However, again something to think about with a new gitforge is perhaps we should have a lifecycle for everything? ie, if you submit a pull request right now, it just sits there until closed or merged. Even if it has conflicts. Even if it's against f37 or something. Finally we should clarify the arch teams. When aarch64/ppc64le/s390x were moving into primary we did have a ton of activity and there were things that needed pushed quickly to get things working. Likely the same will be the case for riscv. At the start of them being primary we still sent arch teams bugs and issues to deal with, but I think slowly over time thats eroded and since most of those are just mainstream now, maintainers often just handle issues themselves with upstream help. Do we still want provenpackagers from those arches to push fixes? I would argue yes, but again communica
Re: Forming a lightweight SIG around MkDocs
On Wed, Dec 18, 2024 at 12:55:07PM +, Davide Cavalca wrote: > MkDocs (https://www.mkdocs.org/) is a Markdown-based website maker, geared > towards technical documentation. The CentOS Project has historically used > MkDocs for SIG documentation, and the CentOS Docs SIG has recently > standardized on MkDocs for the overall project, leading to the creation of a > collated documentation site at https://docs.centos.org (sources: > https://gitlab.com/CentOS/docs/docs.centos.org). > > To ease this work, I've been working on getting the MkDocs stack back in > shape in Fedora, with the goal of eventually branching it for EPEL 10. > Because MkDocs is quite sprawling, I'd like to setup a lightweight SIG > around it to ease package maintenance of the stack. By "lightweight" I mean > that I expect this will mostly be used for package ACLs and bug triage. > While I mostly expect folks from the CentOS Docs SIG to join in, this is by > all means open to anybody interested in collaborating. > For completeness, this is the infra request https://pagure.io/fedora-infrastructure/issue/12337 cc Packaging group to see if we should consider making the process of creating a new SIG better documented FESCo has a policy document on specific SIGs' rules https://docs.fedoraproject.org/en-US/fesco/SIG_policy/ but the only document I see for creating a SIG is still only a wiki page https://fedoraproject.org/wiki/Creating_a_Fedora_SIG Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forming a lightweight SIG around MkDocs
On Wed, Dec 18, 2024 at 11:17:12AM -0600, Michel Lind wrote: > but the only document I see for creating a SIG is still only a wiki page > https://fedoraproject.org/wiki/Creating_a_Fedora_SIG This all desperately needs a refresh. All I ask is: please, please don't create a new mailing list. :) -- Matthew Miller Fedora Project Leader -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 libtimezone unannounced removal
On Wed, 2024-12-18 at 15:08 +, Leigh Scott wrote: > Please readd libtimezone for f42 and give me ownership. > > https://bugzilla.redhat.com/show_bug.cgi?id=2333021 > > https://src.fedoraproject.org/rpms/libtimezonemap/c/3e1e20e5d49c4a3b144f8fb285c4b913dfc9bd43?branch=rawhide IMHO , we should move the ticket to component libtimezonemap the only dependency is one hard require in cinnamon [1]https://src.fedoraproject.org/rpms/cinnamon/blob/rawhide/f/cinnamon.spec#_118 [1] Depending on: libtimezonemap (1) cinnamon cinnamon-6.2.9-1.fc41.x86_64 requires libtimezonemap(x86-64) = 0.4.5.3-2.fc41 -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 2:04 AM Daniel P. Berrangé wrote: > > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > > The following packages are orphaned and will be retired when they > > > are orphaned for six weeks, unless someone adopts them. If you know for > > > sure > > > that the package should be retired, please do so now with a proper reason: > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > I see lots of packages that are orphaned, but have one or more > > co-maintainer. Sometimes they may quickly take the package, sometimes they > > may be on holidays. > > > > Would you object if promote a co-maintainer to main maintainer for orphaned > > packages and make it a rule? > > Broadly it is a good idea, but with impl questions due to Pagure. > > IIUC Pagure only allows for 1 "main admin" (owner). What would you suggest > if there are currently 2 (or more) "admin"s (co-maintainers). Arbitrarily > pick 1 of the many to promote? Or do nothing and let them choose ? > > This is a problem I would hope our Pagure replacement will trivially fix > for us, on the dist-git side at least. Other forges don't typically have > a distinction between a single "main admin" and other "admins". Repos are > "owned" by the collective of all admins who are equal peers. So there's > no problem until the very last admin wants to leave. > One thing I hope we never do is allow something to be principally owned by groups as a rule. As a general practice, "groups" are bad at being responsible for packages when the chips are down. It is difficult to figure out if a package is being administered. Having a singular point of contact in that scenario is beneficial, and I would prefer we maintain that going forward in any new system. Will we? I don't know. People have been trying to make loopholes for this for years anyway, and every loophole implementation sucks in their own way. Just look at all the "foo-maint" accounts that represent some team for a package. Ultimately those accounts are useless for being responsible for the package and creates issues for us over the long-term as we cannot figure out if there's anyone behind a package in the first place. Pagure had the distinction because our policy needed it, and I don't particularly disagree with that need. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Forming a lightweight SIG around MkDocs
MkDocs (https://www.mkdocs.org/) is a Markdown-based website maker, geared towards technical documentation. The CentOS Project has historically used MkDocs for SIG documentation, and the CentOS Docs SIG has recently standardized on MkDocs for the overall project, leading to the creation of a collated documentation site at https://docs.centos.org (sources: https://gitlab.com/CentOS/docs/docs.centos.org). To ease this work, I've been working on getting the MkDocs stack back in shape in Fedora, with the goal of eventually branching it for EPEL 10. Because MkDocs is quite sprawling, I'd like to setup a lightweight SIG around it to ease package maintenance of the stack. By "lightweight" I mean that I expect this will mostly be used for package ACLs and bug triage. While I mostly expect folks from the CentOS Docs SIG to join in, this is by all means open to anybody interested in collaborating. Cheers Davide -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forming a lightweight SIG around MkDocs
On Wed, Dec 18, 2024 at 5:55 AM Davide Cavalca wrote: > > MkDocs (https://www.mkdocs.org/) is a Markdown-based website maker, > geared towards technical documentation. The CentOS Project has > historically used MkDocs for SIG documentation, and the CentOS Docs SIG > has recently standardized on MkDocs for the overall project, leading to > the creation of a collated documentation site at https://docs.centos.org > (sources: https://gitlab.com/CentOS/docs/docs.centos.org). > > To ease this work, I've been working on getting the MkDocs stack back in > shape in Fedora, with the goal of eventually branching it for EPEL 10. > Because MkDocs is quite sprawling, I'd like to setup a lightweight SIG > around it to ease package maintenance of the stack. By "lightweight" I > mean that I expect this will mostly be used for package ACLs and bug > triage. While I mostly expect folks from the CentOS Docs SIG to join in, > this is by all means open to anybody interested in collaborating. > I think this is great! Thanks for this! :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: On revoking provenpackager from probinson
On Tue, Dec 17, 2024 at 11:00:49PM -0800, Adam Williamson wrote: > make one up on the fly, which seems not to have gone optimally. But I > don't think the reasonable conclusion to draw from this is "everything > must either fall under the CoC or nothing". Strong agree. Code of Conduct Committee is stressful enough as it is. -- Matthew Miller Fedora Project Leader -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F42 libtimezone unannounced removal
Please readd libtimezone for f42 and give me ownership. https://bugzilla.redhat.com/show_bug.cgi?id=2333021 https://src.fedoraproject.org/rpms/libtimezonemap/c/3e1e20e5d49c4a3b144f8fb285c4b913dfc9bd43?branch=rawhide -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 libtimezone unannounced removal
releng ticket filed https://pagure.io/releng/issue/12505 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 libtimezone unannounced removal
libtimezone = libtimezonemap -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 10:43 AM Clemens Lang wrote: > > Hi Neal, > > > On 18. Dec 2024, at 10:21, Neal Gompa wrote: > > > > One thing I hope we never do is allow something to be principally > > owned by groups as a rule. > > See https://src.fedoraproject.org/rpms/stunnel, or > https://src.fedoraproject.org/rpms/gnutls, owned by @crypto-team. Looks like there are multiple different things being conflated here: The "main admin" of neither of these packages is the @crypto-team group - groups *cannot* be the "main admin". There are some "legacy" groups (that predate the actual concept of "groups" AFAIK) that *act* as groups but which are normal user accounts (for example, "java-sig") that just happen to be shared between multiple people. Those *can* be "main admin". Then there is the default bugzilla assignee, which *can* be a group too, but the default bugzilla assignee is not the "main admin". Being orphaned means that the "main admin" is "orphan", the default bugzilla assignee is set independent of that. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 3:40 PM Miroslav Suchý wrote: > > Dne 18. 12. 24 v 2:25 odp. Emmanuel Seyman napsal(a): > > If there are several co-maintainers, which one do you choose? > > Anyone. That's literally the worst way to handle this IMO. Packages that get orphaned due to long-standing "issues" (FTI / FTBFS) means that *all* co-maintainers have failed to address these issues - *all* of them should have been CC'd on the corresponding bugs and reminders. Promoting any one of them to "main" maintainer just to keep the package from being retired just prolongs the time frame in which a broken package is present in Fedora. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
> maxwell--- via devel-announce > writes: > fedscm-admin cqi, ignatenkobrain, limb, 3 weeks > ago > mohanboddu, orphan, tibbs > I can't think of any reason this shouldn't simply be retired. All of the SCM processing is now handled via a completely different method, and I doubt the tool has any utility at all now. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 libtimezone unannounced removal
On Wed, Dec 18, 2024 at 03:08:25PM -, Leigh Scott wrote: > Please readd libtimezone for f42 and give me ownership. > > https://bugzilla.redhat.com/show_bug.cgi?id=2333021 > > https://src.fedoraproject.org/rpms/libtimezonemap/c/3e1e20e5d49c4a3b144f8fb285c4b913dfc9bd43?branch=rawhide Indeed, this is actually used by cinnamon $ fedrq whatrequires 'libtimezonemap*' cinnamon-6.4.2-2.fc42.x86_64 $ fedrq whatrequires 'libtimezonemap*' -b f41 cinnamon-6.2.9-1.fc41.x86_64 libtimezonemap-devel-0.4.5.3-2.fc41.i686 libtimezonemap-devel-0.4.5.3-2.fc41.x86_64 cc-ing the packaging list - I notice the retirement process currently does not really mention any requirement to check for affected packages / to provide heads-up, which is a bit surprising since we do that (implicitly) for updating packages at least in stable releases. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#Unretire_a_Package Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 02:15:23PM +0100, Pierre-Yves Chibon wrote: > On Wed, Dec 18, 2024 at 09:03:45AM +, Daniel P. Berrangé wrote: > > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > > > The following packages are orphaned and will be retired when they > > > > are orphaned for six weeks, unless someone adopts them. If you know for > > > > sure > > > > that the package should be retired, please do so now with a proper > > > > reason: > > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > > > I see lots of packages that are orphaned, but have one or more > > > co-maintainer. Sometimes they may quickly take the package, sometimes they > > > may be on holidays. > > > > > > Would you object if promote a co-maintainer to main maintainer for > > > orphaned packages and make it a rule? > > > > Broadly it is a good idea, but with impl questions due to Pagure. > > > > IIUC Pagure only allows for 1 "main admin" (owner). What would you suggest > > if there are currently 2 (or more) "admin"s (co-maintainers). Arbitrarily > > pick 1 of the many to promote? Or do nothing and let them choose ? > > > > This is a problem I would hope our Pagure replacement will trivially fix > > for us, on the dist-git side at least. Other forges don't typically have > > a distinction between a single "main admin" and other "admins". Repos are > > "owned" by the collective of all admins who are equal peers. So there's > > no problem until the very last admin wants to leave. > > It's not actually a pagure problem, the reason we have a main admin is > basically > bugzilla. You can have as many CC as you want in a bugzilla bug, but there can > only be 1 account assigned to the ticket. > This is why in pkgdb we had an "owner" which got changed to "point of contact" > in pkgdb2 and "main admin" in pagure. Oh good point. That's actually one of the main reasons many teams create a '-maint' email alias, both in Fedora and RHEL world. It gets rid of the mis-leading impression for new bugs that a specific single person out of all the co-maintainers is responsible for that bug. A real human does not get assigned until it is genuinely something they're intending to work on, so other co-maintainers have a clear view of what's pending or not. I recall Fedora in the past had unique email address aliases per-package which would fan out to all maintainers, which could have been used in BZ, avoiding the need to limit Pagure due to BZ's design. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life I see lots of packages that are orphaned, but have one or more co-maintainer. Sometimes they may quickly take the package, sometimes they may be on holidays. Would you object if promote a co-maintainer to main maintainer for orphaned packages and make it a rule? ... Here is random example from today's announce of orphaned packages: Package (co)maintainers Status Change Singular orphan, rdieter 0 weeks ago cddlibjjames, orphan 0 weeks ago -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 02:21:19AM -0700, Neal Gompa wrote: > On Wed, Dec 18, 2024 at 2:04 AM Daniel P. Berrangé > wrote: > > > > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > > > The following packages are orphaned and will be retired when they > > > > are orphaned for six weeks, unless someone adopts them. If you know for > > > > sure > > > > that the package should be retired, please do so now with a proper > > > > reason: > > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > > > I see lots of packages that are orphaned, but have one or more > > > co-maintainer. Sometimes they may quickly take the package, sometimes they > > > may be on holidays. > > > > > > Would you object if promote a co-maintainer to main maintainer for > > > orphaned packages and make it a rule? > > > > Broadly it is a good idea, but with impl questions due to Pagure. > > > > IIUC Pagure only allows for 1 "main admin" (owner). What would you suggest > > if there are currently 2 (or more) "admin"s (co-maintainers). Arbitrarily > > pick 1 of the many to promote? Or do nothing and let them choose ? > > > > This is a problem I would hope our Pagure replacement will trivially fix > > for us, on the dist-git side at least. Other forges don't typically have > > a distinction between a single "main admin" and other "admins". Repos are > > "owned" by the collective of all admins who are equal peers. So there's > > no problem until the very last admin wants to leave. > > > > One thing I hope we never do is allow something to be principally > owned by groups as a rule. As a general practice, "groups" are bad at > being responsible for packages when the chips are down. It is > difficult to figure out if a package is being administered. Having a > singular point of contact in that scenario is beneficial, and I would > prefer we maintain that going forward in any new system. > > Will we? I don't know. People have been trying to make loopholes for > this for years anyway, and every loophole implementation sucks in > their own way. Just look at all the "foo-maint" accounts that > represent some team for a package. Ultimately those accounts are > useless for being responsible for the package and creates issues for > us over the long-term as we cannot figure out if there's anyone behind > a package in the first place. I can understand your complaint about non-responsive groups, but there are equally plenty of non-responsive individuals too. It all boils down to social expectations for maintainers. If either an individual, or a group, is not sufficiently responsive, technical solutions are not going to solve that for us. > Pagure had the distinction because our policy needed it, and I don't > particularly disagree with that need. Our policy here is ineffective & unenforced, given we have many packages with group ownership via the "foo-maint" alias workaround for Pagure's limitations. Trying to fix social problems with technical solutions often ends up this way, with people forced into sub-optimal workarounds. I don't like the "foo-maint" aliases, because we have no visibility into who is behind the alias, but this is problem of our own making. If Pagure had allowed all admins as peers it would have reduced the incentive to workaround it with "foo-maint" aliases. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 10:03 dop. Daniel P. Berrangé napsal(a): What would you suggest if there are currently 2 (or more) "admin"s (co-maintainers). No. I thinking about implementation in the script that generates "Orphaned packages looking for new maintainers" emails. And instead of putting the package on the list, it would the API call to pagure and assign the package to another co-maintainer. So there will be alway one main-maintainer. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 10:51 dop. Vít Ondruch napsal(a): Also making `ruby-packagers-sig` as a primary contact is problematic, because the group cannot e.g. retire such package without opening rel-eng ticket. Valid concern. Can be solved by skipping @ID. So only real people would be assigned. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 10:53 dop. Miro Hrončok napsal(a): When the package is orphaned (e.g. because the buzgilla that said it does not install was ignored by all 8 maintainers), it would be assigned to one of them, we are at 7 maintainers. It would take 8 another weeks to orphan it again, and again, and again. In such case the package should be retired, isn't it? -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Hi Neal, > On 18. Dec 2024, at 10:21, Neal Gompa wrote: > > One thing I hope we never do is allow something to be principally > owned by groups as a rule. See https://src.fedoraproject.org/rpms/stunnel, or https://src.fedoraproject.org/rpms/gnutls, owned by @crypto-team. > As a general practice, "groups" are bad at > being responsible for packages when the chips are down. It is > difficult to figure out if a package is being administered. Having a > singular point of contact in that scenario is beneficial, and I would > prefer we maintain that going forward in any new system. Do you have the impression that stunnel or gnutls are not well maintained in Fedora? While I sympathize with your concerns, this really comes down to the particular group that maintains these packages. The Fedora crypto team (which is equivalent to the RHEL crypto team, essentially) does take good and active care of its components, even though they are maintained by a group. In fact, those packages being maintained by a group is actually an advantage for Fedora, because we will collectively monitor and, if necessary, act on tickets even when the primary maintainer is currently out of office. As a consequence, I am very much opposed to a rule that would require packages to be maintained by single individuals. Are there such cases as you describe? Absolutely! Should they be a reason to completely ban groups? No. -- Clemens Lang RHEL Crypto Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
I would object! We've been there prior we arrived to the current workflow. And the typical situation was that such package was moved from one non-responsive maintainer to the other non-responsive maintainer. With my handle beginning with "v" I was always the last to become the maintainer and I can telly you, waiting or actively calling out other inactive maintainers is PITA. I don't think there is any big issue with the current situation. There is 7 weeks for folks to figure that somebody could pick up orphaned package. Vít Dne 18. 12. 24 v 9:53 Miroslav Suchý napsal(a): Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life I see lots of packages that are orphaned, but have one or more co-maintainer. Sometimes they may quickly take the package, sometimes they may be on holidays. Would you object if promote a co-maintainer to main maintainer for orphaned packages and make it a rule? ... Here is random example from today's announce of orphaned packages: Package (co)maintainers Status Change Singular orphan, rdieter 0 weeks ago cddlib jjames, orphan 0 weeks ago OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20241218.n.0 changes
OLD: Fedora-Rawhide-20241217.n.0 NEW: Fedora-Rawhide-20241218.n.0 = SUMMARY = Added images:3 Dropped images: 4 Added packages: 3 Dropped packages:1 Upgraded packages: 76 Downgraded packages: 0 Size of added packages: 953.22 KiB Size of dropped packages:12.34 MiB Size of upgraded packages: 2.83 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -2.94 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20241218.n.0.x86_64.vagrant-virtualbox.box Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20241218.n.0.x86_64.vagrant-libvirt.box Image: Kinoite ociarchive ppc64le Path: Kinoite/ppc64le/images/Fedora-Kinoite-ppc64le-Rawhide.20241218.n.0.ociarchive = DROPPED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20241217.n.0.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20241217.n.0.iso Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20241217.n.0.x86_64.vagrant-virtualbox.box Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20241217.n.0.x86_64.vagrant-libvirt.box = ADDED PACKAGES = Package: golang-github-gosimple-unidecode-1.0.1-1.fc42 Summary: Unicode transliterator in Golang RPMs:golang-github-gosimple-unidecode-devel Size:226.88 KiB Package: hash-o-matic-1.0.1-1.fc42 Summary: KDE file checksum utility RPMs:hash-o-matic Size:513.30 KiB Package: rust-auto_enums-0.8.6-1.fc42 Summary: Library for to allow multiple return types by automatically generated enum RPMs:rust-auto_enums+convert-devel rust-auto_enums+coroutine_trait-devel rust-auto_enums+default-devel rust-auto_enums+fmt-devel rust-auto_enums+fn_traits-devel rust-auto_enums+futures03-devel rust-auto_enums+generator_trait-devel rust-auto_enums+http_body1-devel rust-auto_enums+ops-devel rust-auto_enums+rayon-devel rust-auto_enums+serde-devel rust-auto_enums+std-devel rust-auto_enums+tokio1-devel rust-auto_enums+transpose_methods-devel rust-auto_enums+trusted_len-devel rust-auto_enums+type_analysis-devel rust-auto_enums+unstable-devel rust-auto_enums-devel Size:213.04 KiB = DROPPED PACKAGES = Package: libtimezonemap-0.4.5.3-2.fc41 Summary: Time zone map widget for Gtk+ RPMs:libtimezonemap libtimezonemap-devel Size:12.34 MiB = UPGRADED PACKAGES = Package: R-arules-1.7.9-1.fc42 Old package: R-arules-1.7.8-1.fc42 Summary: Mining Association Rules and Frequent Itemsets RPMs: R-arules Size: 10.60 MiB Size change: 17.79 KiB Changelog: * Tue Dec 17 2024 Iztok Fister Jr. - 1.7.9-1 - Update to 1.7.9 Package: aggregate6-1.0.14-1.fc42 Old package: aggregate6-1.0.13-1.fc42 Summary: Tool to compress an unsorted list of IPv4 and IPv6 prefixes RPMs: aggregate6 python3-aggregate6 Size: 29.76 KiB Size change: 211 B Changelog: * Tue Dec 17 2024 Robert Scheck 1.0.14-1 - Upgrade to 1.0.14 (#2332819) Package: ansible-collection-community-libvirt-1.3.1-1.fc42 Old package: ansible-collection-community-libvirt-1.3.0-5.fc41 Summary: Manages virtual machines supported by libvirt RPMs: ansible-collection-community-libvirt Size: 54.81 KiB Size change: 275 B Changelog: * Tue Dec 17 2024 Paul Howarth - 1.3.1-1 - Update to 1.3.1 (rhbz#2332772) - libvirt_lxc: add configuration for libvirt_lxc_noseclabel Package: bombardier-0.8.3-27.fc42 Old package: bombardier-0.8.3-26.fc41 Summary: The GNU Bombing utility RPMs: bombardier Size: 137.00 KiB Size change: -5.86 KiB Changelog: * Tue Dec 17 2024 Gwyn Ciesla - 0.8.3-27 - nmu4 Package: cairo-dock-3.5.99^20241216git4f36d13-1.beta6.fc42 Old package: cairo-dock-3.5.99^20241207gitea4bd97-1.beta5.fc42 Summary: Light eye-candy fully themable animated dock RPMs: cairo-dock cairo-dock-core cairo-dock-devel cairo-dock-libs Size: 7.85 MiB Size change: -267.42 KiB Changelog: * Mon Dec 16 2024 Mamoru TASAKA - 3.5.99^20241216git4f36d13-1.beta6 - Update to the latest git (20241216git4f36d13) Package: cairo-dock-plug-ins-3.5.99^20241217gitf8ad97e-1.beta6.fc42 Old package: cairo-dock-plug-ins-3.5.99^20241207gitce518e9-1.fc42 Summary: Plug-ins files for Cairo-Dock RPMs: cairo-dock-plug-ins cairo-dock-plug-ins-base cairo-dock-plug-ins-common cairo-dock-plug-ins-dbus cairo-dock-plug-ins-kde cairo-dock-plug-ins-unstable cairo-dock-plug-ins-webkit cairo-dock-plug-ins-xfce cairo-dock-python3 cairo-dock-ruby cairo-dock-vala cairo-dock-vala-devel Size: 17.18 MiB Size change: 9.44 KiB Changelog: * Mon Dec 16 2024 Mamoru TASAKA
Re: F42 Change Proposal: Switch to git-core (self-contained)
On čtvrtek 5. prosince 2024 10:21:28, středoevropský standardní čas Pavel Raiskup wrote: > Would you mind updating the change wiki page with the list of > features/commands that are provided by the `git` package on top of > `git-core`? Is it expected we do this only for Fedora Rawhide, or > shall we apply this pattern for all Fedora versions (or EPEL)? @Mikel ping, for most of the cases where git is involved, we just do `git ` (not Perl, but am I able to tell this easily?). Can we have a list of commands that are provided by `git` on top of `git-core`? Then I can easily grep the source code, and decide if the switch to `git-core` is what we really want. I'm still curious if we want to fix all Fedora/EPEL versions, or Rawhide only. Pavel > Pavel > > > > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Daniel P. Berrangé venit, vidit, dixit 2024-12-18 10:53:00:
> On Wed, Dec 18, 2024 at 10:43:33AM +0100, Vít Ondruch wrote:
> > I would object! We've been there prior we arrived to the current workflow.
> > And the typical situation was that such package was moved from one
> > non-responsive maintainer to the other non-responsive maintainer. With my
> > handle beginning with "v" I was always the last to become the maintainer and
> > I can telly you, waiting or actively calling out other inactive maintainers
> > is PITA. I don't think there is any big issue with the current situation.
> > There is 7 weeks for folks to figure that somebody could pick up orphaned
> > package.
>
> I don't accept that co-maintainers are (or should be assumed to be)
> "typically" non-responsive. That is a depressing denigration of
> many Fedora co-maintainer's work.
That is not said what Vit said, obviously.
People seem to forget that there's a simple solution:
- main admin steps back and asks admins to pick up, one does
There's even a second solution:
- main admin disappears/gets removed by process and one admin takes over
So, what we are talking about here is the case where the package got
orphaned for whatever reasons, and no admin has picked it up (again, for
whatever reason) nor advocated for substitutes. By definition of this
case ("such package"), we're dealing with non-responsive maintainers
here, where the 1st two solutions did not come to fruition.
I see too much reading into others' responses on this list lately, to
the point of skewing them completely. Now, I'm not reading bad
intentions into that either. Maybe it's the (pre-)season, the need for
holidays, or the topics themselves that came up. I just wish we'd all
tone down a bit and focus on understanding each others arguments (not
necessarily sharing them) rather than fueling the heat that is there
already. I wish us all warmth instead :)
Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. If you know for sure > > that the package should be retired, please do so now with a proper reason: > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > I see lots of packages that are orphaned, but have one or more > co-maintainer. Sometimes they may quickly take the package, sometimes they > may be on holidays. > > Would you object if promote a co-maintainer to main maintainer for orphaned > packages and make it a rule? Broadly it is a good idea, but with impl questions due to Pagure. IIUC Pagure only allows for 1 "main admin" (owner). What would you suggest if there are currently 2 (or more) "admin"s (co-maintainers). Arbitrarily pick 1 of the many to promote? Or do nothing and let them choose ? This is a problem I would hope our Pagure replacement will trivially fix for us, on the dist-git side at least. Other forges don't typically have a distinction between a single "main admin" and other "admins". Repos are "owned" by the collective of all admins who are equal peers. So there's no problem until the very last admin wants to leave. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On 18. 12. 24 9:53, Miroslav Suchý wrote: Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life I see lots of packages that are orphaned, but have one or more co-maintainer. Sometimes they may quickly take the package, sometimes they may be on holidays. Would you object if promote a co-maintainer to main maintainer for orphaned packages and make it a rule? I would, as repeatedly said in the past. Let's say we have a package that has 8 listed maintainers. When the package is orphaned (e.g. because the buzgilla that said it does not install was ignored by all 8 maintainers), it would be assigned to one of them, we are at 7 maintainers. It would take 8 another weeks to orphan it again, and again, and again. If a package is orphaned by administrative action (e.g. nonrepsonsive policy, inactive packager), the "operator" whould offer the package to comaintainers. If a package is orphaned for FTBFS/FTI reason, co-maiantainers clearly should not get it automatically. If the original main admin orphans it, they should communicate with their co-maintainers. In reallity, they don't always do that, but that is an exception. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 10:42 Clemens Lang napsal(a): Hi Neal, On 18. Dec 2024, at 10:21, Neal Gompa wrote: One thing I hope we never do is allow something to be principally owned by groups as a rule. See https://src.fedoraproject.org/rpms/stunnel, or https://src.fedoraproject.org/rpms/gnutls, owned by @crypto-team. As a general practice, "groups" are bad at being responsible for packages when the chips are down. It is difficult to figure out if a package is being administered. Having a singular point of contact in that scenario is beneficial, and I would prefer we maintain that going forward in any new system. Do you have the impression that stunnel or gnutls are not well maintained in Fedora? While I sympathize with your concerns, this really comes down to the particular group that maintains these packages. The Fedora crypto team (which is equivalent to the RHEL crypto team, essentially) does take good and active care of its components, even though they are maintained by a group. In fact, those packages being maintained by a group is actually an advantage for Fedora, because we will collectively monitor and, if necessary, act on tickets even when the primary maintainer is currently out of office. As a consequence, I am very much opposed to a rule that would require packages to be maintained by single individuals. Are there such cases as you describe? Absolutely! Should they be a reason to completely ban groups? No. There are different groups. Group such as `ruby-packagers-sig` is basically dumping ground. Everybody thinks that if they give permission of their package to `ruby-packagers-sig`, then it will be automagically maintained, which can't be further from truth. Also making `ruby-packagers-sig` as a primary contact is problematic, because the group cannot e.g. retire such package without opening rel-eng ticket. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
On Wed, Dec 18, 2024 at 10:43:33AM +0100, Vít Ondruch wrote: > I would object! We've been there prior we arrived to the current workflow. > And the typical situation was that such package was moved from one > non-responsive maintainer to the other non-responsive maintainer. With my > handle beginning with "v" I was always the last to become the maintainer and > I can telly you, waiting or actively calling out other inactive maintainers > is PITA. I don't think there is any big issue with the current situation. > There is 7 weeks for folks to figure that somebody could pick up orphaned > package. I don't accept that co-maintainers are (or should be assumed to be) "typically" non-responsive. That is a depressing denigration of many Fedora co-maintainer's work. Yes, there will be cases where a co-maintainer is not responsive, but we shouldn't design our policy to assume our maintainers are doing a bad job by default. The situation described where there are 2 (or more) co-maintainers and the tool re-assigned to a sub-optimal choice, is precisely why we should NOT designate a single person as the "main admin" (owner). If all maintainers are equal peers, we would not have got into a situation where the maintainer whose name is later in the alphabet gets overlooked as the "best" choice for re-assignment. We cna't solve this with Pagure without dev work, but hopefully our new forge will solve this problem. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Promoting co-maintainer to main maintainer for orphaned packages?
Dne 18. 12. 24 v 10:53 dop. Daniel P. Berrangé napsal(a): I don't accept that co-maintainers are (or should be assumed to be) "typically" non-responsive. That is a depressing denigration of many Fedora co-maintainer's work. During this year, as part of my work on SPDX, I opened several hundreds PR at src.fedoraproject.org. Only fraction of the maintainers reacted. I do not have hard data on my hand, It could be about 20-30% of maintainer that responded. Definitelly way bellow of 40%. That is the reality. I wish it would be different. But I cannot change it. And we should not deny it. Yes, there will be cases where a co-maintainer is not responsive, but we shouldn't design our policy to assume our maintainers are doing a bad job by default. Hold on. Non-responsive maintainer != bad job. Fedora is made of volunteers. They have they own work. They own priorities. Maybe they just become parent. Or they have hard times. And they do not want to be connected right now. And then we have a package that have release every few years. The spec changelog consists of "mass rebuild for FXX". And the package works without problem. And we have many of such packages. And suddenly main maintainer orphans the package. And we have 6 weeks window where we need to find a new maintainer. In situation where there is co-maintainer - likely willing to take over the package. But if he did not read emails in 6 weeks, does it make them doing a bad job? I do not think so. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora eln compose report: 20241219.n.0 changes
OLD: Fedora-eln-20241218.n.0 NEW: Fedora-eln-20241219.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:56 Upgraded packages: 19 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:227.48 MiB Size of upgraded packages: 280.94 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 155.29 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: caribou-0.4.21-41.eln144 Summary: A simplified in-place on-screen keyboard RPMs:caribou caribou-gtk3-module python3-caribou Size:847.05 KiB Package: cinnamon-6.4.2-2.eln144 Summary: Window management and application launching for GNOME RPMs:cinnamon Size:7.67 MiB Package: cinnamon-control-center-6.4.1-1.eln144 Summary: Utilities to configure the Cinnamon desktop RPMs:cinnamon-control-center cinnamon-control-center-filesystem Size:2.00 MiB Package: cinnamon-desktop-6.4.1-1.eln144 Summary: Shared code among cinnamon-session, nemo, etc RPMs:cinnamon-desktop Size:1.17 MiB Package: cinnamon-menus-6.4.0-1.eln144 Summary: A menu system for the Cinnamon project RPMs:cinnamon-menus Size:291.26 KiB Package: cinnamon-screensaver-6.4.0-1.eln144 Summary: Cinnamon Screensaver RPMs:cinnamon-screensaver Size:804.77 KiB Package: cinnamon-session-6.4.0-1.eln144 Summary: Cinnamon session manager RPMs:cinnamon-session Size:547.06 KiB Package: cinnamon-settings-daemon-6.4.1-2.eln144 Summary: The daemon sharing settings from CINNAMON to GTK+/KDE applications RPMs:cinnamon-settings-daemon Size:1.85 MiB Package: cinnamon-translations-6.4.1-1.eln144 Summary: Translations for Cinnamon and Nemo RPMs:cinnamon-translations Size:4.06 MiB Package: cjs-1:6.4.0-1.eln144 Summary: Javascript Bindings for Cinnamon RPMs:cjs Size:1.98 MiB Package: clutter-1.26.4-14.eln144 Summary: Open Source software library for creating rich graphical user interfaces RPMs:clutter Size:4.36 MiB Package: clutter-gst3-3.0.27-19.eln144 Summary: GStreamer integration library for Clutter RPMs:clutter-gst3 Size:330.95 KiB Package: clutter-gtk-1.8.4-19.eln144 Summary: A basic GTK clutter widget RPMs:clutter-gtk Size:185.00 KiB Package: cogl-1.22.8-11.eln144 Summary: A library for using 3D graphics hardware to draw pretty pictures RPMs:cogl Size:1.99 MiB Package: dbus-glib-0.112-9.eln144 Summary: GLib bindings for D-Bus RPMs:dbus-glib Size:524.60 KiB Package: djvulibre-3.5.28-10.eln144 Summary: DjVu viewers, encoders, and utilities RPMs:djvulibre-libs Size:2.62 MiB Package: exif-0.6.22-10.eln144 Summary: Utility to show EXIF information hidden in JPEG files RPMs:exif Size:394.25 KiB Package: file-roller-44.4-1.eln144 Summary: Tool for viewing and creating archives RPMs:file-roller Size:3.76 MiB Package: folder-color-switcher-1.6.6-1.eln144 Summary: Change a folder colour RPMs:folder-color-switcher Size:83.84 KiB Package: fpaste-0.5.0.0-1.eln144 Summary: A simple tool for pasting info onto the Fedora community paste server RPMs:fpaste Size:33.88 KiB Package: gnome-backgrounds-47.0-1.eln144 Summary: Desktop backgrounds packaged with the GNOME desktop RPMs:gnome-backgrounds Size:2.65 MiB Package: gnome-icon-theme-3.12.0-24.eln144 Summary: GNOME icon theme RPMs:gnome-icon-theme Size:9.93 MiB Package: gnome-online-accounts-gtk-3.50.3-2.eln144 Summary: GUI Utility for logging into online accounts RPMs:gnome-online-accounts-gtk Size:234.16 KiB Package: gnome-themes-extra-3.28-20.eln144 Summary: GNOME Extra Themes RPMs:gnome-themes-extra highcontrast-icon-theme Size:3.32 MiB Package: gtksourceview4-4.8.4-7.eln144 Summary: Source code editing widget RPMs:gtksourceview4 Size:3.48 MiB Package: gucharmap-16.0.2-1.eln144 Summary: Unicode character picker and font browser RPMs:gucharmap gucharmap-libs Size:8.04 MiB Package: keybinder3-0.3.2-19.eln144 Summary: A library for registering global keyboard shortcuts RPMs:keybinder3 Size:80.30 KiB Package: libcryptui-3.12.2-31.eln144 Summary: Interface components for OpenPGP RPMs:libcryptui Size:3.01 MiB Package: libgnomekbd-3.28.1-6.eln144 Summary: A keyboard configuration library RPMs:libgnomekbd Size:702.86 KiB Package: libsoup-2.74.3-7.eln144 Summary: Soup, an HTTP library implementation RPMs:libsoup Size:1.57 MiB Package: libxklavier-5.4-26.eln144 Summary: High-level API for X Keyboard Extension RPMs:libxklavier Size:255.73 KiB Package: mint-themes-1:2.2.1-1.eln144 Summary: Mint themes RPMs:cinnamon-themes mint-themes mint-themes-gtk3 mint-themes-gtk4 Size:2.60 MiB Package: mint-x-icons-1.7.2-1.eln144 Summary: Icon theme for Linux Mint RPMs:mint-x-icons Size:14.10 MiB Package
Re: libntlm soname bump
On Mon, Dec 09, 2024 at 10:09:44AM -0800, Kevin Fenzi wrote: > Hey folks. > > In 1 week, I'd like to bump libntlm from 1.6 to 1.8. > This involves a soname bump. > > Affected are I think (gkrellm and libgsasl). > Maintainers bcced here. > > I ran a mpb on the 1.8 version and both those packages built fine. > https://copr.fedorainfracloud.org/coprs/kevin/libntlm/packages/ > > I'm happy to bump and rebuild the 2 dependent packages, > or if maintainers want, point them to the sidetag when I create it. Sorry for the delay here. I have built the new libntlm and the 2 dependent packages and submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d3c7b90924 please let me know if you see any issues. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forming a lightweight SIG around MkDocs
On Wed, Dec 18, 2024 at 07:21:07PM +0100, Fabio Valentini wrote: > For the latter (i.e. also be able to add the group with commit access > to packages), you actually *MUST* create a mailing list, which needs > to be associated with the bugzilla account of the group, and where > bugzilla will send bugmail for packages associated with the group. That's fine -- I have no objection to lists used this way (and hopefully restricted to those bugzilla messages). I just want to avoid more which are mostly crickets punctuated by the occasional outbreak of spam. -- Matthew Miller Fedora Project Leader -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On Tue, Dec 17, 2024 at 02:28:09PM +0100, Vít Ondruch wrote: > This is not recent example, but really bad example of PP's work IMHO: > https://src.fedoraproject.org/rpms/ruby/c/c31c7edb6913eb7417ee68c59997548df2943dde I do not think nitpicking over _ten year old_ commits is helpful. -- Matthew Miller Fedora Project Leader -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On Wed, Dec 18, 2024 at 11:35 PM Kevin Fenzi wrote: > > Oh, one additional item I wanted to mention... > > I wonder if we could encourage maintainers/community members to do > something like this: > https://cassidoo.co/post/remote-intros/ > > TLDR: a small page listing your contact prefs, timezones, etc. That's a nice idea (with some horrible potential for identity theft), but we sort of have that already in the form of fas profiles. Unlike wiki pages, every contributor has one. A couple of fields will need to be added, e.g. contact preferences, but a lot of info is already there. Getting people to actually keep their profile up to date, is another story, I'm afraid. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forming a lightweight SIG around MkDocs
Excellent! Thanks for putting this together Davide. Count me in. --Neil On Wed, Dec 18, 2024 at 7:55 AM Davide Cavalca wrote: > > MkDocs (https://www.mkdocs.org/) is a Markdown-based website maker, > geared towards technical documentation. The CentOS Project has > historically used MkDocs for SIG documentation, and the CentOS Docs SIG > has recently standardized on MkDocs for the overall project, leading to > the creation of a collated documentation site at https://docs.centos.org > (sources: https://gitlab.com/CentOS/docs/docs.centos.org). > > To ease this work, I've been working on getting the MkDocs stack back in > shape in Fedora, with the goal of eventually branching it for EPEL 10. > Because MkDocs is quite sprawling, I'd like to setup a lightweight SIG > around it to ease package maintenance of the stack. By "lightweight" I > mean that I expect this will mostly be used for package ACLs and bug > triage. While I mostly expect folks from the CentOS Docs SIG to join in, > this is by all means open to anybody interested in collaborating. > > Cheers > Davide > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On Mon, Dec 16, 2024 at 7:22 PM Al Stone wrote: > > On 16 Dec 2024 08:08, Stephen Smoogen wrote: > > On Fri, 13 Dec 2024 at 20:33, Josh Stone wrote: > > > > > On Tuesday (2024-12-10), the Fedora Engineering Steering Committee > > > (FESCo) met in a private meeting to discuss whether Fedora contributor > > > Peter Robinson should retain his provenpackager privileges. Over the > > > last year, multiple private tickets have been opened with FESCo > > > regarding Peter’s packaging behavior. In particular, on numerous > > > occasions Peter has pushed uncommunicated updates to packages he has no > > > prior relationship with, interfering with those packages’ maintenance > > > efforts. On at least a few occasions, this has resulted in other > > > maintainers being forced to react to these changes with no coordination > > > or notice. > > > > > > > I know that these sorts of matters are hard to deal with, but this entire > > thing comes across more as something from the mythological Star Chamber > > than something I would expect from Fedora. > > Absolutely agreed. I find this sort of behavior by FESCo unacceptable. > Indeed. There are just so many things that are wrong on how this was conducted IMO: * A private trial but a very public sharing of the verdict. * Sharing the decision before having a public summary of the accuser's supposed wrongdoings as a PP and the arguments of the FESCo members / their vote. * The fact that one of the complainers is a FESCo member and was allowed to vote. * That Peter was not given the opportunity to defend himself. > > Yes, Peter is hard to get along with at times, and yes he can be brusque, > > pushy, and grumpier than any mule or cow I have had the 'pleasure' to work > > with, and I have been at the tail end of his tongue multiple times over the > > years in Fedora. Yet in all those years, I have also known that his work > > has been in service of the parts of the project he has been given charge > > of, be it architecture or package sets. Of the many people I have seen > > problems with 'proven packager' he has been the least likely I would > > consider 'dropped from Proven Packager'. > > I have worked with Peter for years; I consider him a friend, so my > opinion is biased. Having worked with software/hardware developers > for several decades, I find him no more rough around the edges than > most anyone in the industry :). Regardless, one does not become PP > without some demonstration of Doing The Right Thing for Fedora, and > that has always, always, always, been my experience in working with > Peter -- not only in Fedora, but at Linaro, and at Red Hat. > Al's comments almost exactly match my thoughts. I consider Peter my friend and I could have some bias too, but in the years that I worked with him I always had the impression that his actions were to improve Fedora. This decision greatly erodes my trust in FESCo and decreases my motivation to contribute to the project. I don't understand what was the goal exactly of making this a public announcement rather than just notifying the decision to the affected person. And I also don't understand what was the hurry to do it before having a public summary to share with the Fedora community. Given that this was the first time that PP rights would be revoked, wouldn't it be better to not act in a rush and try to make the process as transparent and fair as possible? Best regards, Javier -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On Wed, 18 Dec 2024 at 22:35, Kevin Fenzi wrote: > Oh, one additional item I wanted to mention... > > I wonder if we could encourage maintainers/community members to do > something like this: > https://cassidoo.co/post/remote-intros/ > > TLDR: a small page listing your contact prefs, timezones, etc. > Don't we already have this to some degree via the wiki, eg yous linked from the fesco team page: https://fedoraproject.org/wiki/User:Kevin Most git forges have a profile page these days so I'm sure that could also suffice. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Revocation of provenpackager access from pbrobinson
On Thu, 2024-12-19 at 00:31 +0100, Javier Martinez Canillas wrote: > I don't understand what was the goal exactly of making this a public > announcement rather than just notifying the decision to the affected > person. And I also don't understand what was the hurry to do it > before > having a public summary to share with the Fedora community. Given > that > this was the first time that PP rights would be revoked, wouldn't it > be better to not act in a rush and try to make the process as > transparent and fair as possible? Agreed with all of this, and I further don't understand how it's even possible to be in violation of the policy as cited in the OP, given that the language uses "should" and not "must", is unclear about what the rules are, and in no way indicates that violating the unclear rules could result in public shaming and privilege revocation. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forming a lightweight SIG around MkDocs
On Wed, Dec 18, 2024 at 07:21:07PM +0100, Fabio Valentini wrote: > On Wed, Dec 18, 2024 at 6:31 PM Matthew Miller > wrote: > > > > On Wed, Dec 18, 2024 at 11:17:12AM -0600, Michel Lind wrote: > > > but the only document I see for creating a SIG is still only a wiki page > > > https://fedoraproject.org/wiki/Creating_a_Fedora_SIG > > > > This all desperately needs a refresh. All I ask is: please, please don't > > create a new mailing list. :) > > Well ... > > Just making a SIG is the easy part. But where more bureaucracy comes > into play is when you want to have the SIG also be a group in FAS, and > in dist-git. > > For the latter (i.e. also be able to add the group with commit access > to packages), you actually *MUST* create a mailing list, which needs > to be associated with the bugzilla account of the group, and where > bugzilla will send bugmail for packages associated with the group. > Yeah... and this is the part that I think we should document. Best, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
