Barclay, Daniel wrote: > > Ken Teague wrote: > How much change (new features, re-implementations, new packages); how much > work.
This is because Debian is a packaged-based distribution and there are litterally thousands of packages that change with bug fixes, new features and so on. This also answers the question on new and obsolete packages. Debian package maintainers come and go, or no longer wish to support a certain package which then becomes orphaned and dropped from the list. More info on packages can be seen here: http://www.debian.org/devel/wnpp/ > How? (How does it sound like that?) People rarely address how the length > of Debian's release cycle is affected by how much change Debian tries to > incorporate into each release. The changes are mostly incorporated into the various packages and the Linux kernel. I don't think most Debian users are concerned with the length between release cycles. They're concerned with stability first, features second. Those who are the opposite have moved to using Ubuntu. I may be wrong, but that's the way I've always seen it. > Why are you about mentioning individual changes? I didn't say or mean to > imply anything like that. Because, again, Debian is a package-based distribution and the majority of the changes are within those individual packages and the Linux kernel that is distributed with the release. There are some changes to Debian itself, but normally very little. For example, when 4.0 was released, they added a graphical interface to the Debian Installer. If this doesn't answer your question, please provide me with some examples of what you're looking for. > If Debian set a shorter target release interval, each individual package > maintainer would implement (and test and debug) a smaller set of features > and changes (for that package) for each (more frequent) release. I don't > think there's any need for listing all the changes. What were you thinking > about? (Why would listing be or have been needed?) It seems that I may be having troubles understanding what you're thinking about. Are you asking when does the Debian release team decide when to put a freeze on testing?... and when to set a release date for what's been in freeze? > Your saying that seems to indicate that you're still missing my point (that > people seem unaware of the quantity aspect when mentioning the quality > aspect). > > Debian's long release cycle is not a result of _just_ Debian's quality. > It's _also_ a result the "chunk size," the quantity of change collected > together before freezing, testing, debugging, re-testing, etc. until it's > up to Debian quality standards for releasing. There are four parts to this; changes in packages, changes in "Debianism" (aspects specific to Debian), new packages (and what they offer), and obsolete and/or orphaned packages. You're right -- the duration between releases tend to incorporate a *lot* of changes. > Consider making two changes. You could implement, test, debug, and re-test > both before making a release containing both. Alternatively, you could > implement one, then test/debug/re-test it fix it, and then make a release > containing just that first change before starting to implement the second > change. Debian works in both ways, depending on how important the release team feels about the feature(s). I think this also is what they base a release date on, after it has been in freeze. > Doing it the second way does _not_ have to compromise any quality standards. > (Why do you (seemingly) think it does?) Perhaps I wasn't understanding you correctly the first time around. Perhaps I'm still not understanding you this time around. Nevertheless, I'm only trying to help you out. If you don't want my help, I'll kindly step to the side and see if anyone else wants to step up to this plate. > Doing it the second way would mean that each release is not as old (as they > are currently) when it is released and does not get as old (as they do > currently) before the next release is released. (E.g., the first change > doesn't have wait for the release containing the second change.) > > Doing it the second way does likely take slightly longer (since part of > the quality-checking process and the release process itself happen multiple > times). > > Except when changes can't be divided into two chunks like that, making two > smaller releases rather than one big one would very likely let Debian > releases > be more current, with no loss of quality. The cost would be some decrease > in average development speed of Debian. I think I understand, and this would be nice. I can't speak for every Debian developer out there, but perhaps it's an issue with the time they have to work on their projects and packages. Debian is a non-profit organization, not a commercial company that has time and resources dedicated to providing timely releases. > The question, of course, is whether shortening Debian's release cycle length > by a factor of, say, 2 or 1.5 (from the current length), would cost only a > very small relative amount of time and effort, small enough to be worth > doing so that Debian stable releases wouldn't initial be or become so > old, or would be a significant drain. I can't put an exact number on it, but I think there are more than a thousand Debian developers from various parts of the world, each of whom have a life outside of Debian development. Without payment, I don't think such a feat can be accomplished. How does Ubuntu do it? I think kit's because Debian developers are footing most of the work for them. > I don't follow; when does checking for changes have to do with the > discussion (about the "chunk size" of changes and releases)? > > True, but, again, how does that relate? It was a matter of me trying to understand what you're trying to get at. I may still be incorrect in interpreting what you're trying to accomplish, but it sounds like you're coming at this from a commercial perspective where a *company* has time and resources to achieve the goals you're speaking of. Again, Debian is a non-profit organization. > No. Again, it's long because of that AND because of the chunk size. > How do you (and others that replied to my message) keep missing that? Again, I could be wrong, but I think you just answered your own question again. :-) The longer the duration between releases produces (what you call) a larger "chunk size". As such, it takes longer for the features within the "chunk size" to be tested, debugged, and fixed. Personally, I'm not used to seeing anyone on this mailing list coming at me like a product manager trying to push a product out of the door, so it threw me off. Sorry for the misunderstanding. - Ken -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
