Re: Role of Release Goals
On 2013-12-02 23:59, Charles Plessy wrote: Hi all, Hi, am I wrong or among the supporters of the concept of release goals, there are no members of the release team themselves ? If yes, then it may be more fruitful to explore alternatives. I think there are (or, at least, were) some supporters of the concept on the team. I certainly remember several members of the release team following the Multi-Arch/ia32-libs removal release goal in Wheezy. I suspect part of the issue is that the current team is less invested in many the individual goals compared to earlier releases. In theory, this should be good - the project should be able to have a release goal without the driver behind it being a member of the release team. In practise, it has not worked out so well. In my experience, many of the Wheezy release goals became second-rate goals - we simply failed to follow up on those goals as we promised, we would. To me, release goals became that outstanding job we never had time for[1]. Honestly, I had mixed feelings when we decided to stop doing release goals. On one hand, I felt we were letting go of a good tradition and at the same time, I felt relieved that we would have one less thing hanging over our heads. Despite us letting go of release goals, I would love for the project to have something like release goals. If I have but one release goal for Jessie, then it is to get our freeze/release process back on track (including a freeze no longer than 6 months). I do not think it satisfies our own SMART criteria, but consider it a personal goal of mine. :) The Debian Enhancement Proposals (DEP) have an advantage, as they provide a way to record whether a given goal is still relevant after a release, or if it has eventually been obsoleted. http://dep.debian.net/ Have a nice day, It is quite possible that we should be looking at DEPs as (a part of) the replacement for release goals. I certainly hope that people, who wanted to do a release goal for Jessie, will not be stopped by all of this. Rather, I would be glad if they still carried out their proposal - be it as a personal goal for Jessie or a DEP. The secret behind completing a release goal is doing it (or convincing other people to do it for you[2]). ~Niels [1] Please note that this had nothing to do with the actual goals proposed for Wheezy or Jessie. There are several goals for both Wheezy and Jessie I accepted/considered to accept as a release goal. [2] Pro-tip: Tools like Lintian and piuparts are exceptionally good at convincing people to change their packages. :) They tend to also give you at least the SM in SMART. Then you just have to focus on the ART of the (release) goal. (SCNR) -- 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/52ad9432.3020...@thykier.net
Re: Role of Release Goals
* Niels Thykier (ni...@thykier.net) [131215 12:36]: In practise, it has not worked out so well. In my experience, many of the Wheezy release goals became second-rate goals - we simply failed to follow up on those goals as we promised, we would. To me, release goals became that outstanding job we never had time for[1]. Basically, release goals came to existence because in the past people tried to force incredible many things on us as release blocker which then ended as impossible to release anymore with so many things. (Because it had been argued before that anything which is not a release blocker and is a change is only severity wishlist and can't be NMUed. Things moved on, so perhaps this isn't so relevant anymore anyways.) For this reason we decided that anything which is no real hard must can be tried to be implemented as release goal (which means bugs are important, and still can be NMUed by the same policies as release blocking bugs). If people manage to resolve a release goal - good. If not, the release still doesn't fail. Andi -- 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/20131215133844.gb16...@mails.so.argh.org
Re: Role of Release Goals
This one time, at band camp, Lucas Nussbaum said: On 01/12/13 at 23:32 +0100, Joerg Jaspert wrote: 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. Now, that makes sense. I apologize if I may have seemed hostile. Given your tone and approach with DSA, it seemed reasonable to me that you were taking the same approach with the release team and just arbitrarily trying to remove things that they have historically done. If they want to cede this responsibility to others, that's of course fair enough. 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)
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
Am 02.12.2013 08:03, schrieb Lucas Nussbaum: 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. a technical project goal applied to a subset of packages could become a release-goal too, e.g. to all packages in the minimal chroots, or to all packages needed to build the minimal chroots. Which rules could need adjustment? - NMU rules? (I already argued against it, but feel free to disagree) It would be nice to have some way to do one NMU for severeal release/technical goals. Maybe nicer for the package maintainer too to only handle one NMU. - 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. It's more like some decisions are not made, or made late, e.g. architecture (re-)qualifications. 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? how is honor CC and CXX different to existing release goals like hardening (and honoring the various FLAGS)? There are a lot of these goals which could be described as sane packaging (honor cross builds, honor, no-test builds, honor verbose builds, honor hardening, honor parallel builds, honor outdated config. files, ...). In most cases these don't touch upstream at all, just the packaging. Not fixing these will cost Debian time and quality too, e.g. longer build times, more ugly bootstraps, unmet or not verifiable release or technical goals, ... 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. How would these project-wide goals decided on? There's usually a minority which objects, or the discussion dies away. At least with a release goal, there was a decision made, whether you liked it or not. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
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.] -- 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/8761r755nf@gkar.ganneff.de
Re: Role of Release Goals
Hi all, am I wrong or among the supporters of the concept of release goals, there are no members of the release team themselves ? If yes, then it may be more fruitful to explore alternatives. The Debian Enhancement Proposals (DEP) have an advantage, as they provide a way to record whether a given goal is still relevant after a release, or if it has eventually been obsoleted. http://dep.debian.net/ Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131202225901.ga14...@falafel.plessy.net
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
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. 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? -- bye, Joerg The sun? That’s the hottest place on Earth. -- 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/87bo105hiv@gkar.ganneff.de
Re: Role of Release Goals
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/msg7.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
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
Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
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. - in the past, uploads fixing release goals bugs were allowed during freeze. However, at this point, it is not clear whether this will be the case for jessie. It would be better to aim for fixing all release goals bugs before the freeze, and do a shorter freeze. - 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)? I personnally think that we should give up on the release goals process in its current form, and instead advertise recommended practices, built on the existing recommended practices for mass-bug filings[2], such as: - aim for a consensus-building discussion on -devel@ - provide a clear plan of what you are trying to achieve (with rationale, evaluation of impact, etc.) (using a wiki page or another type of structured document is a good idea) - provide objectives that are S.M.A.R.T[3] (specific, measurable, attainable, relevant and time-bound), so that it's easy to understand where you want to go. - use usertags to track progress - etc. If there is consensus that a given change and its implementation is desired by the project, I don't see what some validation from the release team would add. And if some maintainers refuse to integrate patches for a consensual change, we already have existing processes, such as bringing issues to the TC. Comments? Lucas [1] https://lists.debian.org/debian-devel-announce/2006/07/msg5.html [2] http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#submit-many-bugs [3] http://en.wikipedia.org/wiki/SMART_criteria -- 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/20131129100255.ga19...@xanadu.blop.info
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
