-----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----- -- 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/52bc370c.1090...@fastmail.fm
