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

Bug#932795: How to handle FTBFS bugs in release architectures



On 29/07/19 at 17:23 -0500, Gunnar Wolf wrote:
> My opinion, based on what we talked about this bug during DebConf and
> the people I talked with, is that we should provide an advice
> following roughly:
> 
> - The Release Team are empowered to set the base requirements to build
>   packages for a given release (starting with Bullseye, I don't think
>   there's any reason to change qualifications for Buster)
> 
> - Get this documented, quite probably in the RT delegation.
> 
> Of course, we have to get this moving within the TC, but I hope we can
> do this before our next meeting (August 21).

Hi,

The release team delegation already states:
>  * Release Team members define the content of the suites listed above,
>    that is:
> 
>    - They define the packages that are part of those suites. Generally,
>      that is achieved by deciding:
> 
>      - Which issues are release-critical (RC) (ie. making the affected
>        packages not suitable for stable releases) usually by setting
>        the corresponding bug's severity to serious, grave or critical.
> [...]

I think that this already encompasses deciding on the supported build
environments (if not building in a supported env is an RC bug), so I'm
not sure if this should be set in stone in the delegation.

However, it might indeed be useful for the release team to clarify the
status of various cases, such as:
- package that fails to build 10%, 50%, 90% of the time (that is, the
  build will eventually succeed)
- package that fails to build when built in a non-clean env (additional
  packages installed)
- package that builds different binaries when built in a non-clean env
- package that requires several cores
- ...

It is my understanding that none of the above issues are considered RC
at the moment.

Lucas


Reply to: