Re: List of long term FTBFS packages to be retired in February​

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26. 01. 23 20:29, Kevin Fenzi wrote:
On Thu, Jan 26, 2023 at 10:21:27AM +0100, Miro Hrončok wrote:
On 26. 01. 23 4:51, Yaakov Selkowitz wrote:
On Tue, 2023-01-24 at 15:55 +0100, Miro Hrončok wrote:
Based on the current fail to build from source policy, the following
packages
should be retired from Fedora 38 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 2 weeks, i.e. around 2023-02-08.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f38.

Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Why isn't automatic orphaning at the beginning of this countdown part of this
policy, so that others have the chance to take and fix the package?  If
someone (other than the maintainer, who should already be well aware) were to
just now notice that one of these packages were about to be retired, there
isn't really enough time to go through the BZ route to get it orphaned first.

That is a good question.

The original idea is that FTBFS packages are orphaned when the maintainers
don't respond to the FTBFS bugzillas. But many do set the bugzillas to
ASSIGNED to avoid the orphaning or sometimes the FTBFS bugzillas are closed
in mistake or not opened at all.

Well, if it's ASSIGNED, you don't want to orphan it, the maintainer is
working on it right?

Unfortunately, as seen by the lenght of the packages listed in my emails, thsi is not always the case.

Some packagers do set the bugzillas to ASSIGNED to get rid of the reminders and then they forget to actually fix the FTBFS, cannot figure out how to fix it, are blocked on externalities that never happen, etc.

I suppose orphaning the packages first would make perfect sense, but the
devil is in the details. I suppose packagers might feel bad if suddenly
"their" packages are orphaned without any reminder or warning of some sort.

Yeah, I think that would be quite bad.

So we would need to modify the policy from:

1. warn
2. warn
3. warn
4. warn
5. warn
6. retire

To something like:

1. warn
2. warn
3. warn
4. orphan
5. warn
6. warn
7. warn
8. retire

And make the process much longer. And we would need to figure out what to do
if the package is taken (unorphaned) in between 4. and 8. without being
fixed.

I suppose FTBFS is less urgent and FTI bugs... perhaps they should be
different in this process?

Oh but they are different. FTBFS are not urgent and the policy is only set to retire packages that FTBFS for more than 2 release cycles.

For a package to be considered for retirement in February 23, it would have to fail to build:

 - During the Fedora 36 mass rebuild in January 22.
 - During the Fedora 37 mass rebuild in July 22.
 - During the Fedora 38 mass rebuild in January 23.

That is not urgent, that is "not being fixed".

We can make this even longer, but I don't think it'll make a difference -- eventually we will just get a list of packages that aren't beign fixed, but for a longer time.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux