Re: Role of Release Goals
>> - 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.
They are.
They aren't.
Both can be true. We can have project wide changes that don't need to be
bound to a specific release and we can have things that are for just
that next one and can't wait longer. We could also have release goals
which aren't first declared as a technical project goal.
> Which rules could need adjustment?
> - NMU rules? (I already argued against it, but feel free to disagree)
> - freeze exemption rules?
Formally lowering NMU rules does make a lot of sense. If not technically
(if one argues its easy enough already) then at least socially - make it
easier for people not so deep inside Debian to see "oh sure, its for
this $goal, NMU rules as simple as $whatever apply".
Freeze exemption or not - whatever, that is imo clean in the power of
the release team, and they can use that in whatever way they deem
appropriate.
> 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.
Which is a valid decision they can take, yes.
>> 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.
Right. And yes, that does touch a bit more than "just a release". But we
are missing a better place currently. So yes, creating one seems to be a
good step, though *IMO* release goals in itself should be kept too. To
ensure things get done in time for a release.
> 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 fully understand them not wanting to take that decision.
I don't think we currently have a body in Debian that is the best place
to go for this. None of the current delegations fit, not even the Tech
CTTE, even if its name fits. (And our lists definitely do not work for
such things either).
> 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.
Discussion and decision about it should be on a public list, yes.
Decision shouldn't be taken by "consensus" or anything like it trying to
have that from such a list. We have proven trillions of times that this
does not work out.
So that means there needs to be a set of appointed people for this.
Which shouldn't be a (too) static list. Take some out of every
(technical) delegation? Take nominations by others? Vote on it and have
a second vote each year for s subset of those people? I dont know, but
luckily I don't need to find the best answer. Have fun, Mr. DPL. :)
--
bye, Joerg
<Fubak> /msg NickServ IDENTIFY arschloch
<codebreaker> /msg nickserv ghost Fubak arschloch
-!- Fubak has quit [Nick collision from services.]
Reply to: