On 14. 08. 19 19:22, Ben Cotton wrote:
I want to publicly express my appreciation for Miro's efforts to
enforce our policy and his willingness to take the hits from people
being rightly upset at its flaws. I also appreciate that the community
has done a good job of understanding that the policy is the problem
and not making it a personal attack on Miro.
Thanks. Support like this is greatly appreciated.
On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote:
"MH" == Miro Hrončok <mhroncok@xxxxxxxxxx> writes:
MH> If we stop here, the current "setting to ASSIGNED to stop this"
MH> remains a problem.
Let's think about why this is perceived as a problem. The maintainer
has performed an affirmative act that shows they noticed. Can't we just
accept that as some statement of intent and stop bugging them at that
point?
This is a reasonable compromise to make, IMO. In a perfect world, we'd
have enough active packagers to handle things in a timely manner. But
in this world, people have a lot going on and there's only so much we
can do. People setting a bug to ASSIGNED is a problem I'm willing to
accept. If there's an exceptional case, we can say FESCo has the
ability to step in and remove it. We should assume positive intent
with maintainers and trust that they're doing the right thing.
What if... we only allow swaying FTBFS bugs under the carpet for a certain
period of time?
E.g.
1. Mass rebuild for Fedora N happens
2. Packages that fail to build get open bugzillas
3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly reminders
4. If the package hasn't rebuilt for a certain number of releases, it is
flagged for removal despite the bug status.
Of course the removal would still need to be communicated properly, but I
suspect only a couple of packages would fall into that category.
I suppose that at a time of a release of Fedora version, all shipped packages
should have been rebuilt on a platform that was supported on the time of the
release.
E.g. when we release Fedora 32, Fedora 28 is already EOL for 5 months. It is
IMHO reasonable to expect the packages were rebuilt at least on Fedora 29.
That would effectively mean:
0. package built with .fc29 release tag before the mass rebuild
1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, kind warning
4. Fedora 32 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
5. Fedora 32 branches, package still fails to build, we retire it
Or:
0. package built with .fc28 release tag before F28 branching
1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, kind warning
3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
4. Fedora 31 branches, package still fails to build, we retire it
That gives 1.5 years minimum (F28 branching to F31 branching) to fix a FTBFS. Is
that reasonable?
(With a possibility to request an exception in exceptional cases.)
The policy is also easy enough to define:
"Rawhide packages with latest successful build made in Fedora N are retired from
master after Fedora N+3 branches."
--
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
