|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
|
|
What will improve Debian most?Hi *,
So looking through the nominations, platforms and the current -vote threads, I'm left wondering if any of this actually matters. Only two candidates running, no IRC debate or rebuttals added to the platforms, and only a couple of topics people have even raised for the candidates to address? Debian used to involve lots of people with different ideas about how to improve free software; not just a handful of different ideas about how to run a free software project. One of the most impressive things about Debian in the past was its exponential growth -- users, developers, packages, architectures, email volume, etc -- but I wonder if that's still happening, or if growth is something that's been outsourced to Ubuntu somewhere along the line. Maintaining an exponential growth curve essentially means finding new ways to make Debian twice as interesting at a constant rate -- each year or two, I'd guess. So here's the question, and really the only part of this mail that warrants a response: Over the next twelve months, what single development/activity/project is going to improve Debian's value the most? By how much? How will you be involved? A possible example might be "making Debian 5% faster on m68k -- that'll affect about 1% of our users, making them about 20% happier since speed is their number one issue, for an overall improvement of 0.2%". Another might be "we'll make web applications, like WordPress, Drupal, Tomcat etc, easy to install, activate and maintain; this will expand our userbase by 30%, and make 20% of our users three times happier -- that's an overall improvement of 82%". Another might be "we'll get 45% more patches from downstream distros (Ubuntu, Xandros, HP's Mi, etc) into Debian, and get 35% more patches from Debian incorporated back upstream, for a 96% improvement in our free software community participation". Another might be "we'll make working on Debian twice as fun so current developers spend twice as much time/effort on Debian, and we'll make participating sufficiently easier to get half as many contributors again without any drop in quality, for an overall increase in our rate of improvement of 150%". Another might be "we'll stop working on Debian and move developers and users to Ubuntu instead, following Canonical's existing goals/processes, giving users three times as many other folks they can turn to for support, pre-installed systems on various netbooks and laptops, and sharing work on things like archive maintenance, bug triage, and routine packaging making that take 70% as much work, with minimal transition costs of about 5% due to Ubuntu's derived nature, for an overall benefit of 389%". Communication is important, but not if it means everyone's time and attention gets focussed on things that don't make an appreciable difference to our goals, while things that would make a huge difference keep getting ignored or deferred. And even if we didn't want to commit to actual numeric values for different ideas, we've got plenty of developers and users we could poll to at least get an overall ordering. Bonus question: in retrospect, what single activity/etc over the past twelve months improved Debian the most? By how much? (Can you really justify that?) How were you involved? Cheers, aj |
|
|
Re: What will improve Debian most?Anthony Towns <aj@...> writes:
> So here's the question, and really the only part of this mail that > warrants a response: > > Over the next twelve months, what single development/activity/project > is going to improve Debian's value the most? By how much? How will > you be involved? Maybe you meant to ask "what are you going to work on over the next twelve months that will improve Debian's value?" Because the right answer to "what one thing is going to improve $FOO the most in the next twelve months," for pretty much any value of $FOO, is "ask us in twelve months and we'll tell you." Personally, here's some things that I plan on working on over the next twelve months that I think will improve Debian's value: * Implement (or merge implementations from others) of multiple repositories, archive areas, and architectures in Lintian. Redo the Lintian reporting scripts so that they install as regular programs with documentation to make it easier for other people to set up Lintian checks of private repositories. * Whittle the Debian Policy bug backlog down considerably and document in Policy some of the things that are currently underdocumented from a standardization perspective, to provide a more concrete standard and increase their visibility. For example, I think better Policy documentation of diversions, alternatives, and symbols files would be straightforward and useful. * Try to do real work as part of the Debian Technical Committee, hopefully resulting in resolving issues and reducing the decision backlog. * Add support for the new PAM automatic configuration to the two PAM packages that I maintain. * Package more tools and utilities for maintaining Kerberos realms and OpenAFS cells. None of these are exponential and I don't care about percentages with any of them. I'm okay with that. I don't think those are useful measures, and I don't think exponential growth is a useful or interesting goal. One thousand people all improving the parts of Debian that they care about produces incredibly impressive results. -- Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: What will improve Debian most?I should probably note here that it looked like Anthony had carefully
phrased his question to apply to the entire project, not just the DPL candidates, and I replied in that context. If it was intended as a DPL candidate question, er, never mind. :) -- Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: What will improve Debian most?On Tue, 24 Mar 2009, Anthony Towns wrote:
> Over the next twelve months, what single development/activity/project > is going to improve Debian's value the most? By how much? How will > you be involved? Having such a discussion is really interesting, I would not limit it to -vote and DPL candidates. We should re-raise the topic on -devel and let all contributors share their big plans for the next year. Going further we could even have an IdeaTorrent setup (à la brainstorm.ubuntu.com) where we could all register our projects/ideas/plans for Debian and have other Debian contributors rate the ideas. (We could also have a variant open to all users) http://www.ideatorrent.org My plans/ideas are the following: - Global switch to new source format 3.0 (quilt) + drive DEP3 to standardize the meta-information on debian/patches/* - Goal: uniformize most packages around a single patch management system. This makes it easier to occasional contributors, they can help by learning a single patch management system. - Goal: better collaboration with upstream and other distributions because all Debian-specific changes are in separate patches that will be documented in a standard format (lintian warning will require that). Get rid of undocumented Debian-specific change in .diff.gz. - dpkg-vendor tool that can be used in source packages - Goal: facilitate cooperation with derivatives by having a common source package for multiple distributions - Offer some official interface in dpkg-dev to drive a package build within a VCS (source package created from the VCS directly too). - Goal: making it easier for occasional contributors so that they don't have to learn another *-buildpackage tool each time that they hack on another package. - Create a debian-love desktop application that would handhold users into becoming new contributors. The user would select "contributions scenarios" that are of interest for him and when he has some time to spend on Debian, he would run one of the scenarios suggested by the application ("translate .po file for package X", "try to reproduce bug X", "suggest debtags for package X", "add screenshot for application X") with the help of some wizard-like interface. It would make use of all the information available locally and on the net. You can combine the information that application X is used regularly and the fact that the bug #123 reported against this application (same version as the user!) is tagged unreproducible to ask the user to help reproduce the problem. Possibilities are very broad… - Goal: recruit more contributors, spread knowledge about our processes in a entertaining way, make bug management more effective (tagging bugs unreproducible would drive the attention of more users to increase the chance that someone can reproduce it), etc. - Drive DEP2 to define a system that allows us to monitor more effectively and precisely the maintenance status of all packages. http://lists.debian.org/debian-qa/2008/12/msg00046.html - Goal: ensure we always have up-to-date information on maintenance status of packages so that new contributors can be redirected where their help will be welcome, useful and not ignored. Not sure all of this fit in a single year… I would not mind if someone else would be interested to create the debian-love application. :) Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-vote-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: What will improve Debian most?On Tue, Mar 24, 2009 at 09:05:07AM +1000, Anthony Towns wrote:
> So looking through the nominations, platforms and the current -vote > threads, I'm left wondering if any of this actually matters. Only > two candidates running, no IRC debate or rebuttals added to the > platforms, [ Don't worry, you will have your rebuttals. FWIW mine has been sent to the secretary already. ] > Debian used to involve lots of people with different ideas about how > to improve free software; not just a handful of different ideas > about how to run a free software project. Nevertheless, you ask what will improve _Debian_'s value most, which sounds like a different question to me. I'll try to address both. > Over the next twelve months, what single development/activity/project > is going to improve Debian's value the most? By how much? How will > you be involved? When I joined in 2001, Debian was The Distribution that a lot of users were using and all my friends knowing Free Software was dreaming of contributing to. Things have changed since then: newbies now use Ubuntu or Fedora, and contributors can easily join their communities. Debian is too often seen as the old distro that some old timers still use, having a rusty process to join which is not worth trying. The Debian's value that needs to be improved the most is changing that: putting Debian back into its place. A place it deserves for what he has done for free software and for what it is continuing to do even if people sometime are not aware of that. That requires agreeing on a vision: we are not Ubuntu, and clearly don't target the same people; but for the people that we want to target (i.e., sysadmins, developers, power-users, derivative maintainers), we should be the obvious right choice. Now, 12 months are probably too few to reach that objective, even because it is not as measurable as your percentages. Still, if elected I will use my influence (towards the press and inside the project) to get as nearer as possible to that goal. More practically, I think the following topics are addressable in 12 months and will contribute significantly to make us re-taking the "lead" we deserve: - Open up. We are perceived as a project to which it is *too* difficult to contribute. That needs to change and can be changed in 12 months. Just yesterday I was at lunch for a keysigning with a guy which has maintained, via sponsoring, a popular scientific software of him in Debian for something like 6 years. Still, he was too scared by the NM process (thanks to frustration emails of other applicants) to attempt joining and only now, thanks to DM, he decided to try becoming one of us. That fear is unacceptable. In 12 months we can: * Decide upon the mechanism we prefer to be a more accessible project with different level of commitments. A project in which all potential contributors find the role they prefer, and get credit for it. * Send a big message to our community that we have become more open and that we are looking for them. * (In case you insist in having numbers) Measure the success of the experiment by counting the number of contributors we got - Contribute back. I feel we have the obligation of setting the example on how to contribute back our changes to the free software ecosystem, mainly towards our upstreams. I believe we are the only one that can show the path: * we have the largest package base (yes, Ubuntu is similar thanks to our work, but their "best" packagers are on a smaller package set, and "universe" patches are mostly originated from us) * we have been hit badly by not pushing back changes and we have to show we have learned the lesson * we have promised to do so in our social contract * our diversity is unique and will help, e.g., in choosing DVCS to better work with upstreams In 12 months we can set up a mechanism to track publicly which, among all our patches (or custom DVCS branches), have been sent upstream and at which "level" of acceptance we have brought them. Thanks for this inspiring question. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime |
|
|
Re: What will improve Debian most?On Mon, Mar 23, 2009 at 04:49:21PM -0700, Russ Allbery wrote:
> Anthony Towns <aj@...> writes: > > Over the next twelve months, what single development/activity/project > > is going to improve Debian's value the most? By how much? How will > > you be involved? > Maybe you meant to ask "what are you going to work on over the next twelve > months that will improve Debian's value?" Because the right answer to > "what one thing is going to improve $FOO the most in the next twelve > months," for pretty much any value of $FOO, is "ask us in twelve months > and we'll tell you." Well, there was that bonus question, which asked about the previous twelve months, that I haven't seen any answers to. I'm not sure it's actually any easier to answer, tbh. Ultimately, I don't see any problem asking what people see as the biggest forthcoming improvement for Debian though; sure it's impossible to say for certain, and most people will pick something that's somewhere between the second most important thing and the hundredth. But that's still useful and interesting; and finding out what other people are focussing on in preference to what you think is most important is interesting no matter who ends up being right. FWIW, I chose the focus ("what's important, how will you help" rather than "what are you doing, why's that important") deliberately. Maybe the best thing for Debian is something that you can't work on directly -- but it can still help to identify that thing, both so the people who are working on it feel appreciated, and so people who could help if only they were aware of the challenge become aware of it and do help. > Personally, here's some things that I plan on working on over the next > twelve months that I think will improve Debian's value: > * [...] > None of these are exponential and I don't care about percentages with any > of them. I'm okay with that. I don't think those are useful measures, > and I don't think exponential growth is a useful or interesting goal. I thought about this some more, and wrote up some of those thoughts on my blog at [0]. YMMV obviously. I'd still be interested in seeing how much of an effect you think those changes will have (and for whom), FWIW. It'd be nice to know what people's actual priorities are these days, in some way that's independent from people pointing blindly at the social contract at just repeating "our users and free software". Are Debian developers mostly interested in doing things that help themselves? Other developers? People who file bugs? People in their LUGs? How about Ubuntu or Eee or Mi users? Desktop or server users? Embedded stuff? Upstream developers? Something else entirely? > One thousand people all improving the parts of Debian that they care about > produces incredibly impressive results. Yes, that's completely true. To double Debian's usefulness, 1000 people only need to individually contribute a change that improves Debian's usefulness by a little less than 0.07%. (1.000693387..^1000 = 2) If you somehow had a thousand people that each increased Debian's value by an appreciable amount, say just 1.5%, you'd get an overall 292,443,586% improvement -- that's higher than Zimbabwe's annualised inflation rate [1]. Which is to say, definitely, and I don't think that sense of things -- that a lot of people each contributing in small amounts adds up amazingly -- is incompatible with making numerical estimates. For comparison, my estimate of the value of a small speedup on m68k was a 0.2% improvement, which is already quite a bit better than the 0.07% above. If it turns out Debian's aiming for a thousand 0.07% improvements, there's no point identifying which is the 0.071% improvement and which is the 0.069% improvement; but getting an idea of the scale is still useful. Personally, as was probably implicit in my examples, I think there's at least a handful of 10% or better improvements that could happen over the next year or two. On Mon, Mar 23, 2009 at 06:04:47PM -0700, Russ Allbery wrote: > I should probably note here that it looked like Anthony had carefully > phrased his question to apply to the entire project, not just the DPL > candidates, and I replied in that context. If it was intended as a DPL > candidate question, er, never mind. :) It was something that I think DPL candidates ought to be able to provide some interesting answers for; but I'm more interested in the question (or its answer) than in how particular people happen to respond to it. In other words, thanks for the answer. :) Cheers, aj [0] http://www.erisian.com.au/wordpress/2009/03/28/exponential-growth [1] http://www.guardian.co.uk/world/2008/oct/09/zimbabwe |
|
|
Re: What will improve Debian most?On Tue, Mar 24, 2009 at 09:05:07AM +1000, Anthony Towns wrote:
> >One of the most impressive things about Debian in the past was its >exponential growth -- users, developers, packages, architectures, >email volume, etc -- but I wonder if that's still happening, or if >growth is something that's been outsourced to Ubuntu somewhere along the >line. Maintaining an exponential growth curve essentially means finding >new ways to make Debian twice as interesting at a constant rate -- >each year or two, I'd guess. Depending on what you're measuring, we are still growing very quickly. The size of the archive and the number of packages are still going up quickly. Sustaining exponential growth in terms of project size itself *is* difficult, however, and that's where we have started to tail off. We have more and more software to work on, but the number of developers is not growing quite as much. Right now, we are one of the biggest software development organisations in the world and so we get to see some of the growth problems first. We tend to have a very flat structure in Debian, without the usual hierarchy that you'd see in most similarly-sized commercial organisations. That's a wonderful thing in my opinion, but it can also lead to problems in communication and making larger decisions. We need to encourage more people to experiment with new ideas, rather than simply live with the status quo all the time. Larger projects have inertia, and we have to acknowledge that: either push things more to overcome it, or work around it for the new ideas until they're ready for wider adoption. The DM initiative and newer discussions about debian membership are a good start to making working on Debian more light-weight. We also must make it easier for other people in the larger Debian family to work within Debian so that their great ideas and contributions make it to a wider audience rather than just their particular project. Some of the derived distros may not care about that, but for many it should be a no-brainer that working directly with the Debian teams and pushing changes up reduces work in the long-run. >So here's the question, and really the only part of this mail that >warrants a response: > > Over the next twelve months, what single development/activity/project > is going to improve Debian's value the most? By how much? How will > you be involved? I believe that the most important thing we need to do is to work out exactly what we want the Debian project to be, in terms of membership. Making it clearer and easier for people to gain recognition for whatever work they're doing on or with Debian is far and away the best way to enourage more people to get involved. For example, we're currently claim to be the "Universal Operating System", but we don't work at all for many of the people in the world as we don't support their languages. We need more translators to help with that work. In terms of strict numbers, I won't pretend to know what the difference will be. It's not going to be measureable immediately, anyway. The DPL needs to be involved to help push these changes, I think, and to help publicise them both as we work on them and afterwards to get more people on board. What do *you* think is the best thing we could do? >Bonus question: in retrospect, what single activity/etc over the past >twelve months improved Debian the most? By how much? (Can you really >justify that?) How were you involved? I think that in the last 12 months one of the biggest improvements has been making significant changes to our core teams. We have had a few years' worth of stagnation in some cases, and really good people struggling to keep up with their commitments and losing their morale to do so. We now have a lot more new blood in place, and plans to introduce more. We have better processes in place as well, that will scale better for more people and more workload. It's not perfect yet (and never will be!), but things are better. I won't claim too much credit here - the real work is down to the team members involved. But I did step in and start pushing for those changes in a number of teams. Numbers? Meh: what do you think? :-) -- Steve McIntyre, Cambridge, UK. steve@... You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-vote-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: What will improve Debian most?On Sat, Mar 28, 2009 at 11:59:43PM +0000, Steve McIntyre wrote:
] Campaigning period: Sunday, March 8th 00:00:00 UTC, 2009 ] - Saturday, March 28th 23:59:59 UTC, 2009 Hmmm... Cutting it fine... > Depending on what you're measuring, we are still growing very quickly. > The size of the archive and the number of packages are still going up > quickly. Here's what that actually looks like: release sources packages src growth bin growth hamm 1115 1524 slink 1580 2269 42% 49% potato 2647 3889 68% 71% woody 5218 8273 97% 113% sarge 8727 15195 67% 84% etch 10220 18051 17% 19% lenny 12123 22311 19% 24% (limited to main, and packages is for i386) I wouldn't say that's particularly quickly; but given the varying release times, it's a bit hard to really tell. Correcting for that: release date days s.p.d p.p.d sg.p.a pg.p.a hamm 1998-07-24 slink 1999-03-09 228 2.04 3.27 75% 89% potato 2000-08-14 524 2.04 3.09 43% 46% woody 2002-07-20 705 3.65 6.22 42% 48% sarge 2005-06-06 1052 3.34 6.58 20% 23% etch 2007-04-08 671 2.23 4.26 9% 10% lenny 2009-02-14 678 2.81 6.28 10% 12% {s,p}.p.d = (net) new source/i386 packages per day. {s,p}g.p.a = annualised growth in source/i386 packages; so eg the 42/49% growth in slink gets annualised to 75/89% since it took under 8 months to release slink. Formula is (100%+growth)^(365/days)-100% Dropping from 75% to 40% to 20% to 10% in source package growth per year is a bit sad -- but it's certainly interesting that the (net) number of new source packages per day has stayed fairly constant. Translating those percentages into a doubling rate (how many months to double the number of source/binary packages) gives: release dbl src dbl pkg slink 15 13 potato 23 22 woody 24 21 sarge 47 39 etch 97 89 lenny 90 73 Moore's law is about 18 months, which means we're not scaling at the same rate technology is, and haven't been close since woody's release. There's three ways of looking at that, some or all of which might be valid: * it's a good thing, extra packages are a cost when trying to work out what to install, so it's better to scale by combining functionality into common packages * upstream isn't scaling with Moore's law, there's not that many new packages, because there just isn't that much new software * we haven't figured out how to offload enough of the scaling work onto technology, so we're not scaling with Moore's law Personally, there seems to be an increasing number of things I'd like to try that just aren't packaged for Debian, so I don't find the first two answers alone entirely satisfying. Obviously YMMV. > Sustaining exponential growth in terms of project size itself > *is* difficult, however, and that's where we have started to tail off. Well, the above growth doesn't look exponential either. But project size is worse, because it's basically stagnant since 2002 (going by vote.d.o's developer count at DPL election): 2000 347 2001 ? 2002 939 2003 831 2004 911 2005 965 2006 972 2007 1036 2008 1075 2009 1043 -- estimated from projectb There are also about 84 DMs currently, and some number of people maintaining packages by sponsorship. For comparison, if my LaunchPad fu is any good, Ubuntu core has some 55 members (upload to Ubuntu's main), MOTU has some 120 members (upload to Ubuntu's universe), and REVU has something like 948 members (reviewed upload to universe). I'm not sure what that should imply for Debian -- maybe it means the 8x factor between MOTU and REVU is something we should be able to duplicate between DDs and sponsored uploaders, eg. > > Over the next twelve months, what single development/activity/project > > is going to improve Debian's value the most? By how much? How will > > you be involved? > I believe that the most important thing we need to do is to work out > exactly what we want the Debian project to be, in terms of membership. That seems very meta, as did Zack's answer. As a Debian user, or as a free software developer, I just don't see a lot of benefit in that, and I can't really see how other users/hackers who aren't directly involved in Debian would do any better. Likewise with: > I think that in the last 12 months one of the biggest improvements has > been making significant changes to our core teams. [...] I realise this is seen as a huge thing within the project -- finally, the cabal is overthrown, long live the new cabal and all -- but what's the externally visible benefit? I guess there's the 1%-2% increase in package growth above for lenny compared to etch? Is there anything else? > In terms of strict numbers, I won't pretend to know what the > difference will be. It's not going to be measureable immediately, > anyway. Presumably an important part of any leadership role is the ability to prioritise different goals, and to justify those priorities. Isn't estimating, quantifying and measuring costs and benefits pretty much the state of the art in doing that well? > What do *you* think is the best thing we could do? I don't know; I've lost a lot of confidence in Debian's capabilities. Which is a shame, because I don't think there's ever been a time when its potential to make an impact has been higher -- both directly, and through Ubuntu's userbase. The biggest single benefit to users that I can think of would be providing a good way of packaging and maintaining web applications for deployment on servers -- dealing with the inevitable security updates, being compatible with multiple web servers (and fastcgi, etc), being compatible with multiple databases and automatically configuring them, supporting multiple sites on a single system, supporting user-based access control, etc. Some of that's already done (particularly the database support), other bits not so much -- in my experience, outdated packages have been the showstopper. Getting that done well would affect a signficant number of server installs for both Debian and Ubuntu, in a fairly notable, user-visible way; and hosting web apps is one of the areas proprietary software competes with free software on a relatively level playing field. Free software's doing pretty well, so I can't think of any big wins for it. A moderate sized one could, I think, be had by partnering with proprietary vendors who build things Debian users want to run -- eg, vmplayer, lots of webapps etc -- and having them officially packaged and distributed by Debian. Benefits: makes things easier for Debian users, improves free software's position when people compare installing/running that software on proprietary platforms against Debian, and gives the vendors an opportunity to see benefits of open source development techniques, which will encourage them to adopt some of them, increasing the amount of software freedom in the world. Certainly there are lots of things purely within Debian that could be better; but if there aren't some big externally visible wins that Debian's going to have, it all seems a bit pointless. Why spend time making Debian twice as successful at achieving (almost) nothing, when there are so many other projects out there making huge differences to people's lives? > >Bonus question: in retrospect, what single activity/etc over the past > >twelve months improved Debian the most? By how much? (Can you really > >justify that?) How were you involved? > Numbers? Meh: what do you think? :-) I can't actually think of anything much over the past year that's been a huge win. Certainly nothing on the scale of the ssh vulnerability, and I'm not sure of anything even on the scale of losing m68k. Anyway, a few things that come to mind, and some corresponding numbers: equivs bug #449542 had its patch applied and uploaded by NMU, which made me happy. According to popcon, equivs has a vote thats about 1.39% the size of perl-base's. On my system there's about 300 packages that get a vote; and I'd count the patch itself as a moderate feature. So if that counts as a 20% improvement to equivs, which is 1/300th of 1.39% of Debian systems, that's a 0.00093% improvement for the project. debhelper got a new "dh" interface, which was kinda cool. Its vote is about 7.02% of perl-base, but the new feature's probably a bit obscure, so count it as a 5% improvement to the package. That's a 0.00117% improvement to Debian. goplay got mentioned in the release notes and sounds kind of cool. It's not used much yet though it seems -- its vote is only 0.13% of perl-base. Now it's a completely new package, so say a 100% improvement score for its users, resulting in a 0.00043% improvement of the distro as a whole. The armel port got released. AIUI the benefit of armel over arm is incremental: some new hardware's supported, programs run a bit faster, but it's not especially exciting to people who don't dream in Arm assembler. So call it a 5% improvement for the average arm user, which according to popcon is about 1.29% of Debian users (about half of whom are running armel already), for a 0.065% improvement. What's that mean? It means the addition of "dh" improved Debian's user experience by slightly more than the equivs bugfix, but not much. Does that sound sensible? It fits my thoughts, but maybe I'm way off. "dh" has the advantage that it might make Debian easier to develop, leading to more bugs getting fixed in future; you might or might not want to count that in your comparison. It means goplay was only worth about half of "dh" or the equivs patch -- even though it's a major, useful new feature, nobody's taking advantage of it. It means the armel port is worth about 70 improvements on the scale of the equivs patch or "dh". If 10 people were involved in the armel rollout, they should've each spent about 7 times as much effort getting it done as was put into dh or that equivs patch for their time to have been well spent. Those seem like useful things to be able to quantify and reason about to me. Cheers, aj |
|
|
Re: What will improve Debian most?On Mon, Mar 30, 2009 at 12:23:43AM +1000, Anthony Towns wrote:
>On Sat, Mar 28, 2009 at 11:59:43PM +0000, Steve McIntyre wrote: > >] Campaigning period: Sunday, March 8th 00:00:00 UTC, 2009 >] - Saturday, March 28th 23:59:59 UTC, 2009 > >Hmmm... Cutting it fine... Yup. :-) Started replying much earlier, then got distracted by a phone call from mum. She does pick the worst times... :-) As we *are* now outside of the campaigning period, I'll not respond to anything more here on the list. -- Steve McIntyre, Cambridge, UK. steve@... "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-vote-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: What will improve Debian most?This one time, at band camp, Anthony Towns said:
> > I wouldn't say that's particularly quickly; but given the varying release > times, it's a bit hard to really tell. Correcting for that: > > release date days s.p.d p.p.d sg.p.a pg.p.a > hamm 1998-07-24 > slink 1999-03-09 228 2.04 3.27 75% 89% > potato 2000-08-14 524 2.04 3.09 43% 46% > woody 2002-07-20 705 3.65 6.22 42% 48% > sarge 2005-06-06 1052 3.34 6.58 20% 23% > etch 2007-04-08 671 2.23 4.26 9% 10% > lenny 2009-02-14 678 2.81 6.28 10% 12% > > {s,p}.p.d = (net) new source/i386 packages per day. > > {s,p}g.p.a = annualised growth in source/i386 packages; so eg the 42/49% > growth in slink gets annualised to 75/89% since it took under 8 months > to release slink. Formula is (100%+growth)^(365/days)-100% > > Dropping from 75% to 40% to 20% to 10% in source package growth per year > is a bit sad -- but it's certainly interesting that the (net) number of > new source packages per day has stayed fairly constant. rate has been constant, but the percentage growth falls as the total increases. Calling the latter development 'sad' ignores the truth that it hasn't slowed down, but has been consistently high since woody. You're also making some implicit assumptions about what is available - are there really 9855 new projects that should have been added to Debian last year that weren't? This is based on (13601 * .8) - (2.81 * 365) (80% increase in total source packages) - (actual increase in source packages) I can't imagine that's the case, really. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@... | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | ----------------------------------------------------------------- |
|
|
Re: What will improve Debian most?On Sun, Mar 29, 2009 at 04:04:22PM +0100, Stephen Gran wrote:
> > I wouldn't say that's particularly quickly; but given the varying release > > times, it's a bit hard to really tell. Correcting for that: > > release date days s.p.d p.p.d sg.p.a pg.p.a > > hamm 1998-07-24 > > slink 1999-03-09 228 2.04 3.27 75% 89% > > potato 2000-08-14 524 2.04 3.09 43% 46% > > woody 2002-07-20 705 3.65 6.22 42% 48% > > sarge 2005-06-06 1052 3.34 6.58 20% 23% > > etch 2007-04-08 671 2.23 4.26 9% 10% > > lenny 2009-02-14 678 2.81 6.28 10% 12% > You're also making some implicit assumptions about what is available - > are there really 9855 new projects that should have been added to Debian > last year that weren't? This is based on > (13601 * .8) - (2.81 * 365) > (80% increase in total source packages) - (actual increase in source packages) Don't know where you've got 13,601 from, the numbers I was working with (stable releases, main) were: > > release sources packages src growth bin growth > > etch 10220 18051 17% 19% > > lenny 12123 22311 19% 24% Moore's law (18 month doubling) implies an annual increase of just under 60%, so if lenny increased at 10% pa by source packages, it needed another 5x that, so an extra 14 packages per day, or 5128 over the year. How might you make that up? * There are about 1064 additional source packages in sid (main) compared to what's in lenny * There are about 2490 unclassified normal and wishlist bugs against wnpp that seem to be mostly ITP/RFP's * There are about 2549 packages in intrepid (Ubuntu 8.10) main+universe that aren't in sid (there are 1130 packages in sid that aren't in intrepid) * There are about 634 unique packages in Debian's contrib/non-free and Ubuntu's multiverse/restricted that could potentially be freed If there's no overlap there, that adds up to a potential 6737 additional source packages for lenny/main, but even considering overlap, it still seems in about the right ballpark. And that's not looking particularly far afield for additional packages. Or take it the other way -- getting the ~2500 additional packages from wnpp or Ubuntu (not both) at the current rate of three per day will take two and a quarter years. And that's just playing catch up, not counting new software that's developed in that time... Cheers, aj -- To UNSUBSCRIBE, email to debian-vote-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: What will improve Debian most?On Sun, Mar 29, 2009 at 04:04:22PM +0100, Stephen Gran wrote:
> You're also making some implicit assumptions about what is available - > are there really 9855 new projects that should have been added to Debian > last year that weren't? Via twitter [0] here's another point of comparison: the iPhone app store opened in July last year, and in that pretty brief time has something like 30,000 apps [1] for its single platform. Debian has 4,847 less than that in sid (main, contrib and non-free) for our most popular platform (i386). CPAN has 15,496 modules apparently, compared to around 1,673 lib*-perl packages. "gem list -r" lists about 4,500 Ruby Gems, compared to about 530 packages with ruby in the name. There are 4,245 wordpress plugins and 700 wordpress themes. There are about 2,120 drupal modules compatible w/ version 6 (somewhat more for version 5). Those (CPAN, Ruby, WordPress, Drupal) alone add up to about 25,000 additional packages, let alone 9,855. I don't know how you want to count the iPhone stuff -- all of which was either ported or written for scratch in the past ten or so months -- but I suspect most of the software there isn't already packaged for Debian. And yes, a lot of those packages would be crap compared to what we currently have in the archive -- they'd be things that make your phone sound like bodily functions, NIH-versions of things other people have already done, Bobby's first program with a deliberately or accidentally non-free license, and I'm sure there wouldn't be much of interest in the maintainer scripts for them either. But take all that for granted: would finding a way to redistribute as much of that as we could serve our users? I suspect so -- making it easy to get software, and having a single point of control for sysadmins to manage it is Debian's raison d'etre, afaict. Would it serve the free software community? How many modules, plugins and themes are freely licensed, and how many more would be if they were redistributed by folks who have learnt about licensing issues and care about encouraging free licenses? Wouldn't having a free Linux distro that's keeping up with new distribution models like the iPhone App Store and Ruby Gems be a useful tool in keeping free software and Debian users relevant and competitive on every playing field? Don't get me wrong, I don't think it'd be easy to handle that sort of scale -- the archive software might cope with that sort of growth but it'd be rough, it'd probably be pretty tough on the capacity of our servers, it'd require more automated maintenance techniques (eg, automatically packaging every module in CPAN), which would in turn require more automated testing techniques (so that automatically packaged modules that are obviously broken don't go into sid), unless most of it was arch:all stuff, it'd be tough on the autobuilders, it'd be tough on the mirrors, it'd be especially tough on searching through the Packages file, and I'm sure there's other challenges that would have to be met. And maybe Debian's not up to meeting those challenges -- maybe keeping a roughly constant growth rate is good enough; maybe all the clever tech that would have to be built is too much effort; maybe there'd just be too many arguments for anyone to bother with. But if Debian doesn't tackle the issues blocking us from distributing lots of the software people are actually using, and if Debian leaves those problems to Apple and Google and Drupal and CPAN to address... Well, if you're not addressing the problems people see as relevant, aren't you irrelevant? Cheers, aj (wondering if Debian's prospective leaders for the next year will have anything further to add when the votion period ends in 30 hours or so) [0] http://twitter.com/diveintomark/status/1360639404 http://identi.ca/notice/2904469 [1] http://www.148apps.com/news/wowza-30000-apps-itunes-app-store/ http://148apps.com/10000/ |
| Free embeddable forum powered by Nabble | Forum Help |