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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131202070332.ga11...@xanadu.blop.info
