Re: All candidates: Development and technical issues and challenges
On Wed, 20 Mar 2013 01:15:58 -0400, Michael Gilbert wrote: > Even the suggestion of a testing removal can evoke negative feelings > for those affected (sometimes from those on the sidelines too). A > recent example: > http://bugs.debian.org/703258 There seems to be a misunderstanding; at least my surprise was not caused by the proposal to remove the package from testing (actually, I mentioned this as the most probably option in my first mail in the original bug report), but by the fact that I wouldn't have known about the removal bug without the later CC by Jonathan. > Do you have any thoughts on addressing the social aspect of this > approach? In this case, "X-Debbugs-Cc: $original_bug|$maintainer_address" would have been enough :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Jimi Hendrix: Message To Love signature.asc Description: Digital signature
Re: All candidates: Development and technical issues and challenges
On 20/03/13 at 01:15 -0400, Michael Gilbert wrote: > On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote: > >> Maybe we could discriminate on the package's priorities. For example, > >> about a third of the 49 packages *really* blocking the release (not > >> waiting for a transition) are from "extra"[2]. Only 5 bugs affect > >> required, important or standard packages. We could focus on those and > >> tell the "extra packages" to hurry up or be shipped with packages that > >> will need to be fixed in a point release... or simply removed. > > > > That's something I already commented on in > > https://lists.debian.org/debian-vote/2013/03/msg00020.html: > > > >Another possible area of improvement is the focusing on the more > >important RC bugs. One way to achieve that would be to remove as many > >leaf/not-so-popular packages as possible at the start of the freeze. > >If they get fixed, they could get back in. > > Even the suggestion of a testing removal can evoke negative feelings > for those affected (sometimes from those on the sidelines too). A > recent example: > http://bugs.debian.org/703258 > > Do you have any thoughts on addressing the social aspect of this > approach? In actuality, a testing removal is really not a big deal > since the package can come right back once the RC bug is fixed. Even > so, some see removals as a kind of judgement on themselves as > maintainer. What can be said or done to qualm the fear and anxiety? It is the release team's role to decide what's inside testing, and I think that it's important to respect that. However, I can understand that reaction: > I also really dislike your recent habit of making discussions hard to > follow by opening new bugs. Please keep things in one place so everyone > can follow along. (even if the tone is very wrong) Maybe we should generalize the use of the BTS' "affects" feature so that such bugs are properly "linked" to the original package? Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130320110103.ga29...@xanadu.blop.info
Re: All candidates: Development and technical issues and challenges
On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote: >> Maybe we could discriminate on the package's priorities. For example, >> about a third of the 49 packages *really* blocking the release (not >> waiting for a transition) are from "extra"[2]. Only 5 bugs affect >> required, important or standard packages. We could focus on those and >> tell the "extra packages" to hurry up or be shipped with packages that >> will need to be fixed in a point release... or simply removed. > > That's something I already commented on in > https://lists.debian.org/debian-vote/2013/03/msg00020.html: > >Another possible area of improvement is the focusing on the more >important RC bugs. One way to achieve that would be to remove as many >leaf/not-so-popular packages as possible at the start of the freeze. >If they get fixed, they could get back in. Even the suggestion of a testing removal can evoke negative feelings for those affected (sometimes from those on the sidelines too). A recent example: http://bugs.debian.org/703258 Do you have any thoughts on addressing the social aspect of this approach? In actuality, a testing removal is really not a big deal since the package can come right back once the RC bug is fixed. Even so, some see removals as a kind of judgement on themselves as maintainer. What can be said or done to qualm the fear and anxiety? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmpswcpjier+3aaeatqkecn9nl0tqca+ijqexpwpm_...@mail.gmail.com
Re: All candidates: Development and technical issues and challenges
On 18/03/13 at 19:41 -0400, anarcat wrote: > On 2013-03-11, Moray Allan wrote: > > When to release: I would also note that we should continue to be > > flexible about "-ignore" tags where appropriate. In some cases > > leaving a package in the release with RC bugs is more useful to users > > than removing it altogether. Indeed, we always release with quite a > > large number of non-RC bugs, some of which make the packages in > > question unusable for large groups of users. At any point in the > > freeze we should ask not only about the state of the frozen release, > > but how it compares to the previous release. Maybe it doesn't even > > need to be a single date -- we could badge the new release as ready > > for the desktop before we close it off as final and suggest that > > people upgrade their servers. > > I think this is a great point, and I would like to push it a little > further. > > "When to release" seems really important. As things stand right now, we > have about 70 packages (assuming one package per RC bug) blocking the > release of 38000 packages[1]. That is 0.2% of the archive. It's really > small. About 0.1% if we look at the ones that don't have a fix yet (49). > > Shouldn't we be releasing 'as is' at some point and just accept that > some bugs will be fixed in a stable release later? That's what we do. We use 'wheezy-ignore' for some bugs. But I think that it would be inappropriate to comment further on the release team's work. I think they are doing a great job. > Shouldn't we "release early, release often"? I think that the length of current Debian release cycles are a good compromise. I'd rather have us explore doing a rolling release in addition to our stable releases. > I agree that releasing with, say, 1000 RC bugs is crazy, but maybe > waiting forever for the last 100 packages is also nonsense. > > Maybe we could discriminate on the package's priorities. For example, > about a third of the 49 packages *really* blocking the release (not > waiting for a transition) are from "extra"[2]. Only 5 bugs affect > required, important or standard packages. We could focus on those and > tell the "extra packages" to hurry up or be shipped with packages that > will need to be fixed in a point release... or simply removed. That's something I already commented on in https://lists.debian.org/debian-vote/2013/03/msg00020.html: Another possible area of improvement is the focusing on the more important RC bugs. One way to achieve that would be to remove as many leaf/not-so-popular packages as possible at the start of the freeze. If they get fixed, they could get back in. But then, if those packages are not so important, it's better to focus the (scarse) manpower on bugs affecting packages that we cannot live without. Another way to achieve the same thing would be to improve existing tools, such as http://udd.debian.org/bugs.cgi (which I developed) to indicate bugs that are release blockers, or bugs that affect leaf packages that could be removed. > Maybe that's something that's already done by the release team too, in > which case I am happy. :) > > A. > > [1] 38569, to be more exact, kudos to UDD: > > SELECT COUNT(DISTINCT(package)) FROM packages WHERE release = 'wheezy'; > > [2] I had trouble with my SQL there, I could only list the packages: > > SELECT distinct(packages.package), packages.priority, bugs.id FROM bugs > LEFT JOIN packages ON bugs.package = packages.package > WHERE severity >= 'serious' > AND NOT (id IN (SELECT id FROM bugs_merged_with WHERE id > merged_with)) > AND id IN (SELECT id FROM bugs_rt_affects_testing) > AND id NOT IN (SELECT id FROM bugs_rt_affects_unstable) > ORDER BY packages.priority; SELECT count(distinct(packages.package)) FROM bugs LEFT JOIN packages ON bugs.package = packages.package WHERE severity >= 'serious' AND NOT (id IN (SELECT id FROM bugs_merged_with WHERE id > merged_with)) AND id IN (SELECT id FROM bugs_rt_affects_testing) AND id NOT IN (SELECT id FROM bugs_rt_affects_unstable); That would work, but then you have a problem with bugs filed against source packages (what's the priority for a source package?). Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130319071431.gc28...@xanadu.blop.info
Re: All candidates: Development and technical issues and challenges
On 2013-03-11, Moray Allan wrote: > When to release: I would also note that we should continue to be > flexible about "-ignore" tags where appropriate. In some cases > leaving a package in the release with RC bugs is more useful to users > than removing it altogether. Indeed, we always release with quite a > large number of non-RC bugs, some of which make the packages in > question unusable for large groups of users. At any point in the > freeze we should ask not only about the state of the frozen release, > but how it compares to the previous release. Maybe it doesn't even > need to be a single date -- we could badge the new release as ready > for the desktop before we close it off as final and suggest that > people upgrade their servers. I think this is a great point, and I would like to push it a little further. "When to release" seems really important. As things stand right now, we have about 70 packages (assuming one package per RC bug) blocking the release of 38000 packages[1]. That is 0.2% of the archive. It's really small. About 0.1% if we look at the ones that don't have a fix yet (49). Shouldn't we be releasing 'as is' at some point and just accept that some bugs will be fixed in a stable release later? Shouldn't we "release early, release often"? I agree that releasing with, say, 1000 RC bugs is crazy, but maybe waiting forever for the last 100 packages is also nonsense. Maybe we could discriminate on the package's priorities. For example, about a third of the 49 packages *really* blocking the release (not waiting for a transition) are from "extra"[2]. Only 5 bugs affect required, important or standard packages. We could focus on those and tell the "extra packages" to hurry up or be shipped with packages that will need to be fixed in a point release... or simply removed. Maybe that's something that's already done by the release team too, in which case I am happy. :) A. [1] 38569, to be more exact, kudos to UDD: SELECT COUNT(DISTINCT(package)) FROM packages WHERE release = 'wheezy'; [2] I had trouble with my SQL there, I could only list the packages: SELECT distinct(packages.package), packages.priority, bugs.id FROM bugs LEFT JOIN packages ON bugs.package = packages.package WHERE severity >= 'serious' AND NOT (id IN (SELECT id FROM bugs_merged_with WHERE id > merged_with)) AND id IN (SELECT id FROM bugs_rt_affects_testing) AND id NOT IN (SELECT id FROM bugs_rt_affects_unstable) ORDER BY packages.priority; -- The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.- Friedrich Nietzsche pgplht1NeIOo3.pgp Description: PGP signature
Re: All candidates: Development and technical issues and challenges
Lars Wirzenius writes: > Gegerly, Moray, and Lucas: > > We're currently in the middle of a freeze for the next release. We've > been in this release since June 30. That's over eight months. That's a > long time, even for a project the size of Debian. Releasing when we're > ready is all well and good, but it's a problem when it takes us so long > to get ready. > > In your opinion, what are the fundamental reasons the release freeze is so > long, and so painful, and what do you propose to do, as DPL, to fix them? The fundamental reason is that fixing bugs isn't all that rewarding in many cases, and considerably harder than doing packaging, especially in cases where one can't rely on upstream help either (for any of the million reasons). What we could and should do (and this includes everyone, not just the DPL) is to make upstreams, downstreams and everyone else involved realise that if we work together, we'll release faster, and if we release faster, we'll have more up to date software, which benefits everyone. I've heard many an upstreams (and users of downstreams too) complain about how old packages in Debian are. I myself am annoyed too about this from time to time, when I'm wearing my syslog-ng upstream hat, for example. But the only proper way to make things better if we combine our knowledge. To do this effectively, we need to learn another thing: we are not our packages. There is no shame in asking for help, or even giving up a package. There is no shame in joining a team. There is no shame in working together. All these things make us better, make the packages better, make Debian better, make the world better. Why we need to learn this? Because there are many half-abandoned packages in the archive, that make the release a lot slower than it needs to be. These should be found and taken care of *before* the freeze, and we should be doing this continously. We have a lot of data points that help us recognise these cases, we need to solve the social issues if we want to avoid these problems in the future. For that to happen, we all need to realize that we're not our packages. > What other development process problems do you see, ones that do not > directly affect the freeze, but make the development of Debian less > productive or less interesting? I feel the collaboration between Debian and downstreams is far from perfect, and that is usually a fault of both sides. Tiny little speckles of dust in the machinery some of these problems are, but if enough dust accumulates, the machinery will suffer. We need to figure out if - and how - we could work together more closely, to reduce the workload on all sides, as that also reduces the annoyance we may have with one another. > Finally, what are the main technical challenges you see for Debian in > the next five years and what should we, as a project, do about them? Most of the challenges I foresee in our immediate future are non-technical. We're fairly good at solving technical problems, so no particularly huge challenge there. At least, not anything we haven't seen before. Nevertheless, what I do find worrysome, is that there seems to be a trend of upstreams bundling third-party components (often slightly patched) into their zillion-component, big and complex solution. Untangling this mess, packaging it, and keeping it functioning is very challenging, to say the least. Persuading upstreams to not do that is - sadly - simply impossible, so we need to either work around this, or bite the bullet and package the forks too, either separately, or bundled with the application (yuck). Another - at least partially technical - challenge would be to improve our own infrastructure and processes, in order to attract more (or at least, drive away less) potential contributors. (See https://lists.debian.org/debian-vote/2013/03/msg00157.html for more details) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc8reess@galadriel.madhouse-project.org
Re: All candidates: Development and technical issues and challenges
On 2013-03-12 07:17, Paul Wise wrote: Removing packages in the freeze is way too late, they should be removed from testing in an (semi-)automated fashion during the whole release cycle. IIRC the release team are planning on doing this and have done it manually in the past. Indeed -- I should really have said something like "much earlier in the release cycle". There is apt-listbugs but does that work for things like PackageKit or software-center? I'll be interested to hear what tools already exist that I've missed. Then the challenge is to get them onto more machines in such a way that people pay attention to what they say. Normally people are installing/updating packages because they're trying to achieve some goal, and they won't tend to interrupt that to debug issues that might be mentioned in messages there. For some contributors, a popup notification about new RC bugs like existing "upgrades are available" ones might be useful, though clearly for many users this would just be an unhelpful worry. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b1d09baeecfa82dc990e8fc89b6df...@www.morayallan.com
Re: All candidates: Development and technical issues and challenges
On Tue, Mar 12, 2013 at 3:30 AM, Moray Allan wrote: > Earlier removals: I wonder if removing RC-buggy packages much earlier in the > freeze would help -- even if it's logically no different to saying they will > be removed later, it might wake up maintainers into bug-fixing action > faster, and especially maintainers of packages that are removed due to their > dependencies. Removing packages in the freeze is way too late, they should be removed from testing in an (semi-)automated fashion during the whole release cycle. IIRC the release team are planning on doing this and have done it manually in the past. > Flag up RC bugs: To tackle things earlier in the cycle, perhaps we could > push use of some tools[1] that more actively flag up new RC-buggy packages > to users of testing? There is apt-listbugs but does that work for things like PackageKit or software-center? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6hduh1xbyfuxv6ag4tgpgoqt64wn8ev96ef3drbwec...@mail.gmail.com
Re: All candidates: Development and technical issues and challenges
On 2013-03-11 01:35, Lars Wirzenius wrote: In your opinion, what are the fundamental reasons the release freeze is so long, and so painful, and what do you propose to do, as DPL, to fix them? On one level I'm cautious about answering this. I don't think that a DPL should try to impose policies on teams like the Release Team, or push their own ideas on this kind of topic rather than trying neutrally to push forward a project discussion. However, to give some of my own views, since you ask for it: Background: It seems to me that part of the problem comes from the Release Team's own past success. Individual maintainers have got used to Debian releases happening more or less painlessly, and just assume that the Release Team will get on with the work, and release when it's ready. But, of course, the release should be the responsibility of all maintainers -- and if too many of us just look after their own packages and leave the Release Team and a few helpers to do the rest, we will be waiting until the slowest maintainer has fixed the hardest bug. At the same time, as a freeze gets longer, and without a specific immediate deadline, it becomes harder to motivate people to put energy into helping. Earlier removals: I wonder if removing RC-buggy packages much earlier in the freeze would help -- even if it's logically no different to saying they will be removed later, it might wake up maintainers into bug-fixing action faster, and especially maintainers of packages that are removed due to their dependencies. Flag up RC bugs: To tackle things earlier in the cycle, perhaps we could push use of some tools[1] that more actively flag up new RC-buggy packages to users of testing? CUT: I think that some form of Constantly Usable Testing would be preferred by many desktop users to our current releases. This would solve the freeze problem for that group of users -- though I worry that it might further reduce the number of people putting energy into our current type of releases. Equally, I wouldn't expect the existing Release Team to make CUT happen, both because of lack of time, but also because they're likely to be self-selected as people who like the current style of release. When to release: I would also note that we should continue to be flexible about "-ignore" tags where appropriate. In some cases leaving a package in the release with RC bugs is more useful to users than removing it altogether. Indeed, we always release with quite a large number of non-RC bugs, some of which make the packages in question unusable for large groups of users. At any point in the freeze we should ask not only about the state of the frozen release, but how it compares to the previous release. Maybe it doesn't even need to be a single date -- we could badge the new release as ready for the desktop before we close it off as final and suggest that people upgrade their servers. Infrastructure: We should consider how we can help things by improvements to our technical infrastructure, in particular by making package source available in a shared DVCS, with tools that will automatically transfer patches to and from the BTS. We should be able to find a technical solution so that source is automatically committed at upload time for packages where the maintainer doesn't (yet) want to shift to the DVCS workflow. What other development process problems do you see, ones that do not directly affect the freeze, but make the development of Debian less productive or less interesting? For the freeze people work under lighter NMU assumptions than usual, so this is not so relevant there, but: I think some work is made much less productive and interesting by the strong idea of package "ownership" that we see from some maintainers. While their intention may only be protective, to make sure that the package stays in the best possible state, we should recognise that we're only working with software, and it's generally easy to reverse or fix changes later. Finally, what are the main technical challenges you see for Debian in the next five years and what should we, as a project, do about them? For me, the biggest challenge over the next five years is to keep being a "universal" operating system. We're doing very well on servers, and I don't see that changing in the next 5 years. We're providing a great free desktop ... but will it work on any hardware people will be using in five years' time? More and more of people's computing is being done on phones and tablets where we mostly don't run, or only run as a toy within a special sandbox. Even if we package upstream software that is great for tablets and phones, at the moment it's very hard to find devices where we can tell users that Debian will work. And we have related issues to face even on computers of a traditional form factor, with worries about how UEFI Secure Boot will be implemented. I think we can rely
Re: All candidates: Development and technical issues and challenges
On 11/03/13 at 21:49 +0800, Paul Wise wrote: > On Mon, Mar 11, 2013 at 9:19 PM, Lucas Nussbaum wrote: > > > to make fixing RC bugs more rewarding. For example, in the Debian Project > > News, we could list the most efficient RC bug squashers. > > Just discussed this in #debian-publicity, if you can write a query to > run against UDD, the publicity team is definitely interested in doing > that. What is easy to do, is get the top RC bugs *closers* for the last n days. But there are more ways to be an efficient RC bug squasher. Query for the top 10 closers in March: udd=> select done, count(*) from bugs where severity >= 'serious' and last_modified >= '2013-03-01' and status='done' group by done order by count desc limit 10; done| count ---+--- Michael Gilbert | 8 LaMont Jones | 6 Julien Cristau | 4 Ludovico Cavedon | 4 Raphaël Hertzog | 4 gregor herrmann| 3 Sebastian Ramacher | 3 Abou Al Montacir | 3 Arno Töll| 3 Sébastien Villemot | 3 (10 rows) If you want to check bugs closed by a specific email: select id, source, title from bugs where severity >= 'serious' and last_modified >= '2013-03-01' and status='done' and done_email='mgilb...@debian.org'; Note that the queries use "last_modified". There's no "done_date" field in the BTS. Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130311140212.ga10...@xanadu.blop.info
Re: All candidates: Development and technical issues and challenges
On Mon, Mar 11, 2013 at 9:19 PM, Lucas Nussbaum wrote: > to make fixing RC bugs more rewarding. For example, in the Debian Project > News, we could list the most efficient RC bug squashers. Just discussed this in #debian-publicity, if you can write a query to run against UDD, the publicity team is definitely interested in doing that. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6Ek3mtXpkZtNt4+nyJKaUBWLq5mjE=v8qw3klvzdmf...@mail.gmail.com
Re: All candidates: Development and technical issues and challenges
> In your opinion, what are the fundamental reasons the release freeze is so > long, and so painful, and what do you propose to do, as DPL, to fix them? The release process is hard to grasp. The most visible side of it is the number of RC bugs (which I contributed to increase :p) As a DPL, I will continue to support QA tests, because identifying bugs early is much better than running into them late in the release process. I will also explore ways to make fixing RC bugs more rewarding. For example, in the Debian Project News, we could list the most efficient RC bug squashers. But then, while in the ideal world, all RC bugs would be fixed, it's not that much of a problem to release with some RC bugs. There are other critical part of the release process: to release, we need an installer, release notes, etc. Those are parts of the work that are unfortunately not very rewarding and visible, and for which we have always had problems to find volunteers. There's probably a small margin of improvement for the release team to explain what are the requirements for releasing (a "why releasing is hard" presentation). As a DPL, I will encourage/help them on that path, and also try to recruit people to work where it's most needed (installer, release notes, release team, etc.). On a more personal opinion, I would welcome more exploration of gradual freezes. I understand that it's important to freeze early packages that affect the installer, and maybe also the base system. But freezing all packages with the hope that it will force people to fix RC bugs in other people's packages does not work: many people just stop working on Debian during the freeze. This was discussed a bit already, but I'm not sure that we really were throughout in the discussion. As a DPL, I will reopen that discussion at a good time (after the release, and not just after the release). Another possible area of improvement is the focusing on the more important RC bugs. One way to achieve that would be to remove as many leaf/not-so-popular packages as possible at the start of the freeze. If they get fixed, they could get back in. But then, if those packages are not so important, it's better to focus the (scarse) manpower on bugs affecting packages that we cannot live without. Another way to achieve the same thing would be to improve existing tools, such as http://udd.debian.org/bugs.cgi (which I developed) to indicate bugs that are release blockers, or bugs that affect leaf packages that could be removed. > What other development process problems do you see, ones that do not > directly affect the freeze, but make the development of Debian less > productive or less interesting? One thing that I find very frustrating is when your work is delayed because of things you can do nothing about. In the past, packages were manually signed on buildds, and it sometimes took a long time before the packages reached the archive (this is now solved thanks to buildd-autosigning). Another example is the NEW queue. While it's clearly improved a lot, it still happens that packages stay stuck there for a couple of months. When you spent hours packaging something, it's very rewarding to see the package in the archive ASAP, being available usable by users. However, besides making sure that teams are properly staffed and understand how harmful those delays are, there's not much the DPL can do there. Longer delays are probably quite unavoidable in a volunteer-based project. > Finally, what are the main technical challenges you see for Debian in > the next five years and what should we, as a project, do about them? I have some things in my platform about that, so I'll just copy/paste: State of the project [..] However, I often have the impression that the project is losing momentum, positive energy, and slowing down. It feels like we are living on the benefits of the past. A lot of very cool things happen in the Debian ecosystem, but very often outside the Debian project. It is good to be a solid basis for many innovative derivative distributions, but should we content ourselves with the package supermarket role? What should Debian be in 5 years? Debian should aim at reinforcing its position in the center of the Free Software ecosystem. It should be the main active intermediary between upstream projects and final users. Of course, providing a good basis for derivatives is important, because derivatives users are Debian users, even if some of them do not acknowledge that. But we should also aim at reinforcing the visibility and the impact of Debian itself, because the extremely important values we fight for as a project are often neglected by our derivatives. Yes, that means working on getting some of the cool stuff done by derivatives back in Debian, and creating more Debian products. For example, we have been providing a fairly good rolling release for almost 13 years with testing, but
All candidates: Development and technical issues and challenges
Gegerly, Moray, and Lucas: We're currently in the middle of a freeze for the next release. We've been in this release since June 30. That's over eight months. That's a long time, even for a project the size of Debian. Releasing when we're ready is all well and good, but it's a problem when it takes us so long to get ready. In your opinion, what are the fundamental reasons the release freeze is so long, and so painful, and what do you propose to do, as DPL, to fix them? What other development process problems do you see, ones that do not directly affect the freeze, but make the development of Debian less productive or less interesting? Finally, what are the main technical challenges you see for Debian in the next five years and what should we, as a project, do about them? -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers signature.asc Description: Digital signature
