Re: Role of Release Goals
Am 02.12.2013 08:03, schrieb Lucas Nussbaum:
> 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.
a technical project goal applied to a subset of packages could become a
release-goal too, e.g. to all packages in the minimal chroots, or to all
packages needed to build the minimal chroots.
> Which rules could need adjustment?
> - NMU rules? (I already argued against it, but feel free to disagree)
It would be nice to have some way to do one NMU for severeal release/technical
goals. Maybe nicer for the package maintainer too to only handle one NMU.
> - 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.
It's more like some decisions are not made, or made late, e.g. architecture
(re-)qualifications.
> 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?
how is "honor CC and CXX" different to existing release goals like hardening
(and honoring the various FLAGS)? There are a lot of these goals which could be
described as "sane packaging" (honor cross builds, honor, no-test builds, honor
verbose builds, honor hardening, honor parallel builds, honor outdated config.
files, ...). In most cases these don't touch upstream at all, "just" the packaging.
Not fixing these will cost Debian time and quality too, e.g. longer build times,
more ugly bootstraps, unmet or not verifiable release or technical goals, ...
> 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.
How would these project-wide goals decided on? There's usually a minority which
objects, or the discussion dies away. At least with a release goal, there was a
decision made, whether you liked it or not.
Matthias
Reply to: