Re: Role of Release Goals
On 01/12/13 at 23:32 +0100, Joerg Jaspert wrote:
>
> >> I would presumably put something like:
> >> * Release Team members decide on the release goals for stable releases
> > I think that a delegation would need to be a bit more specific in
> > defining what "release goals" are, and what it means to have a goal
> > labelled as "release goal". At least for me, the current definition of
> > "release goal" is rather unclear.
>
> It does sound to me like you two are discussing two things:
>
> - There are project-wide changes to be done and someone needs to take a
> decision to do them to adjust some of our common rules to make them
> easier to do. Lets name them "technical project goals"
>
> - There are project-wide changes to be done that should be done in time
> for a certain release and someone needs to decide which of those
> are for which release, and to probably adjust some of our common
> rules even more. Ie. release-goals.
If release goals are a subset of technical project goals, then I agree
with your definition, yes.
Which rules could need adjustment?
- NMU rules? (I already argued against it, but feel free to disagree)
- freeze exemption rules?
In the draft delegation I pointed to, the release team can already
decide which bugfixes are suitable for inclusion in the various suites,
so freeze exemptions are already covered, though the release team
expressed during the meeting that, to favor a shorter freeze, they
might not allow freeze exemption for release goal bugfixes.
> I think the second one is more than sure a part of the release teams
> call. The first was with RT in the past, and it seems Lucas wants to
> move that elsewhere.
>
> I don't really see a problem in that - $someone decides on "technical
> project goals", whatever they are. And RT can decide that they should be
> for the next release. Or the one after. Setting a timeline until when
> its done. Additionally, the RT can (in whatever ways) come up with more
> release-goals, say "gcc must be version 42.0815 for jessie".
>
> Though I don't see why it needs a split now - has the RT done such a bad
> job with the goals?
Heh :) no.
See [1]. During the release team meeting, the release team was not
super at ease with deciding whether specific technical goals were
worthwhile for Debian.
I fully understand that. Some technical goals have a very high impact on
Debian. Let's take the "clang as secondary compiler"[2] one, for
example:
- there are very good reasons to do that: being able to rebuild Debian
with Debian makes Debian the distribution of choice to work on static
analysis, and general compiler testing. So this will result in
many indirect improvements to Debian and Free Software in general.
- but that goal has a high impact for Debian. There's a dependency
on the "honor CC and CXX"[3] release goal proposal, that will
require changes in many packages. For clang support itself, 11% of the
packages are currently failing to build, and will require changes.
Does Debian should invest time to fix all those issues, and then
maintain the patches that will not be accepted by upstreams?
And how should we decide that? Ask the release team to take the
decision, even if it's quite unrelated to releases?
I think that there are really two problems:
1) Have a recommended process to discuss project-wide technical goals,
gather feedback, and reach consensus.
As I wrote in https://lists.debian.org/debian-devel/2013/11/msg00455.html,
I think that the discussion about them should happen on public lists.
2) If the release team wants it, have a process for carte blanche
freeze exemptions for specific classes of bugfixes (typically, for
large-scale changes that are close to completion at the beginning of
the freeze). It's the release team decision to decide which classes of
bugfixes are sufficiently low impact that they want to risk introducing
regression that could lengthen the freeze. (And it's also up to the
release team to decide whether they want to have such carte blanche
freeze exemptions at all).
[1] https://lists.debian.org/debian-devel-announce/2013/11/msg00007.html
[2] https://wiki.debian.org/ReleaseGoals/clang-secondary-compiler
[3] https://wiki.debian.org/ReleaseGoals/honorCCandCXX
Lucas
Reply to: