Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
Am 01.12.2013 21:03, schrieb Lucas Nussbaum: that fictious goals such as gcc 4.9 by default in jessie or GNOME 3.14 in jessie would totally be in the realm of the release team, but are already covered in the delegation. a) please use real fictious goals. b) the choice of compiler version wasn't yet in the realm of the release team, and I think it didn't change. Matthias -- 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/529c951f.5030...@debian.org
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 30/11/13 at 22:07 -0600, Steve Langasek wrote: On Sat, Nov 30, 2013 at 05:40:35PM +0100, Jakub Wilk wrote: * Steve Langasek vor...@debian.org, 2013-11-29, 12:01: What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? My proposal is to realize that reduced delay for archive-wide changes is not needed. Seriously, such changes will take months or years anyway, so what does reducing a 10-day delay buy you? It buys you being able to finish in months, instead of in years. It buys you not having to track dozens of in-flight NMUs in parallel, letting you spend more of your time working on improving Debian instead of doing paperwork. I fully agree that project-wide improvements should be encouraged, and that we should try to reduce the burden for people working on such tasks. So we need a efficient mechanism to protect such project-wide improvements to be blocked by a maintainer's unresponsiveness/inactivity blocks. However, on the other hand, the NMU process is disruptive for active maintainers, as the NMUer usually doesn't have insider knowledge of the package and its life cycle. So, it's really a question of how efficient we want the process to be, and how much we are willing to pay for that (in terms of disruptiveness). The current NMU rules allow someone to prepare a patch, file a bug with it, and upload to DELAYED/10, all in one go. The tracking needed for such a process is minimal, and the BTS, or BTS+UDD, likely can make it even easier. I agree that the 10-day delay might not be sufficient for transitions that require numerous stages, but in that case, I would totally understand if someone argued for DELAYED/5, especially if advanced notice is given (by listing all packages affected by a large-scale change). It sets an appropriate project-wide expectation that certain NMUs are sanctioned, so people (including new developers, NMs, or new contributors) will feel supported in working on such tasks instead of being afraid to stick their necks out. The need for review and feedback is another problem. It's often difficult to get feedback on a proposed change inside Debian. But I really don't think that it should be the release team's job alone to decide which project-wide improvements are good or bad. If it's too hard to reach consensus on -devel@ on a proposed improvement, I would rather prefer if we used the TC's ability to offer advice. 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/20131201161735.gc28...@xanadu.blop.info
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
This one time, at band camp, Lucas Nussbaum said: The need for review and feedback is another problem. It's often difficult to get feedback on a proposed change inside Debian. But I really don't think that it should be the release team's job alone to decide which project-wide improvements are good or bad. If it's too hard to reach consensus on -devel@ on a proposed improvement, I would rather prefer if we used the TC's ability to offer advice. Releases have, up to now, been the domain of the release team, since that's sort of what they do. What goals are set for a given release seem to me to be something squarely in that realm, especially given that there is no 'stick' - there's not really anything to compel others to play along. Can you explain why you think it would be a good idea to remove the power to decide their own goals from a team, and why you think it would be good for Debian to have one team drive another team's goals? This is so different to how we usually work that it seems jarring. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Sun, Dec 1, 2013 at 12:53 PM, Stephen Gran wrote: Can you explain why you think it would be a good idea to remove the power to decide their own goals from a team, and why you think it would be good for Debian to have one team drive another team's goals? This is so different to how we usually work that it seems jarring. I believe the underlying friction is that the release team rejects a lot of goals as not affecting a sufficiently broad set of packages, which leaves no venue for organizing less broad but still useful and possibly disruptive (in a smaller way) changes. Best wishes, Mike -- 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/CANTw=mmt_mgo5uky3hh3oz2wvkeuxjlyqybhsnazjzitsqv...@mail.gmail.com
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 01/12/13 at 17:53 +, Stephen Gran wrote: This one time, at band camp, Lucas Nussbaum said: The need for review and feedback is another problem. It's often difficult to get feedback on a proposed change inside Debian. But I really don't think that it should be the release team's job alone to decide which project-wide improvements are good or bad. If it's too hard to reach consensus on -devel@ on a proposed improvement, I would rather prefer if we used the TC's ability to offer advice. Releases have, up to now, been the domain of the release team, since that's sort of what they do. Sure. What goals are set for a given release seem to me to be something squarely in that realm, especially given that there is no 'stick' - there's not really anything to compel others to play along. Ah, interesting. My POV is that release goals are kind-of misnamed, because most of them are not specific to releases, but are instead general technical changes. Most of the goals proposed on https://wiki.debian.org/ReleaseGoals are very valid and interesting technical changes, but I really fail to see how they are specific to a given release. Maybe you could explain why you think that it's the case? Can you explain why you think it would be a good idea to remove the power to decide their own goals from a team, and why you think it would be good for Debian to have one team drive another team's goals? This is so different to how we usually work that it seems jarring. Release goals are usually achieved by contributors working on one specific goal, not by the release team (= the release team doesn't actively fix packages for release goals). The role of the release team regarding release goals is to: 1) evaluate/approve goals 2) follow progress (using BTS usertags, usually) and re-evaluate during the release cycle. So, I don't think that it's correct to describe release goals as the release team's own goals. Then, yes, I question whether it should really be the release team's role to evaluate and approve such goals. I'm currently working on a delegation for the release team (non-final draft at [1]), and I agree that fictious goals such as gcc 4.9 by default in jessie or GNOME 3.14 in jessie would totally be in the realm of the release team, but are already covered in the delegation. If you think that the release team should have the power to decide on release goals, how should this draft delegation be changed to include that? [1] http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=blob;f=release-delegation.txt - 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/20131201200300.ga5...@xanadu.blop.info
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
This one time, at band camp, Lucas Nussbaum said: On 01/12/13 at 17:53 +, Stephen Gran wrote: This one time, at band camp, Lucas Nussbaum said: What goals are set for a given release seem to me to be something squarely in that realm, especially given that there is no 'stick' - there's not really anything to compel others to play along. Ah, interesting. My POV is that release goals are kind-of misnamed, because most of them are not specific to releases, but are instead general technical changes. Most of the goals proposed on https://wiki.debian.org/ReleaseGoals are very valid and interesting technical changes, but I really fail to see how they are specific to a given release. Maybe you could explain why you think that it's the case? The bullet-point new feature list for a given release is generally speaking, a combination of 'gnome x.x, kde x.x' style version enumeration and the result of release goals. See the bit about multiarch on http://www.debian.org/News/2013/20130504.en.html, for instance. I can't see how a set of new features targeted at the next release can't help but be related to the next release. Can you explain why you think it would be a good idea to remove the power to decide their own goals from a team, and why you think it would be good for Debian to have one team drive another team's goals? This is so different to how we usually work that it seems jarring. Release goals are usually achieved by contributors working on one specific goal, not by the release team (= the release team doesn't actively fix packages for release goals). Huh. My impression from watching the last several releases was that the release team was a lot more involved than that in actually doing the work of meeting release goals, and not just a note keeper for someone else's pet project. The role of the release team regarding release goals is to: 1) evaluate/approve goals 2) follow progress (using BTS usertags, usually) and re-evaluate during the release cycle. So, I don't think that it's correct to describe release goals as the release team's own goals. OK, so you really do think the release team just does paper work for someone else's goals. I can understand why you don't have a problem changing who makes the decisions, then. I don't share your point of view about the amount of work the release team has historically put into this sort of thing. Then, yes, I question whether it should really be the release team's role to evaluate and approve such goals. I'm currently working on a delegation for the release team (non-final draft at [1]), and I agree that fictious goals such as gcc 4.9 by default in jessie or GNOME 3.14 in jessie would totally be in the realm of the release team, but are already covered in the delegation. It's good of you to allow them the freedom to be able to choose the compiler version in the next release. You should be careful about allowing them that much power, it might go to their heads. If you think that the release team should have the power to decide on release goals, how should this draft delegation be changed to include that? I would presumably put something like: * Release Team members decide on the release goals for stable releases But I am a simple man. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 01/12/13 at 20:38 +, Stephen Gran wrote: This one time, at band camp, Lucas Nussbaum said: On 01/12/13 at 17:53 +, Stephen Gran wrote: Can you explain why you think it would be a good idea to remove the power to decide their own goals from a team, and why you think it would be good for Debian to have one team drive another team's goals? This is so different to how we usually work that it seems jarring. Release goals are usually achieved by contributors working on one specific goal, not by the release team (= the release team doesn't actively fix packages for release goals). Huh. My impression from watching the last several releases was that the release team was a lot more involved than that in actually doing the work of meeting release goals, and not just a note keeper for someone else's pet project. My memory might fail me. Could you provide an/some examples? Also, even if some release team members contributed to achieving release goals, are you sure that this was really done with the release team hat? As a counter-example, half of the Lintian maintainers are or were members of the release team at some point, but I don't think that the release team ever claimed that maintaining Lintian was part of their normal duties. If you think that the release team should have the power to decide on release goals, how should this draft delegation be changed to include that? 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. 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/20131201213328.ga8...@xanadu.blop.info
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
* Steve Langasek vor...@debian.org, 2013-11-29, 12:01: What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? My proposal is to realize that reduced delay for archive-wide changes is not needed. Seriously, such changes will take months or years anyway, so what does reducing a 10-day delay buy you? -- Jakub Wilk -- 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/20131130164034.gb2...@jwilk.net
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Sat, Nov 30, 2013 at 05:40:35PM +0100, Jakub Wilk wrote: * Steve Langasek vor...@debian.org, 2013-11-29, 12:01: What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? My proposal is to realize that reduced delay for archive-wide changes is not needed. Seriously, such changes will take months or years anyway, so what does reducing a 10-day delay buy you? It buys you being able to finish in months, instead of in years. It buys you not having to track dozens of in-flight NMUs in parallel, letting you spend more of your time working on improving Debian instead of doing paperwork. It sets an appropriate project-wide expectation that certain NMUs are sanctioned, so people (including new developers, NMs, or new contributors) will feel supported in working on such tasks instead of being afraid to stick their necks out. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote: On 28/11/13 at 21:04 +0100, Niels Thykier wrote: Release Goals = We discussed release goals in some depth at the recent sprint. The general consensus was that, whilst release goals have been useful in the past to introduce archive-wide changes, we should review whether this remains the case and whether the release team is really the right place to determine them. We intend to consult with the project on this point in due course. Indeed. To elaborate a bit more: Release Goals are usually distribution-wide changes to Debian. We have had release goals for a long time (see e.g. [1] about etch release goals, in 2006). Release Goals seem to have several purposes: - in the past, specific NMU rules applied to release goals. However, that is no longer the case. It is already possible to NMU for any bug (including wishlist ones) provided that reasonable advance notice and effort to consult the maintainer is applied. I think that misstates the rationale for release goals. It was *always* possible to NMU for any bug provided reasonable advanced notice and consultation. The point of declaring a release goal is that, for a distribution-wide change that touches many packages, following the standard SRU process where each upload requires a built-in waiting period significantly slows down progress. So having a relaxed NMU policy for recognized project-wide goals, allowing release goal NMUs to be done quickly as part of bug squashing parties, benefits the project by letting us reach these goals much more effectively. - Release Goals kind-of define Debian's technical agenda. However, one could question whether it's really the role of the release team to decide on this, rather than the one of the project at large. Shouldn't this be discussed the usual Debian way (= discussion on mailing list to gather feedback and reach consensus on the global picture; then do-ocracy for the smaller implementation details)? We're not talking about small implementation details. What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? The release team may not be the right way to get this done organizationally, but a strict consensus-driven process on debian-devel is also not realistic as we will never converge on a decision in a reasonable amount of time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Fri, 29 Nov 2013 12:01:31 -0600, Steve Langasek wrote: On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote: - Release Goals kind-of define Debian's technical agenda. However, one could question whether it's really the role of the release team to decide on this, rather than the one of the project at large. Shouldn't this be discussed the usual Debian way (= discussion on mailing list to gather feedback and reach consensus on the global picture; then do-ocracy for the smaller implementation details)? We're not talking about small implementation details. What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? The release team may not be the right way to get this done organizationally, but a strict consensus-driven process on debian-devel is also not realistic as we will never converge on a decision in a reasonable amount of time. Something similar to DEPs could be useful in this regard. For the purposes of release goals, though, the requirements for passing from DRAFT to CANDIDATE should be defined, to avoid endless discussions (say, a number N of seconds). -- Saludos, Felipe Sateler -- 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/l7ao87$qot$1...@ger.gmane.org
