Re: Delegation for the Release Team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/26/2013 07:23 AM, Lucas Nussbaum wrote:
> On 26/12/13 at 13:20 +0100, Lucas Nussbaum wrote:
>
>> Dear Developers,
>>
>> It is my great pleasure and honor to officialize the existence and
>> the powers of one of Debian's most important teams: the Release
>> Team.
>
> Hi,
>
> I'd like to note that the discussion on this delegation was
> inconclusive on a couple of points:
> 2) it does not include anything about Release Goals.
>
> There's currently a thread on -devel@ about Release Goals, where the
> rough consensus seems to be that we need a way to define "technical
> project-wide goals", but that the release team is not necessarily the
> most suitable team to oversee this (due to the additional workload,
> and to the fact that most of such goals are not specific to a
> *release*).
Just as a note, since I don't recall having seen it mentioned in the
referenced thread:
It's seemed intuitively obvious to me that a "release goal" could
equally be defined as "a new criterion by which a package can be judged
to be RC-buggy". Since "deciding what issues are release-critical" is,
per the delegation announcement, part of the job of the Release Team,
that would naturally seem to fall under their purview. (Conflicting with
this is the fact that, IIRC, the criteria for "release-critical" status
are defined in policy.)
The advantage of classifying a "technical project-wide goal" as a
criterion for RC bugs - and, thus, for exclusion from a release - is
that it provides an impetus for package maintainers to implement the
changes necessary to meet that goal, by providing an enforcement
mechanism.
The major disadvantage, that I see, is that in practice it seems to
leave us with a choice between undesirable alternatives: making
exceptions to that criterion (and thus not progressing towards the
goal), omitting valuable packages from a release, or having an extended
freeze.
I'm not sure, however, that having a "technical project-wide goal"
*without* an enforcement mechanism would even work. While many people -
especially those who have proven themselves far enough to become DDs -
might well work to implement such a goal anyway, whether because they
like and agree with it or just out of a sense of responsibility and good
citizenship, not everyone is that responsible, that involved, or that
committed. Without an enforcement mechanism, I could easily see it
happening that many maintainers would simply let the goal slide, or
otherwise ignore it - and it might never get implemented for their packages.
It isn't certain that that would happen, of course, and even if it were
the threat of release exclusion may not be the only possible enforcement
mechanism. However, I don't think it's unlikely enough to be completely
ignored (except possibly for a "let's try it out and see what happens"
scenario), and I don't think I've seen any other possible mechanisms
proposed - nor have I been able to think of any plausible ones myself.
If an enforcement mechanism for project-wide goals is needed, and if the
only available one is tied to a release, then it seems natural and
appropriate for the release team to be the ones to oversee those goals.
If we don't want them doing that (for whatever reason), then we need to
either decide that no enforcement mechanism is needed, or come up with
one that is not tied to a release - or at least not to the authority of
the release team.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJSvDcLAAoJEASpNY00KDJrkmAP/1B7dBi02gDFQVYtgxo73QHk
dW6Z3hmfV3nFBBL154Mo3jeOQ0fyPTGJpzjAtRrHEt9caW2RPX2dY7C48NbkAAl2
va/SUJ2SL8l0+MpWtQ6BR8h5YXPEQzdfjKsOfkGHddg0YobTmi+j9NaT2G/+Q4Lw
cOLJDhyedopJW4VepH1XbYbhBdIV/LqkP9otvtU+aNbt1aonQM0ZC21kW+uaOoQt
y1NrDqlajaOZIHkAZysayDislYZNlCl47oPUJzwCbKkuSLWl5hPwrpWPbV2jWBGv
+NsE1zYJ0QXpj1U7k/NKuMss6wPRC77SHc3t9KMWJqGdALqgmB8ivO/Fbpp5bDaa
1ACmioZy2TMEuHgpqCn9IG4x1OXBDc3HI/+jmDalvQnKJAomcqP3DdZ32i8q2+LN
c6fkxMy7WXewHCR6uwhnjE483Lg7Mpeyc2xYgOUisaTzunIthTzYvbNtFm2ylxSe
6IRVRw/pvI407gyfU9q3u+pRyRqRMOby4NHMHm8OCm2HU+AU1WN7GH2SqGl4T11+
28q2Z13CqXYlLvDCq0dOxMzKvHk+gwac75AkG91kEv8X4w5Q4Xwvlb4nXXY60uKB
hhnf7Cohsk7pNBlFaf5oz95KiuRIp4E3N8+Z9QthVe5VL7SD+17N+iN+xkGZ0F7y
PEs+bAPZ4YOMewqoFv3C
=+YcY
-----END PGP SIGNATURE-----
Reply to: