Re: A progressive distribution
Joseph Carter wrote: IMO, dist and a half is mostly fluff as far as press releases go. potato and a half would be a potato dist with a 2.4 kernel, possibly some new X stuff if it can be done and a new apache. It's still out of date potato otherwise. I want a REAL upgrade! In the case of slink and a half, it's fluff that lets you install on laptops a normal user could never get working with plain slink. -- see shy jo
Re: A progressive distribution
On Wed, Mar 15, 2000 at 09:35:16PM +0100, J.H.M. Dassen (Ray) wrote: On Wed, Mar 15, 2000 at 15:06:57 -0500, Jaldhar H. Vyas wrote: It wouldn't help with out and out buggy programs but at least it would catch dependency problems. It would catch problems with the dependencies a package declares. But it's no substitite for integration testing, part of which checks that the declared dependencies of a package accurately reflect the real dependencies. true. that's why there will still a need for the freeze/test/release part of the cycle even after automated snapshot releases are possible. snapshots will get the latest stuff out to the nearly-bleeding-edge users fast (hopefully once/month)...those users will then use test the software. final testing as an integrated system will be done as normal, with our usual freeze/test/release procedure...but should go faster because many of the serious package bugs will have already been found by snapshot users. as i recall it, the basic package pools idea was something like: development cycle: incoming - packages arrive here and stay until all dependancies are met (i.e. satisfied by the packages in unstable or incoming) unstable - packages auto moved to here by dinstall if no dep. problems ??? - packages auto moved to here after basic criteria met (e.g. in unstable for 2 weeks with no bug reports). can't remember what this stage was to be called. snapshot - built automatically from the latest stuff in '???'. release cycle: frozen - forked from the latest snapshot when the release team feels it is nearly ready. stable - final release, after testing, debugging, and integration work (both cycles can, and probably will, occur simultaneously. the release cycle can happen as often as the release team have the energy for it, perhaps with as little as a few weeks or a month between a stable release and the next freeze) target users: 'unstable' will probably be used mostly by developers and bleeding-edge type users. 'snapshot' will be used by those with fewer guinea-pig genes, who want something up-to-date but with major obvious problems resolved. 'frozen' is for those who just can't wait for stable or who want to help with final testing. 'stable' is for everyone. craig -- craig sanders
Re: A progressive distribution
On Thu, Mar 16, 2000 at 11:02:31AM +1100, Craig Sanders wrote: ??? - packages auto moved to here after basic criteria met (e.g. in unstable for 2 weeks with no bug reports). can't remember what this stage was to be called. i feel a need to write some more about this stage. this is the workhorse of the package pools/rolling release idea, this is where there will be the most work to be done, fine-tuning the criteria (and probably the source of the loudest and longest debates). there have already been several discussions on appropriate criteria...some as simple as the automatic after two weeks example above. others as complex as manual, requiring endorsement by X number of people. by trying different criteria here, we'll eventually come to the ideal compromise between stability and speed of release. we probably wont get it right the first time around. the tests here will mostly be regarding usability/stability of the package, and how it integrates into the system - i.e. it will be driven by user bug reports as most packaging bugs will have already been caught by the dinstall process which moves packages from incoming to unstable (which would check for dependancies and run a lintian test, holding or rejecting packages which have errors) craig -- craig sanders
Re: A progressive distribution
In article [EMAIL PROTECTED] you wrote: You know, the whole concept of 'a release' is orthogonal to the way I think about Debian. We've been through that before, too, and I understand the various reasons that it's important for us to make a release from time to time... but I doubt any of my machines will ever run a release. The beauty of the Debian development model in the presence of sufficient network bandwidth is that you don't have to wait until some release happens to get new functionality or bug fixes... The package pool concept on some level is just an efficiency hack for managing the master archive site better, but it is also fundamental enabling technology for supporting the idea of having multiple simultaneous flavors of Debian. this is the workhorse of the package pools/rolling release idea, this is where there will be the most work to be done, fine-tuning the criteria (and probably the source of the loudest and longest debates). Absolutely. What I realized after talking to Manoj at some length face-to-face at the Usenix Tech conference in New Orleans a couple of years ago is that we will need to have different snapshots (I actually don't like that name) with different criteria. He and I had a fundamental difference of opinion about how automated the package promotion to stability should be. I think we both had reasonable approaches, and there's no reason not to implement both if people want them. The beauty of the package pool concept is that the cost of each flavor is pretty low, so there's no reason we can't have a number of them. Some might be different levels of stability towards a release, some might be proper subsets like Debian Jr. There are a number of secondary issues, like how many versions of each package you can afford to have in the pool before you run out of disk space, but those are all manageable... and we'll learn by doing. I gathered from Guy's email a while back that a prototype might be underway on a Debian machine somewhere. I have spent a bunch of time talking with the other developers at work, one of whom gets paid to do revison control and release management for a living, about this. I believe there are enough interested people willing to work that we *will* have something in place before woody, but I've promised myself that I won't personally do any more work on package pools until potato releases. Bdale
Re: A progressive distribution
Michael Stone wrote: On Wed, Mar 15, 2000 at 03:27:18PM -0500, Jaldhar H. Vyas wrote: > On Wed, 15 Mar 2000, Ed Szynaka wrote: > > > How does this account for drastic changes to something like libc that > > > might take weeks or months to shake out? > > Build daemons could take care of the 90% or so of packages that would just > need a recompile. That ignores the arguments over what needs to be recompiled, the time needed to discover problems, the time needed to make the compilations work, etc. Build daemons are not omnipotent. (Otherwise they'd be build deities...I digress.) All right. Why doesn't anyone take the tools developed in mozilla.org seriously? I think their build tracking tools are quite excellent. I'm sure that it would be a breeze to hinge a debian source build back-end to that and get it up and running together with the fancy web interface. -- Mike Stone Part 1.2Type: application/pgp-signature -- -+++-+++-++-++-++--+---++- --- -- - - + Eray "eXa" Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED] . ^ . .
Re: A progressive distribution
On Wed, 15 Mar 2000, Bdale Garbee wrote: In article [EMAIL PROTECTED] you wrote: After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. I gather you haven't read the discussion of package pools in the archive? Not all of it, and after reading some people not having the same option of that I wanted to suggest an additional idea, that is more simple (both in the sence of less advantages and less work). First things first. Let's get potato released, As I wrote, nothing can be changed before. Hochachtungsvoll, Bernhard R. Link
Beyond Package Pools (Was: Re: A progressive distribution)
J.H.M. Dassen (Ray) wrote: On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote: try this hypothetical release method out: there are two trees. let's call them devel and production. debian saavy folks (maintainers) run devel. new packages are uploaded to devel where they are tested extensivly. when a package has been in devel for more than (for instance) two weeks, and it has no release critical and few important bugs, it graduates into production. the production branch should always work. But it won't. This approach ignores the fact that stability is a property of a release as a whole (the set of packages and their interdependencies, ISOs, boot floppies and the upgrade path from the previous release) rather than the sum of the stability of individual packages. Ray So, that's why the current scheme is correct? It obviously suffers from latency, though it doesn't suffer from quality. It doesn't suffer from quality, because releases are being managed, in order for a package to get into stable it has to go through extensive testing. That's in fact the main advantage of Debian. Now, how do we combine this with responsiveness, and an organic distribution like the FreeBSD? (in which there is rock-stable distro, a working distro, and an unstable distro, three of which are constantly developing) Here is the outline of a proposal which might do that: 1. Define subsystems within the debian system. One example is the X subsystem. However, that's too big. The point here is that the current classification of packages would be too coarse grained. I would suggest that, for instance, X applications that support gnome and are IRC clients are one class while console IRC applications are another class. A classification scheme as this would a) make browsing and finding of packages easier since it makes better use of real world semantics b) can be used to formalize things, it's just a DAG 2. Divide and conquer the release process. Define the dependencies and interfaces of each subsystem with others. Then, reorganize the release process as follows: a) A Release Team is responsible for each subsystem. The Release Team does not have to be comprised of developers of packages of that subsystem. Release Team decides which packages graduate to working and then to stable. Except that Release Teams may define other flavors of distributions for their subsystem. [Here I assume that package pools is working, and has three virtual distros called: stable, working, unstable] b) According to the number of packages (or the sum of weights of packages) in that subsystem and the number of dependencies with other subsystems (that's important), we give a weight to that subsystem. According to some thresholds, small subystems are release-managed by the smallest-weighted Team, closest up in the hierarchy. Some other thresholds may be used to indicate the importance of the release in that part of Debian. c) Debian has some serious glueware, config tools, and a complicated package management. The policy for dealing with package management and etc. seem to be quite effective at the moment. No need to fiddle with that. However, the Debian specific software is represented also in the regular release process, and since their weights would be great their importance would have been shown faithfully. The use of these tools, and policy is made even more comprehensive and documented extensively for other developers. d) There is a System Release Team which overlooks the activities of subsystem Release Teams and coordinates them and guides them towards some goals such as the release goals that Debian had in potato. The Release Teams can have their own release policies and quality considerations, however they would have to state their reasoning. The System Release Team *doesn't* have absolute control over the Release Teams, they just represent the overall concern for Debian. 3. Implement this new scheme. In the low level, tools such as debdiff and build daemons will have significance. In the high level, package pools, release management tools, and a web based status / modular organization tool must be handled, probably the bug tracking system should interface with this tool. Perhaps, the bigger release teams must have their own mailing lists and other communication media, too. A developer should be able to find other developers' contact information easily, and participate in subsystem discussions... This is quite open-ended. A point which might strike is the existence of task packages. Don't they constitute, somewhat the required organization? The answer is both yes, and no. The task packages in their natural extension could represent a part-of hierarchy in Debian. However, they have overlapping
A progressive distribution
After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. As I understood the problem, at the moment, only the stable distribution is able to be distributed, while the unstable branch is to unstable and there's no distrubution in between. (To simplify I count the frozen as stable short before release here.) When potate becomes stable, a branch called e.g. progressive could be created between the branches stable and unstable. This branch (sorry for using this term, but I don't like distribution so much) would start with the modules from stable and subsets of unstable would be added, if they are usable. The term subset I use for packages that contain together like one ore more basis packages (libc,xfree,perl,... or just something like emacs) and those packages depending on this basis package. (Note that I mean basis as basis of dependencies not basis of the whole or larger parts of distribution) And usable shell mean, that this package can be used for average use without the need of Debian-like-tability. With the next freeze, this progressive branch could be copied to froozen and new useable packaged from unstable would go to progressive, while those in frozen are kept and only made more stable. Doing this there would be a distribution in between, where new versions of products can reside and easily be used. Someone should be easily use a snapshot of progressive at an good moment to form a not-so-stable but up-to-date unofficial release, which could also be called less inoffical, if there is a common will for this. Though some advantages this would cause at least two problems: On the one hand this proposal would prohibit the current way of naming, because with any release a new distribution is created beetween stable and unstable, so some branch would change name and the old name would be used for a possibly totally other branch. So unstable( and perhaps progressive) had to be without name and just be unstable. This coresponds to the loss of a cycle for the whole distribution. Changes would start in unstable and go through the phases of unstable, progessive and froozen before they become stable. On the other hand would this proposal multiply the number of branches to up to four when there will be the next freeze and stable,frozen,progressive and unstable beeing all together. This made me the most headacke, but I think it's not so much of a problem, as many work to make the frozen version of his package will seriously prevent him from working so much on the unstable version, that this could become usable. So most packages would be either the same in frozen and progressive or they would be same in progressive and unstable. Hochachtungsvoll, Bernhard R. Link
Re: A progressive distribution
Bernhard R. Link wrote: After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. As I understood the problem, at the moment, only the stable distribution is able to be distributed, while the unstable branch is to unstable and there's no distrubution in between. (To simplify I count the frozen as stable short before release here.) When potate becomes stable, a branch called e.g. progressive could be created between the branches stable and unstable. This branch (sorry for using this term, but I don't like distribution so much) would start with the modules from stable and subsets of unstable would be added, if they are usable. The term subset I use for packages that contain together like one ore more basis packages (libc,xfree,perl,... or just something like emacs) and those packages depending on this basis package. (Note that I mean basis as basis of dependencies not basis of the whole or larger parts of distribution) And usable shell mean, that this package can be used for average use without the need of Debian-like-tability. Do you mean like, Slink 2.1 r1, 3.1r2, 2.1r3, 2.1r4 ? Id like to see a rolling stable release, where unstable package have to meet a certain pre-defined criteria before they can be considered stable. Like to be stable, a package must not have any rc bugs, or have any rc bugs in its dependencies. It would also have to be exposed to the masses for a certain period of time in unstable before being considered for stable. This type of arangment could be automated prety well, it would depend on people reporting bugs and would place extra strain on bug tracking, but i think it would be easier than trying to get all the latest versions of each package bug free at one point in time. A rolling stable release such as this may well scale better than the traditional release model. Just a thought Glenn McGrath
Re: A progressive distribution
In article [EMAIL PROTECTED] you wrote: After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. I gather you haven't read the discussion of package pools in the archive? First things first. Let's get potato released, and then get pools and flavors implemented before we try to release woody. Bdale
Re: A progressive distribution
In article [EMAIL PROTECTED] you wrote: After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. I gather you haven't read the discussion of package pools in the archive? First things first. Let's get potato released, and then get pools and flavors implemented before we try to release woody. I'm all for that if you think the pools idea has any chance of being implented in our lifetime. A really simple way of handling a progressive distribution would be to mutate frozen. After potato ships have frozen become thaw. Thaw would be unstable except there is a lag time between .debs hitting unstable and migrating to thaw. This lag time should be long enough to catch any critical bugs where we could tag the package from moving into thaw until those bugs are fixed. When a new stable is ready to be shipped out we'd simply freeze the thaw and prod the developers to fix thier critical bugs. What problems would the above cause? Could we code around issues like say php xx.3 requiring apache xx.3 and apache not hitting thaw due to a crit bug? The system would need to know to keep php xx.3 out until apache become thawable. -Mark
Re: A progressive distribution
i have seen a lot of discussion about a distribution half way between stable and unstable. on the surface that sounds like exactly what we need, but at least one person pointed out that this is not the way to manage a project with hundreds of developers working against hundreds of seperate releases cycles. i wish i could remember who said that first, you really hit the nail on the head. the deadline-based release cycle may work great for commercial projects, but quite possibly not for projects like Debian. i think we need something a little more organic. try this hypothetical release method out: there are two trees. let's call them devel and production. debian saavy folks (maintainers) run devel. new packages are uploaded to devel where they are tested extensivly. when a package has been in devel for more than (for instance) two weeks, and it has no release critical and few important bugs, it graduates into production. the production branch should always work. a system could be put in place where you could always get an iso image of the production branch that is recent to within a few days. i imagine that we would need to get pools in place before we could even attempt this. this type of system could probably work along side of whatever else we decide to to about release cycles. -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: A progressive distribution
Jacob Kuntz wrote: the production branch should always work. a system could be put in place where you could always get an iso image of the production branch that is recent to within a few days. i imagine that we would need to get pools in place before we could even attempt this. this type of system could probably work along side of whatever else we decide to to about release cycles. This production branch presents a few problems to package maintainers unless some extra procedure is detailed. If the packages are being constantly updated, and a library (a dependency of package foo, which I package) is changed so that it is no longer link-compatable with foo, I have to rebuild and upload foo. While this would not normally be a problem, say I'm working on foo2 in the devel branch. With Debian's current stable / unstable, I only have to worry about building packages against unstable (while I'm adding more features, fixing bugs, etc.). With production / devel, I would need to track two branches. As it is now, I can pretty much leave foo in stable and not touch it (unless someone discovers security problems, etc.). This message wasn't really intended as a critique of your idea, Jacob. Rather, I wanted to take a little time to ask the Debian community to pay attention to what the FreeBSD guys do with their distributions. Please don't immitate FreeBSD's release practices. The FreeBSD guys tag a release RELEASE when they feel it's ready for lots of people to download, compile, and use. The RELEASE branch is usually of very high quality, but like all software, it has problems. Instead of continually releasing new RELEASE branches, they have a CURRENT branch of their distribution. This branch is the RELEASE branch plus fixes to things that had problems in the original release. So far, this plan works very well. Now comes the tricky part. FreeBSD offers a STABLE branch which is usually anything BUT stable. I followed this branch on two machines (just a few months ago), and I was subscribed to the STABLE mailing lists. STABLE is similar to what Jacob calls production. The FreeBSD handbook (at http://www.freebsd.org/handbook/stable.html): If you are a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking stable. This is especially true if you have installed the most recent release (3.4-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release. STABLE breaks just about every day (a cvsup to their source trees and a make world will fail). Sometimes you can build a kernel that does very odd things (a friend of mine built a STABLE kernel off the recent RELENG3 tree, and the first time his machines would run out of RAM, they would handle the situation (killing the offending process), but the second time, it refused to allow any more malloc() until the kernel gave out). Of course one could choose to not continually update and build from the STABLE tree, but then what's the use of having updated code? Picking on FreeBSD's kernel probably isn't the best way to make a point about Debian's packaging policies, so here's my simple suggestion: Keep the stable and unstable (with the frozen step towards releases), but release more often. A year between releases is very painful, when I need to install somewhat recent software on a new host. Maybe double the release rate (aim for once every 6 months)? -- Shaw Terwilliger
Re: A progressive distribution
I really don't think that a progressive branch is necessary. The problems involved in keeping track of three branches at one time and trying to keep version dependencies in order between branches would far out weigh any benefit that would be created by such a branch. IMHO the structure (stable, frozen, unstable) is more than adequate. The problem that I see is that there is too much time between stable releases. I think that shorter and much more regular time periods between freezes is necessary. By fixing the number and date of freezes, with say three or four a year, and letting everyone know long in advance of the freeze it would allow developers to schedule when all bugs must be removed by. Also the fact that the time period would be much shorter would make changes between stable versions less drastic and therefore easier to handle. Ed Bernhard R. Link wrote: After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. As I understood the problem, at the moment, only the stable distribution is able to be distributed, while the unstable branch is to unstable and there's no distrubution in between. (To simplify I count the frozen as stable short before release here.) When potate becomes stable, a branch called e.g. progressive could be created between the branches stable and unstable. This branch (sorry for using this term, but I don't like distribution so much) would start with the modules from stable and subsets of unstable would be added, if they are usable. The term subset I use for packages that contain together like one ore more basis packages (libc,xfree,perl,... or just something like emacs) and those packages depending on this basis package. (Note that I mean basis as basis of dependencies not basis of the whole or larger parts of distribution) And usable shell mean, that this package can be used for average use without the need of Debian-like-tability. With the next freeze, this progressive branch could be copied to froozen and new useable packaged from unstable would go to progressive, while those in frozen are kept and only made more stable. Doing this there would be a distribution in between, where new versions of products can reside and easily be used. Someone should be easily use a snapshot of progressive at an good moment to form a not-so-stable but up-to-date unofficial release, which could also be called less inoffical, if there is a common will for this. Though some advantages this would cause at least two problems: On the one hand this proposal would prohibit the current way of naming, because with any release a new distribution is created beetween stable and unstable, so some branch would change name and the old name would be used for a possibly totally other branch. So unstable( and perhaps progressive) had to be without name and just be unstable. This coresponds to the loss of a cycle for the whole distribution. Changes would start in unstable and go through the phases of unstable, progessive and froozen before they become stable. On the other hand would this proposal multiply the number of branches to up to four when there will be the next freeze and stable,frozen,progressive and unstable beeing all together. This made me the most headacke, but I think it's not so much of a problem, as many work to make the frozen version of his package will seriously prevent him from working so much on the unstable version, that this could become usable. So most packages would be either the same in frozen and progressive or they would be same in progressive and unstable. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A progressive distribution
On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote: The problem that I see is that there is too much time between stable releases. I think that shorter and much more regular time periods between freezes is necessary. By fixing the number and date of freezes, with say three or four a year, and letting everyone know long in advance of the freeze it would allow developers to schedule when all bugs must be removed by. Also the fact that the time period would be much shorter would make changes between stable versions less drastic and therefore easier to handle. How does this account for drastic changes to something like libc that might take weeks or months to shake out? -- Mike Stone pgpYZCckGUTEe.pgp Description: PGP signature
Re: A progressive distribution
On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote: try this hypothetical release method out: there are two trees. let's call them devel and production. debian saavy folks (maintainers) run devel. new packages are uploaded to devel where they are tested extensivly. when a package has been in devel for more than (for instance) two weeks, and it has no release critical and few important bugs, it graduates into production. the production branch should always work. But it won't. This approach ignores the fact that stability is a property of a release as a whole (the set of packages and their interdependencies, ISOs, boot floppies and the upgrade path from the previous release) rather than the sum of the stability of individual packages. Ray -- ART A friend of mine in Tulsa, Okla., when I was about eleven years old. I'd be interested to hear from him. There are so many pseudos around taking his name in vain. - The Hipcrime Vocab by Chad C. Mulligan
Re: A progressive distribution
On Wed, 15 Mar 2000, J.H.M. Dassen (Ray) wrote: But it won't. This approach ignores the fact that stability is a property of a release as a whole (the set of packages and their interdependencies, ISOs, boot floppies and the upgrade path from the previous release) rather than the sum of the stability of individual packages. A possibly naive question: apt-get will refuse to install packages if their dependencies aren't met. Why can't dinstall do the same? It would put any newly uploaded package in a waiting queue until all its dependencies were met. It wouldn't help with out and out buggy programs but at least it would catch dependency problems. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: A progressive distribution
On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote: The problem that I see is that there is too much time between stable releases. I think that shorter and much more regular time periods between freezes is necessary. By fixing the number and date of freezes, with say three or four a year, and letting everyone know long in advance of the freeze it would allow developers to schedule when all bugs must be removed by. Also the fact that the time period would be much shorter would make changes between stable versions less drastic and therefore easier to handle. How does this account for drastic changes to something like libc that might take weeks or months to shake out? Well say that there are 3 releases a year. That gives say 3 months for devel. With a freeze scheduled to start at the beginning of the 4th month and a stable release at the end of a month of freeze. I think that even the most drastic changes can be worked out in the course of 4 months. Now if something _can't_ be completed in that time frame just postpone it until the next freeze. Since the next stable would only be 4 months off the penalty for not making it into the stable isn't that severe. With only the 3 months of changes I don't think that a freeze will take as long as it has with a 6 or even 12 month devel cycle. Ed
Re: A progressive distribution
On Wed, Mar 15, 2000 at 03:06:57PM -0500, Jaldhar H. Vyas wrote: On Wed, 15 Mar 2000, J.H.M. Dassen (Ray) wrote: But it won't. This approach ignores the fact that stability is a property of a release as a whole (the set of packages and their interdependencies, ISOs, boot floppies and the upgrade path from the previous release) rather than the sum of the stability of individual packages. A possibly naive question: apt-get will refuse to install packages if their dependencies aren't met. Why can't dinstall do the same? It would put any newly uploaded package in a waiting queue until all its dependencies were met. It wouldn't help with out and out buggy programs but at least it would catch dependency problems. Yes, such a queue was part of the incremental release process proposal (which people then told me shouldn't have been proposed, and is now being more-or-less implemented by someone with no developer feedback at all). It's not hard to implement. Search the archives for the proposal if you want details. []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the personal page Debian GNU/Linux---http://www.debian.org Brazil of Darkness--- http://zope.gf.com.br/BroDar
Re: A progressive distribution
On Wed, 15 Mar 2000, Ed Szynaka wrote: The problem that I see is that there is too much time between stable releases. I think that shorter and much more regular time periods between freezes is necessary. By fixing the number and date of freezes, with say three or four a year, and letting everyone know long in advance of the freeze it would allow developers to schedule when all bugs must be removed by. Also the fact that the time period would be much shorter would make changes between stable versions less drastic and therefore easier to handle. How does this account for drastic changes to something like libc that might take weeks or months to shake out? Build daemons could take care of the 90% or so of packages that would just need a recompile. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: A progressive distribution
On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote: On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote: How does this account for drastic changes to something like libc that might take weeks or months to shake out? Well say that there are 3 releases a year. That gives say 3 months for devel. With a freeze scheduled to start at the beginning of the 4th month and a stable release at the end of a month of freeze. I think that even the most drastic changes can be worked out in the course of 4 months. That assumes that the change is made at the beginning of the devel period. That never seems to happen. People *always* hold something until just before the freeze. Now if something _can't_ be completed in that time frame just postpone it until the next freeze. Once it's in, it seems to be really hard to remove/postpone it. If we change that, then releases will fall into place without discussions of arbitrary time cycles. If we don't change that, then the short cycles are no more enforcable than what we have now. Drawing up new plans without addressing the cultural issues behind this are a waste of time. (Does anyone remember pushing back the freeze because people wouldn't be able to work on it over the holidays? Does that seem like a good idea in hindsight?) -- Mike Stone pgpOCadJgU7k9.pgp Description: PGP signature
Re: A progressive distribution
On Wed, Mar 15, 2000 at 15:06:57 -0500, Jaldhar H. Vyas wrote: A possibly naive question: apt-get will refuse to install packages if their dependencies aren't met. Why can't dinstall do the same? It could do so. It wouldn't help with out and out buggy programs but at least it would catch dependency problems. It would catch problems with the dependencies a package declares. But it's no substitite for integration testing, part of which checks that the declared dependencies of a package accurately reflect the real dependencies. Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Re: A progressive distribution
On Wed, Mar 15, 2000 at 03:27:18PM -0500, Jaldhar H. Vyas wrote: On Wed, 15 Mar 2000, Ed Szynaka wrote: How does this account for drastic changes to something like libc that might take weeks or months to shake out? Build daemons could take care of the 90% or so of packages that would just need a recompile. That ignores the arguments over what needs to be recompiled, the time needed to discover problems, the time needed to make the compilations work, etc. Build daemons are not omnipotent. (Otherwise they'd be build deities...I digress.) -- Mike Stone pgpMr9JqgopLQ.pgp Description: PGP signature
Re: A progressive distribution
On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote: Well say that there are 3 releases a year. That gives say 3 months for devel. With a freeze scheduled to start at the beginning of the 4th month and a stable release at the end of a month of freeze. I think that even the most drastic changes can be worked out in the course of 4 months. Now if something _can't_ be completed in that time frame just postpone it until the next freeze. Since the next stable would only be 4 months off the penalty for not making it into the stable isn't that severe. I hate to be overly harsh, but you I haven't seen around much before this thread. As such, I'm going to assume that you haven't been around very long as far as following this list. Anybody who has been around awhile can tell you that people just like you (and even a large segment of the existing developer base) says every single release that we need to freeze sooner and release more often---however pools will only complicate things and make it harder. Well uh, here's where the above you don't know what you're talking about yet because you're still new angle comes in... We've tried it. We tried it with hamm, slink, and now with potato. Freeze as soon as someone thinks it can be released in a few weeks DOES NOT mean it can be done in a few weeks. Freeze early doesn't mean a sooner release, it just means a more stale release faster. The pool solution is more complex. It requires that we constantly maintain two trees, plus a pool of unstable packages that just never really get released as a whole. A package does not become a release candidate until it's ready to become so. Sure that means more overhead on a package to determine whether or not it is going to be released. It also makes it harder for Debian to ship with every single piece of free software that doesn't guaranteed pull the system down to its knees. It also means per developerer there is more time required to maintain ones packages properly (though I would argue that unless your name is Joey Hess the extra time required is not terribly significant.) What does this gain us though? For all these disadvantages, what's it really worth? A distribution that is maintained in the near-release state that we CAN simply release any time we feel it is necessary. It's also easier to update than the current system which involves releasing security revisions to stable. Not only this but it is easier to make upgrades because they would happen more often and be more upgrade than the current complete new OS scenerio. We're running out of options because freeze early doesn't work. The other two options are the dist and a half (which was done for slink by Joey Hess and Shaleh.) As it turns out, the pools system allows us to have more of a real upgrade. The dist and a half system allows us to have a more focused upgrade. Which is more beneficial to our users? Both can be done in a matter of a couple of weeks. Both are actual versioned releases. The pools have more overhead, but they provide a real upgrade rather than just the dist with a few big notables like kernel, X, and Apache. IMO, dist and a half is mostly fluff as far as press releases go. potato and a half would be a potato dist with a 2.4 kernel, possibly some new X stuff if it can be done and a new apache. It's still out of date potato otherwise. I want a REAL upgrade! With only the 3 months of changes I don't think that a freeze will take as long as it has with a 6 or even 12 month devel cycle. As I said, you haven't been around much yet have you? -- Joseph Carter [EMAIL PROTECTED] GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 First off - Quake is simply incredible. It lets you repeatedly kill your boss in the office without being arrested. :) -- Signal 11, in a slashdot comment
Re: A progressive distribution
On Wed, Mar 15, 2000 at 01:34:22PM -0500, Mark Mealman wrote: First things first. Let's get potato released, and then get pools and flavors implemented before we try to release woody. I'm all for that if you think the pools idea has any chance of being implented in our lifetime. I recall reading that it was being prototyped on lully...but lully is currently waiting for some replacement hardware. craig -- craig sanders
