Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Miguel A. Vallejo wrote: ... > I activelly follow the development of some programs in diverse areas > (ham radio, astronomy, emulators, etc), and new versions usually > appears in unstable months after release. The more prominent example > is the kernel itself. Current version is 5.5.7, but unstable still > have 5.4.19. When the statibily of your system depends on a feature or > bug solved in a new kernel version, this can be distressing. > > Even with all this, I still prefer to use Debian. these days so much is happening in other repositories that as much as possible for a project i want to follow closely i'll just fork it on github and pull it to my machine and use some form of an environment to localize the changes (putting in more paths to binaries/libraries, etc). i think a lot of what is packaged for debian is nice and i appreciate the efforts of the people who do it but with some code the developers have no idea of how to do things properly and they are messing up so i have no choice but to follow them (and regret it in one case because it's annoying to not have someone understand a cycle of development which involves ideas like stable vs. development and not introducing breaking changes too frequently - like every minor release...*sigh*). songbird
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
I have a friend who works as a system administrator that always says: Debian Stable --> Debian Server Debian Testing --> Debian Desktop Moderate Debian Unstable --> Debian Desktop Fast Being Moderate and Fast the speed at you will eat new bugs. As time goes by, I'm more and more agree with him. Debian Stable should be enough for everyone, but... in practice only works for servers and very low demanding desktops / workstations. if you use fast moving software (for example, ham radio applications), or developing new software, or helps developing new software, your only option is to run ahead to testing / unstable. Packages versions in Stable are obsolete even on the very same launch day. The developer puts a new version, you download the sources, try to compile them, compilation failed, asks the developer why and the answer is always the same: Your put_any_library_here version is obsolete, please upgrade. So you are forced to move to testing / unstable. Another case is if you suffer a serious bug with stable, usually hardware support. Then, also your only option is to run ahead to testing / unstable and cross your fingers. In my case, suffering the big problems with Intel video cards the only option is to move to unstable and pray for every new kernel to be the one that solves the problem. I've read there will be no chace to get a working kernel with Intel cards until next 5.7 so now I'm on stable, which seems to be somewhat stable (only one chrash in the last 7 days). I activelly follow the development of some programs in diverse areas (ham radio, astronomy, emulators, etc), and new versions usually appears in unstable months after release. The more prominent example is the kernel itself. Current version is 5.5.7, but unstable still have 5.4.19. When the statibily of your system depends on a feature or bug solved in a new kernel version, this can be distressing. Even with all this, I still prefer to use Debian.
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, Feb 25, 2020 at 06:48:21PM +0100, Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and of > course if I ever were to set up a server Debian would probably be my choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly > like distributions tied to or ultimately dependant on commercial entities (I > want a change of air after going through Ubuntu, openSUSE...) I recently made the move to Debian after being a Ubuntu user since 4.10 (first release). > I have also seen independent Debian derivatives (MX Linux comes to mind), but > they either used backports or the Testing distribution. > > I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Is it actually usable for a Workstation? The same > would A lot of people seem to be using Testing as such. > apply to Sid, I can no longer allow myself to fix big breakages after broken > updates (I don't know if that really happens often in Sid) I chose Debian Stable because I need to get work done and can't afford disruptions due to broken updates - I already have to deal with broken internet connectivity, ISP/institutional shenanigans from time to time. I kept my old Ubuntu LTS instance running while I setup Debian Stable with stuff that gave me the same functionality. I have customised my Stable instance with the software that is minimally resource intensive (no GNOME/KDE/XFCE). To make the decision easier: * When work is important stick with Debian Stable * HTH, Didar > Thanks, > Sam > > -- Somewhere in Tenafly, New Jersey, a chiropractor is viewing "Leave it to Beaver"!
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 09:30:36 -0500 Stefan Monnier wrote: > > Right. You can also use a CD based Linux such as finnix to shrink an > > existing LVM logical volume (LV), create a new LV for swap, and run > > mkswap to lay down a swap partition on it. > > BTW, you don't need a separate CD or anything like that: you can use > your initrd for that same purpose. I.e. at the Grub prompt, tell it > to boot with an argument like `break=local` (IIRC) and it should > (hopefully) drop you into a shell soon before mounting the root > file system. You can then use `lvm lvresize`. > > Bear in mind that LVM knows nothing of filesystems: before you shrink an LVM logical volume you need to shrink the filesystem that lives on it, and conversely if you enlarge the volume, you then need to enlarge the filesystem afterwards. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 08:54:02 +1100 Keith Bainbridge wrote: > > > I'm having trouble understanding how LVM snapshots works on / if it > is outside the LVM. > I don't think anyone has picked this up. Yes, you do need additional space. I've only done it a few times. It basically involves leaving enough unallocated space to accommodate whatever you want to do with the snapshot. What I used it for was on-line system backup. You can generally get away with just copying a Linux system while it is running, if not much is going on at the time, particularly if you temporarily stop SQL servers and the like. Various volatile files won't be consistent, being copied at different times, but if they are general housekeeping files which are constantly being re-written, then the contents won't matter much after a restore and reboot. Yes, some inconsistencies can be critical, and restoring it in full over your working system is a bit risky. Using it to restore individual files is generally safe, for most people a full restore from backup would be a last resort (OK, second last, just before reinstalling). But I've booted an online copy on another machine on several occasions without (as far as I know) any issues. If you want an absolutely consistent backup (e.g. copying to a bigger hard drive), you either shut down and take it with an external tool, or you can use LVM. When you enable the snapshot, the region of interest is frozen, further disc writes are basically done to a journal, not to the frozen region, and the journal is reconciled with its parent region when you close the snapshot. In the meantime, you can take a backup where no disc files will change while you're doing it. You need enough space for the snapshot to store everything that may written until you terminate the snapshot, but with modern discs you can generally allocate as much space as the largest region you want to back up, which is the safe option. Performance will be a bit reduced during the snapshot period, but that depends on what the system is being used for, how much writing is going on, and in any case a system backup itself will slow things down a lot. Windows Server partitions with Volume Shadow enabled do something like this continuously, managing daily snapshots and deleting old ones up to the limit of allocated space. Read the current docs for exact details of how to do this. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
> Right. You can also use a CD based Linux such as finnix to shrink an > existing LVM logical volume (LV), create a new LV for swap, and run > mkswap to lay down a swap partition on it. BTW, you don't need a separate CD or anything like that: you can use your initrd for that same purpose. I.e. at the Grub prompt, tell it to boot with an argument like `break=local` (IIRC) and it should (hopefully) drop you into a shell soon before mounting the root file system. You can then use `lvm lvresize`. Stefan
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 11:43:42 +1100 Keith Bainbridge wrote: > OK I am in the process of install debian in vbox. It set up LVM > using the whole partition, and allowed several logical volumes. > > Am I safe to believe that this is what will happen with a SSD when I > start? Yes. > > I got a prompt that I didn't set a swap partition. I ignored that for > now, but will have to remember when I do the real thing. Right. You can also use a CD based Linux such as finnix to shrink an existing LVM logical volume (LV), create a new LV for swap, and run mkswap to lay down a swap partition on it. See https://www.thegeekdiary.com/how-to-add-swap-space-in-linux/ Or just use mkswap to create a swap file. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 08:59:55 + Brad Rogers wrote: > On Wed, 26 Feb 2020 19:47:35 -0600 > John Hasler wrote: > > Hello John, > > >blindly upgrading nightly causes far more problems than it solves. > > Because that's what gets asked about. Nobody posts saying; > > "I updated lasted night, and everything worked!" > > There's no point. > > However, I do recognise that you wrote 'blindly' and there, you're > right. > I've found it rare for an upgrade to break anything, and if it does, I have more than one computer. What is fairly common is that the upgrade of a large system such as KDE or Qt takes place over a period of time, making upgrading tedious for a week or two. A couple of weeks ago, I had over 400 packages held up by a dependency on one new (and buggy) library. But that's about as bad as it gets. The last time I reinstalled sid was several years ago, on a mobile that I don't upgrade often, and aptitude and apt-get both choked on about a gigabyte of upgrades. The time before that must have been more than fifteen years ago, when a damaged perl upgrade stopped the package tools, even dpkg, from working, and it was beyond my abilities to fix manually. But generally, if the apt tools still work, it's fixable, and it's pretty rare for anything to need fixing. If there is a breakage, the quick answer is to go back to the previous version if it's in the cache, if it's not it can be found on the Net, or if it's not a show-stopper, wait for it to be fixed. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Wed, 26 Feb 2020 19:47:35 -0600 John Hasler wrote: > Andrei writes: > > An entire month without security updates is not the best idea in my > > opinion. > > It appears to me from watching this list that the practice of > blindly upgrading nightly causes far more problems than it solves. As I am not an IT professional or systems programmer, I can't be of much help in building Debian. But I can see bugs as easily as the next user, and I can do basic troubleshooting. So I do fully upgrade sid almost every day, and have contributed a number of bug reports. It's actually quite difficult to be the first, but I can sometimes add a data point. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Wed, 26 Feb 2020 19:47:35 -0600 John Hasler wrote: Hello John, >blindly upgrading nightly causes far more problems than it solves. Because that's what gets asked about. Nobody posts saying; "I updated lasted night, and everything worked!" There's no point. However, I do recognise that you wrote 'blindly' and there, you're right. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I am alone there's nobody there I Look Alone - Buzzcocks pgpnPV6rF3H7G.pgp Description: OpenPGP digital signature
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Brad writes: > I update daily, but 'cherry pick' in the event of transitions that > _might_ have repercussions. So you *don't* "track" testing by doing automatic full upgrades every day. That is the practice that I'm arguing against. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Andrei writes: > An entire month without security updates is not the best idea in my > opinion. I follow the security list and do security updates as required, of course. Those rarely (if ever) require full upgrades. There is no need to do daily full upgrades just to stay up with security. > Additionally after a month the upgrade can become quite complex with a > lot more moving parts, i.e. it will be difficult to tell what broke. I haven't found it so, but then, as I noted, I run neither KDE nor Gnome. It appears to me from watching this list that the practice of blindly upgrading nightly causes far more problems than it solves. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 27/2/20 8:54 am, Keith Bainbridge wrote: Thanks for the positive responses. I am interested now because I am about to buy a new drive. I guess the answer to these will be obvious when I choose LVM at the disk selection stage, but do I need to keep system partitions separate? as I install the 2nd & 3rd install? OK I am in the process of install debian in vbox. It set up LVM using the whole partition, and allowed several logical volumes. Am I safe to believe that this is what will happen with a SSD when I start? I got a prompt that I didn't set a swap partition. I ignored that for now, but will have to remember when I do the real thing. System is running well, though. Further changes tonight -- Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 27/2/20 3:46 am, Charles Curley wrote: On Thu, 27 Feb 2020 00:15:44 +1100 Keith Bainbridge wrote: Is LVM viable? I can see the benefit of re-sizing on the fly. I use multi-boot. I can see the possibility of /dev/sda1 and LVM using the rest. But is it viable, please? Yes, it is viable. I use an encrypted partition with LVM on it to hold everything except /boot on laptops, desktops, and headerless servers. That works well for me. However, I set it up at installation time. Since I have never set up an Rpi, I have no idea whether you can do it on one. Be sure to back up /etc/lvm/ in case the LVM headder gets clobbered. I've had no problem with that for more than ten years, but you never know... Thanks for the positive responses. I am interested now because I am about to buy a new drive. I guess the answer to these will be obvious when I choose LVM at the disk selection stage, but do I need to keep system partitions separate? as I install the 2nd & 3rd install? It seems I'd be wise to create several smallish virtual partitions and add them to my 'work area' as I need them. Amongst other quirks, I have taken up the practice of having a small /home partition for each OS, and sym-linking all data type directories from a bulk partition. I've been using /mnt/data but I saw /data a couple of times last night. I'm having trouble understanding how LVM snapshots works on / if it is outside the LVM. -- Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, 25 Feb 2020 19:18:10 -0600 John Hasler wrote: Hello John, >*Don't* "track" Testing or Unstable by upgrading nightly. I'm with songbird (and others). It can be done, with care; I subscribe to the 'Testing Changes' mailing list. I subscribe to the 'Debian Developers' mailing list. I subscribe to the 'Debian KDE' mailing list. I update daily, but 'cherry pick' in the event of transitions that _might_ have repercussions. By reading, or at least scanning, those lists, I can update fairly safely. I only came unstuck once, and that simply resulted in me having to enter a password twice at a login prompt. A situation that was rectified a couple of days later when KDM (as was in use at the time) got updated. I considered upgrading to sid, but decided against it because I'm far from knowledgeable enough to sort problems out myself, should they arise. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" You're all invited to a party, you don't even have to come Get The Funk Out - Extreme pgpbC1TUGLR1l.pgp Description: OpenPGP digital signature
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 00:15:44 +1100 Keith Bainbridge wrote: > Is LVM viable? I can see the benefit of re-sizing on the fly. I use > multi-boot. I can see the possibility of /dev/sda1 and LVM using the > rest. But is it viable, please? Yes, it is viable. I use an encrypted partition with LVM on it to hold everything except /boot on laptops, desktops, and headerless servers. That works well for me. However, I set it up at installation time. Since I have never set up an Rpi, I have no idea whether you can do it on one. Be sure to back up /etc/lvm/ in case the LVM headder gets clobbered. I've had no problem with that for more than ten years, but you never know... -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
John Hasler wrote: ... > *Don't* "track" Testing or Unstable by upgrading nightly. I don't > understand why people want to do this. A full upgrade (after a test > upgrade) about once a month is plenty. different people have different purposes. :) my reasons for my morning routine is to determine what is being changed or worked on in the packages that i use/have on this machine. most days i scan the proposed updates and see that they are things i don't mind if they get updated. they're not too likely to impact the few things i do the most. so for me to just get them updated means the next time i do use them i will either help with the testing part or more likely i won't notice any difference at all. which is good. if i do see a bug and have the time to report it then i've done what i consider part of my giving back to the developers and users of the same code base. they can at least be aware that somewhere ahead "There May Be Dragons!" having a nice running computer system that does what i want and expect is my goal. to do that at times means i can't always keep exactly up to date so i will put some updates on hold until i have a bit more time to investigate or ask questions or file bugs or ... > If you have packages you need to have the current release of wait until > they've been available for a week or so without serious or important > bugs that would matter to you. Then do a test upgrade so that you can > decide whether you can go right ahead, have to do a full upgrade to make > it work, or perhaps should wait a bit. yes, if something looks very intrusive to the basic packages i use every day i try to make sure i have time set aside to make sure it all goes as expected. most often in the past that has meant 99.99% of the time that i don't have any problems at all. once in a while "stuff happens[tm]" and having a booting stable set up is sufficient for me to get what i need done accomplished. > I've been doing this with Unstable for most of this century with very > few problems (and none recently). > > And a caveat: I don't use either Gnome or KDE. ditto. they kept changing in ways that got in the way of my workflows/habits/expectations. songbird
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Hi. On Thu, Feb 27, 2020 at 12:15:44AM +1100, Keith Bainbridge wrote: > Is LVM viable? I can see the benefit of re-sizing on the fly. I use > multi-boot. I can see the possibility of /dev/sda1 and LVM using the rest. > But is it viable, please? Yes. LVM does not care if your drive was detected as /dev/sda, /dev/sdb or /dev/somethingelse. It'll work regardless. Reco
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Further to lvm snapshots, I have read about 10 articles explaining the concept of LVM and how to set them up. All of them talk about using /dev/sdb, c, d or more for LVM. None uses /dev/sda I am running a laptop and raspberry pi's, all with only 1 prime 'disk' and USB attached disks/sticks. Is LVM viable? I can see the benefit of re-sizing on the fly. I use multi-boot. I can see the possibility of /dev/sda1 and LVM using the rest. But is it viable, please? Keith BAINBRIDGE keithr...@gmail.com +61447 667 468 Sent from my Apad On Wed., 26 Feb. 2020, 16:42 Keith Bainbridge, wrote: > On 26/2/20 10:59 am, Stefan Monnier wrote: > > LVM snapshots > > I use timeshift for the same purpose; and have needed it a couple of > times over 14 months since switching from mint. > > I look at what packages are to be upgraged, and if more than a few > libraries, I create a new timeshift first. Usually adds about a minute > to the upgrade. > > > I am about to look into LVM snapshots NOW, though. > > -- > Keith Bainbridge > > keith.bainbridge.3...@gmail.com > +61 (0)447 667 468 >
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 2020-02-26, Andrei POPESCU wrote: > > Debian testing already has checks and delays in place to filter out > (most of the) problems. Updates fixing security issues are prioritised. I used testing once; I found 'apt-listbugs' to be quite helpful in obviating potential disaster (it was invariably only a question of waiting a day or two for things applicable to my installation to be fixed). >> I've been doing this with Unstable for most of this century with very >> few problems (and none recently). > > In both cases (testing and unstable), if the system is in any way=20 > exposed to security threats updating more often than that would be a=20 > good idea. > > Kind regards, > Andrei > http://wiki.debian.org/FAQsFromDebianUser > -- "J'ai pour me guérir du jugement des autres toute la distance qui me sépare de moi." Antonin Artaud
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Ma, 25 feb 20, 19:18:10, John Hasler wrote: > Sam writes: > > I will give Testing a spin and will definitely take another look at > > the Debian derivatives. You also made me admire the Debian community, > > so that's a big plus on the > > reasons-why-I-definitely-need-to-switch-to-Debian list :) > > A couple of suggestions if you decide to use Testing or Unstable. > > Subscribe to the debian-devel list and scan the subject lines often > enough to be aware of upcoming transitions that might affect you or > kerfuffles that might make you want to delay upgrading until they are > resolved. This doesn't really take much time. > > *Don't* "track" Testing or Unstable by upgrading nightly. I don't > understand why people want to do this. A full upgrade (after a test > upgrade) about once a month is plenty. An entire month without security updates is not the best idea in my opinion. Additionally after a month the upgrade can become quite complex with a lot more moving parts, i.e. it will be difficult to tell what broke. Just don't do upgrades right before important deadlines, events, presentations, etc. Otherwise upgrading every few days up to a week ensures that your system is reasonably up to date (security) and the upgrades are not too complex. > If you have packages you need to have the current release of wait until > they've been available for a week or so without serious or important > bugs that would matter to you. Then do a test upgrade so that you can > decide whether you can go right ahead, have to do a full upgrade to make > it work, or perhaps should wait a bit. Debian testing already has checks and delays in place to filter out (most of the) problems. Updates fixing security issues are prioritised. > I've been doing this with Unstable for most of this century with very > few problems (and none recently). In both cases (testing and unstable), if the system is in any way exposed to security threats updating more often than that would be a good idea. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 26/2/20 10:59 am, Stefan Monnier wrote: LVM snapshots I use timeshift for the same purpose; and have needed it a couple of times over 14 months since switching from mint. I look at what packages are to be upgraged, and if more than a few libraries, I create a new timeshift first. Usually adds about a minute to the upgrade. I am about to look into LVM snapshots NOW, though. -- Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Sam writes: > I will give Testing a spin and will definitely take another look at > the Debian derivatives. You also made me admire the Debian community, > so that's a big plus on the > reasons-why-I-definitely-need-to-switch-to-Debian list :) A couple of suggestions if you decide to use Testing or Unstable. Subscribe to the debian-devel list and scan the subject lines often enough to be aware of upcoming transitions that might affect you or kerfuffles that might make you want to delay upgrading until they are resolved. This doesn't really take much time. *Don't* "track" Testing or Unstable by upgrading nightly. I don't understand why people want to do this. A full upgrade (after a test upgrade) about once a month is plenty. If you have packages you need to have the current release of wait until they've been available for a week or so without serious or important bugs that would matter to you. Then do a test upgrade so that you can decide whether you can go right ahead, have to do a full upgrade to make it work, or perhaps should wait a bit. I've been doing this with Unstable for most of this century with very few problems (and none recently). And a caveat: I don't use either Gnome or KDE. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
> I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Other tools you can use: LVM snapshots. Take a snapshot before updating to testing/unstable, so you can easily revert if you don't like the result. I've used that for my machines running stable but where some (typically hardware, usually graphics-related) bug/regression shows up. Stefan
Re: Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Thank you very much for the tips! I will give Testing a spin and will definitely take another look at the Debian derivatives. You also made me admire the Debian community, so that's a big plus on the reasons-why-I-definitely-need-to-switch-to-Debian list :) Thank you, Sam
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Peter Ehlert wrote: > I think Debian Testing would fit you very well > It is like a rock, honestly. that hasn't been my experience, but i know what i'm doing well enough to fix things or to ask for help here if i find something i don't understand well enough. i got bit by some kind of lightdm transition or update and then before when system[-x] came along i had a failure during that which was not easy enough to solve as i did not have any exposure to system[-x] to that point. as i am here now and all is working ok i'm happy. debian does rock. :) thanks to the people who volunteer and do the work and answer questions and fix bugs. :) songbird
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Roberto writes: > On strategy would be to run testing and not update too frequently. I do that with Unstable. Works fine (but I use neither Gnome nor KDE) I follow the security list and upgrade the relevant package when I see something there that matters to me. Security fixes reach Unstable as fast or faster than they reach Stable and often aren't even relevant to Unstable since it is likely to have the newest release (which is where upstream usually fixes security bugs). I also scan debian-devel to keep any eye out for problems that might be a reason *not* to upgrade. Those have been very rare in recent years. I often update packages rather than doing a full upgrade. I always do a test update or upgrade and review the proposed changes looking closely at any proposed removals. Often when Apt can't find a workable update or upgrade path Aptitude can. Might be nice if there was a Debian deriviative based on this policy. Perhaps there is. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
I think Debian Testing would fit you very well It is like a rock, honestly. == I demand stability. My machines Must work 24/7 without intervention. for this reason I do have Debian Stable installed and operational on all machines (Mate desktop). However, on the other hand I love Mate, and the continuing new features... and we don't get them in Stable. And I am impatient and want the Latest And Greatest shiny new things in Mate!!! My solution: I keep a Debian Sid Mate (unstable) as default on on several machines, and I update daily +/- In my experience, IF there is something buggy in Sid, it gets patched withing 12 hours, maybe as long as 24. AND, I can just reboot to Stable and got to work without any issues. My Wife is kinda a "Luddite that uses computers" so she has Debian Mate Stable... and I update it for her on occasion (days, weeks sometimes) and she is happy. Happy Spouse = Happy Me. Same for the office computers: the have Only Stable installed. Mind that all of my hardware is several years old at a minimum, so having the bleeding edge gizmos is a non issue (and Mate is always in a Stable condition, that team is aces!) On 2/25/20 7:55 AM, Sam wrote: Hello, I would like to hear opinions about the release cycle of the Stable Debian releases for a Desktop user. I love the Debian ideals and perks (its social contract, independence from big companies...) and understand to a certain extent the fundamentals on why keeping "old-ish" versions of packages with backports and the Shiny new stuff syndrome, but I fail to see how Debian can make a useful desktop distribution with the current release cycle. For example: My main PC is an already two years old ryzen-based system and a Vega graphics card from 2017, and the kernel used in Stable has regressions which cause complete, unrecoverable system hangups on Vega cards which were not alleviated until kernel 5.3 onwards (and they still keep happening, though rarely!). This means that to ensure stability on a Debian installation I would need a backported kernel, or use Debian Testing or Sid, which IMO collides with the point of a Stable release. I also see everyday many announcements about performance (GNOME) and usability (KDE Plasma) improvements which are not exactly new features. This is obviously happening on more recent releases, which Debian may not see (unless these changes are also backported, which I would find extremely cumbersome?) until approximately two years have passed since that. All this makes me think that while Debian is a fantastic distribution, its Desktop, common user-facing side of things would greatly benefit from something like a separate yearly Stable release. Thanks, Sam
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Sam wrote: > Hello, > > I would like to hear opinions about the release cycle of the Stable Debian > releases for a Desktop user. > > I love the Debian ideals and perks (its social contract, independence from > big > companies...) and understand to a certain extent the fundamentals on why > keeping "old-ish" versions of packages with backports and the Shiny new stuff > syndrome, but I fail to see how Debian can make a useful desktop distribution > with the current release cycle. > > For example: My main PC is an already two years old ryzen-based system and a > Vega graphics card from 2017, and the kernel used in Stable has regressions > which cause complete, unrecoverable system hangups on Vega cards which were > not alleviated until kernel 5.3 onwards (and they still keep happening, > though > rarely!). This means that to ensure stability on a Debian installation I > would > need a backported kernel, or use Debian Testing or Sid, which IMO collides > with the point of a Stable release. > > I also see everyday many announcements about performance (GNOME) and > usability > (KDE Plasma) improvements which are not exactly new features. This is > obviously happening on more recent releases, which Debian may not see (unless > these changes are also backported, which I would find extremely cumbersome?) > until approximately two years have passed since that. > > All this makes me think that while Debian is a fantastic distribution, its > Desktop, common user-facing side of things would greatly benefit from > something like a separate yearly Stable release. for those who are willing to put some time into understanding how debian works, running debian testing and/or bits of unstable can be an acceptable risk. i do not recommend this to just anyone though as once in a while you may have something break. this is why i also have a separate stable partition for those rare times when i need it. the main issue with running from testing is that during the freeze running up to the stable release the packages allowed into testing may pause enough that you aren't being kept as current as you'd otherwise like. so during that time i might pull some things in from unstable as needed. i don't do this on many things and i'm trying to be careful about how many and what so i know what is going on. mainly i like to keep up with the most recent firefox releases. running etckeeper and git on a system can find out all sorts of interesting things. :) my other philosophical remarks would be an aside so i will leave them off. songbird
Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
I install testing on all my machines*. It is very usable. Sid has given me problems in the past, so I stay clear. *While it is true I install testing, I should clarify that I continue to use it as it moves into stable and then old-stable. Eventually, I hit some kind of "you can't get there from here" state with apt, at which point I install testing again. John Cunningham On Tue, Feb 25, 2020 at 1:06 PM Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and > of > course if I ever were to set up a server Debian would probably be my > choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't > exactly > like distributions tied to or ultimately dependant on commercial entities > (I > want a change of air after going through Ubuntu, openSUSE...) > > I have also seen independent Debian derivatives (MX Linux comes to mind), > but > they either used backports or the Testing distribution. > > I would happily consider using Debian Testing for example, but wherever I > see > someone asking about it I always find someone discouraging from using it > due > to the possibility of having broken or unsecure packages for a long time > due > to it being automated. Is it actually usable for a Workstation? The same > would > apply to Sid, I can no longer allow myself to fix big breakages after > broken > updates (I don't know if that really happens often in Sid) > > Thanks, > Sam > > >
Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, Feb 25, 2020 at 06:48:21PM +0100, Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and of > course if I ever were to set up a server Debian would probably be my choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly > like distributions tied to or ultimately dependant on commercial entities (I > want a change of air after going through Ubuntu, openSUSE...) > > I have also seen independent Debian derivatives (MX Linux comes to mind), but > they either used backports or the Testing distribution. > There are literally dozens (hundreds?) of Debian derivatives out there. You might find that one or another suits your needs better than the rest: https://wiki.debian.org/Derivatives/Census > I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Is it actually usable for a Workstation? The same > would > apply to Sid, I can no longer allow myself to fix big breakages after broken > updates (I don't know if that really happens often in Sid) > On strategy would be to run testing and not update too frequently. The important thing there would be to monitor the -user and -devel mailing lists to ensure that when you do update it isn't in the middle of a known "trouble spot". The trade there is that you must invest the effort in keeping up with what is going on at a fairly low level and you won't be getting timely security support. The approach that I take is to run stable on my workstations/laptops and then use chroots, containers, and/or VMs for when I need a "newer" environment. For instance, I need to run the lintian utility on my packages before I upload them to the Debian archive. For this to be a useful check it must be performed with the latest lintian from unstable. I have an unstable chroot environment which has (among other things) lintian installed in it at the latest available version so that I have it always available when I need it. If the environment breaks because of a bad update or bug in a package or whatever, I have others that I can use instead. For containers and VMs, taking a snapshot before upgrading to allow roll-back is trivially easy. Something similar may work for you. Regards, -Roberto -- Roberto C. Sánchez
Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Thanks for your points of view! I agree that Stable comes at a cost, and of course if I ever were to set up a server Debian would probably be my choice. Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly like distributions tied to or ultimately dependant on commercial entities (I want a change of air after going through Ubuntu, openSUSE...) I have also seen independent Debian derivatives (MX Linux comes to mind), but they either used backports or the Testing distribution. I would happily consider using Debian Testing for example, but wherever I see someone asking about it I always find someone discouraging from using it due to the possibility of having broken or unsecure packages for a long time due to it being automated. Is it actually usable for a Workstation? The same would apply to Sid, I can no longer allow myself to fix big breakages after broken updates (I don't know if that really happens often in Sid) Thanks, Sam
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, 25 Feb 2020 16:55:46 +0100 Sam wrote: > Hello, > > I would like to hear opinions about the release cycle of the Stable > Debian releases for a Desktop user. > > I love the Debian ideals and perks (its social contract, independence > from big companies...) and understand to a certain extent the > fundamentals on why keeping "old-ish" versions of packages with > backports and the Shiny new stuff syndrome, but I fail to see how > Debian can make a useful desktop distribution with the current > release cycle. > > For example: My main PC is an already two years old ryzen-based > system and a Vega graphics card from 2017, and the kernel used in > Stable has regressions which cause complete, unrecoverable system > hangups on Vega cards which were not alleviated until kernel 5.3 > onwards (and they still keep happening, though rarely!). This means > that to ensure stability on a Debian installation I would need a > backported kernel, or use Debian Testing or Sid, which IMO collides > with the point of a Stable release. > > I also see everyday many announcements about performance (GNOME) and > usability (KDE Plasma) improvements which are not exactly new > features. This is obviously happening on more recent releases, which > Debian may not see (unless these changes are also backported, which I > would find extremely cumbersome?) until approximately two years have > passed since that. > > All this makes me think that while Debian is a fantastic > distribution, its Desktop, common user-facing side of things would > greatly benefit from something like a separate yearly Stable release. > Software is always a trade-off between age and stability. If you want new software, you must accept that it will have more bugs than older software (providing it is widely used, and people report bugs). Some of these bugs will have security implications. After Debian Testing is frozen, it undergoes six months of concerted efforts to fix the bugs. But six months out of every year would mean the developers not doing all that much development. After release, only security bugs (pretty much) get fixed. Until the freeze, Testing is only about two weeks behind Unstable, so if you want the latest software, you could choose either, after the freeze, Testing will obviously fall further behind. Testing is generally a little less buggy than Unstable. I use both options: Stable for my server and netbook, Unstable for my workstation. I don't use Gnome or KDE desktops anywhere (though I use a few of their applications), I use Xfce on netbook and workstation, command line on the server. I'm really not bothered about whizzy window animations and other special effects. The applications run the same whatever the desktop, in fact a little bit quicker if you don't waste resources on visual gimmicks. Finally, the unique selling point of Debian Stable is that you can *always* do an in-place upgrade of one version to the next. That means a lot to people running servers, though they also like that their automation scripts don't break after routine upgrades. Windows hasn't done major version upgrades since Win 2000, (except the trivial 8/8a/10 upgrades) and I don't think many other Linux distributions offer it. It was originally hoped to release at one-year intervals, and the current roughly two-year interval is not set in stone, it's just the way things have worked out. It seems to be a good ratio of development time to bug-fixing time. Given a large number of new (unpaid) developers, the cycle could be faster. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, Feb 25, 2020 at 04:55:46PM +0100, Sam wrote: > Hello, > > I would like to hear opinions about the release cycle of the Stable Debian > releases for a Desktop user. > > I love the Debian ideals and perks (its social contract, independence from > big > companies...) and understand to a certain extent the fundamentals on why > keeping "old-ish" versions of packages with backports and the Shiny new stuff > syndrome, but I fail to see how Debian can make a useful desktop distribution > with the current release cycle. > Debian's stable release does make a useful desktop distribution. I use it on every single one of my laptops/desktops. That said, your definition of "useful" may differ from mine. Though, on my current "main" laptop I had to run Debian testing at first because of the hardware support I needed from the newer kernel. > For example: My main PC is an already two years old ryzen-based system and a > Vega graphics card from 2017, and the kernel used in Stable has regressions > which cause complete, unrecoverable system hangups on Vega cards which were > not alleviated until kernel 5.3 onwards (and they still keep happening, > though > rarely!). This means that to ensure stability on a Debian installation I > would > need a backported kernel, or use Debian Testing or Sid, which IMO collides > with the point of a Stable release. > > I also see everyday many announcements about performance (GNOME) and > usability > (KDE Plasma) improvements which are not exactly new features. This is > obviously happening on more recent releases, which Debian may not see (unless > these changes are also backported, which I would find extremely cumbersome?) > until approximately two years have passed since that. > > All this makes me think that while Debian is a fantastic distribution, its > Desktop, common user-facing side of things would greatly benefit from > something like a separate yearly Stable release. > I am not sure what you are getting at. Gnome and KDE are notoriously complex and extraordinarily difficult to integrate. That integration happens in unstable and testing. The fact remains that you have two basic choices. If you must have the "latest and greatest" features, hardware support, etc., then you are better off with testing/unstable. If you can do without those things or if timely security support is more important to you than those things, then you are better off with Debian stable. Also, for administrators of large collections of systems (e.g., workstations across and enterprise, data centers, server farms, etc.) too much change too often is a major pain. Those wanting more change more often can easily switch to testing and/or unstable. But if the main stable distribution changes too often, that makes it difficult for those who need a slower rate of change. By the way, there are also lots of Debian derivatives (like Linux Mint, Ubuntu, and so on) which may be more what you are looking for in terms of meeting your specific needs. Have you considered any alternatives? Regards, -Roberto -- Roberto C. Sánchez
Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Hello, I would like to hear opinions about the release cycle of the Stable Debian releases for a Desktop user. I love the Debian ideals and perks (its social contract, independence from big companies...) and understand to a certain extent the fundamentals on why keeping "old-ish" versions of packages with backports and the Shiny new stuff syndrome, but I fail to see how Debian can make a useful desktop distribution with the current release cycle. For example: My main PC is an already two years old ryzen-based system and a Vega graphics card from 2017, and the kernel used in Stable has regressions which cause complete, unrecoverable system hangups on Vega cards which were not alleviated until kernel 5.3 onwards (and they still keep happening, though rarely!). This means that to ensure stability on a Debian installation I would need a backported kernel, or use Debian Testing or Sid, which IMO collides with the point of a Stable release. I also see everyday many announcements about performance (GNOME) and usability (KDE Plasma) improvements which are not exactly new features. This is obviously happening on more recent releases, which Debian may not see (unless these changes are also backported, which I would find extremely cumbersome?) until approximately two years have passed since that. All this makes me think that while Debian is a fantastic distribution, its Desktop, common user-facing side of things would greatly benefit from something like a separate yearly Stable release. Thanks, Sam
Re: Release Cycle
David Jardine wrote: On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote: Barclay, Daniel wrote: ... Well, maybe I'll prove to be understanding neither of you, but the point seems to be that you can't 'force' the maturity of a package. I wasn't talking about trying to force the maturation of any changes to go faster; I just meant dividing the changes into two (or however many) groups so the first group could be implemented, matured and released before the second group got started. That shouldn't increase the _explicit_ development, testing, and fixing effort required. (Of course, as I said, there is also the additional (presumably significant) overhead of making and tracking an additional release in the middle.) On the other hand, that division admittedly does reduce the _time_ during which a change group is implicitly tested by being used. (Instead of having both sets of changes being tested for duration D, each gets tested for only duration D/2). So I guess that question is how significant that testing duration is (compared to the number of people implicitly testing, etc.). Halving the seed rate in a field of wheat won't make the wheat ripen twice as fast. But breaking an ice cube in half does help it melt faster. The question is which analogy is actually ... um ... analogous (or, probably more accurately, how much each applies to this case). Daniel -- (Plain text sometimes corrupted to HTML courtesy of Microsoft Exchange.) [F]
Re: Release Cycle
On Tue, Feb 3, 2009 at 6:24 PM, Barclay, Daniel dan...@fgm.com wrote: David Jardine wrote: On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote: Barclay, Daniel wrote: ... Well, maybe I'll prove to be understanding neither of you, but the point seems to be that you can't 'force' the maturity of a package. I wasn't talking about trying to force the maturation of any changes to go faster; I just meant dividing the changes into two (or however many) groups so the first group could be implemented, matured and released before the second group got started. That shouldn't increase the _explicit_ development, testing, and fixing effort required. (Of course, as I said, there is also the additional (presumably significant) overhead of making and tracking an additional release in the middle.) On the other hand, that division admittedly does reduce the _time_ during which a change group is implicitly tested by being used. (Instead of having both sets of changes being tested for duration D, each gets tested for only duration D/2). So I guess that question is how significant that testing duration is (compared to the number of people implicitly testing, etc.). Halving the seed rate in a field of wheat won't make the wheat ripen twice as fast. But breaking an ice cube in half does help it melt faster. The question is which analogy is actually ... um ... analogous (or, probably more accurately, how much each applies to this case). It sounds like what you are advocating is for the freeze to begin, say, six months after release. Is that correct? So the question really would be: what's the shortest amount of time from release N to freeze for N+1 that can be justified given the overhead of releasing, and I think the answer to that will always be at least somewhat subjective. Nye (PS: FWIW, it's my *personal* belief that the freeze for Lenny should have been somewhat earlier, but on the other hand we already seem to have reached the point where the time from freeze to release is a large fraction of the total release cycle, and do we really want that proportion to be bigger?) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Aneurin Price wrote: On Tue, Feb 3, 2009 at 6:24 PM, Barclay, Daniel dan...@fgm.com wrote: David Jardine wrote: On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote: Barclay, Daniel wrote: ... Well, maybe I'll prove to be understanding neither of you, but the point seems to be that you can't 'force' the maturity of a package. I wasn't talking about trying to force the maturation of any changes to go faster; I just meant dividing the changes into two (or however many) groups so the first group could be implemented, matured and released before the second group got started. That shouldn't increase the _explicit_ development, testing, and fixing effort required. (Of course, as I said, there is also the additional (presumably significant) overhead of making and tracking an additional release in the middle.) On the other hand, that division admittedly does reduce the _time_ during which a change group is implicitly tested by being used. (Instead of having both sets of changes being tested for duration D, each gets tested for only duration D/2). So I guess that question is how significant that testing duration is (compared to the number of people implicitly testing, etc.). ... It sounds like what you are advocating is for the freeze to begin, say, six months after release. Is that correct? Yes (not necessarily that exact length of time, but yes, something shorter that currently). So the question really would be: what's the shortest amount of time from release N to freeze for N+1 that can be justified given the overhead of releasing, and I think the answer to that will always be at least somewhat subjective. Nye (PS: FWIW, it's my *personal* belief that the freeze for Lenny should have been somewhat earlier, but on the other hand we already seem to have reached the point where the time from freeze to release is a large fraction of the total release cycle, and do we really want that proportion to be bigger?) If the time until the freeze is reduced, fewer changes would be incorporated before the freeze, so the length of the freeze hopefully would decrease too. If it does, then the proportion of time in the freeze wouldn't necessarily increase. (Of course, the freeze length might not decrease proportionaly.) Daniel -- (Plain text sometimes corrupted to HTML courtesy of Microsoft Exchange.) [F]
Re: Release Cycle
Ken Teague wrote: Barclay, Daniel wrote: Ken Teague wrote: ... 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? No, I wasn't requesting the latter (releasing with less quality). I was talking about the former--could freezes in testing be started sooner after the previous release? (That is, are the sets of changes made usually divisible into smaller chunks, or are there almost always a few big change groups that require keeping testing unfrozen as long as is done currently? Daniel -- (Plain text sometimes corrupted to HTML courtesy of Microsoft Exchange.) [F]
Re: Release Cycle
On Tuesday 03 February 2009 12:51:15 Barclay, Daniel wrote: [C]ould freezes in testing be started sooner after the previous release? I think so. There's really no reason that testing has to unfreeze at all, but it's how things are done right now. I think it would be nice if some automated system could, immediately after the Lenny-stable, Squeeze-testing switchover (1) find all packages that are under consideration (no bugs, been in unstable for X days) for a move unstable-testing and then monitor those package versions. Once those package versions are all either in testing or out of unstable, an automatic soft freeze goes into effect, the release team in notified and they can decide to start hardening the freeze OR thaw and restart the process from (1). Of course, the release team would remain completely in control of the process and be able to freeze/thaw at any time; the mails from the automated system would simply be advisory. [Hmm, this is something to try hacking on...] Such a automated system would serve as a guideline. It's basically: all packages that appeared suitable for a future Debian release (at the time of the last release/when monitoring started) have made it in to testing or have since been determined unsuitable for a Debian release. Depending on the state of the release goals, that would seem to me a good time to freeze. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: Release Cycle
Ken Teague wrote: Barclay, Daniel wrote: Why do so many defenses of Debian's release cycle length seem to ignore or skirt the issue of _how_ _much_ is planned to be in each release? (Saying when it's right still depends on what it is--which set of features/ changes are involved.) How much of what? How much change (new features, re-implementations, new packages); how much work. It sounds like you answered your own question in the tail end of the paragraph. 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. If there's only one feature or thing to do, it's easy to say whether it's done (right) or not. However, when you're releasing N thousand changes every 18 months or so, it's arguable that maybe you should be releasing N/2 thousand changes every 9 or 10 months. Debian is a package-based distribution. Mentioning the changes in N thousand packages is not only very time consuming, but it doesn't apply to each individual user. As such, I don't think the majority of us would want to weed through a long list of changes to find out what has changed. Why are you about mentioning individual changes? I didn't say or mean to imply anything like that. 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?) Also, with the way Debian is released (when it's ready) 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. 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. Doing it the second way does _not_ have to compromise any quality standards. (Why do you (seemingly) think it does?) 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. 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. That's the topic I'm having trouble getting to, because people think I'm saying Debian should reduce its quality and because many people can't seem to see that the release cycle length is not determined _only_ by Debian's quality standards. , there's a time when the testing tree is put into a freeze. This means that the version of the package itself doesn't change and only bug fixes are implemented at this point. At this point, you can check for yourself which changes are in the packages you plan to use. I don't follow; when does checking for changes have to do with the discussion (about the chunk size of changes and releases)? Obviously, not everything is simply divisible like that--e.g., a big change that takes many months to design, implement, and test. Changes to the way Debian functions are mentioned in the mailing lists and is updated in its documentation. ... True, but, again, how does that relate? Is Debian's stable release cycle relative long because Debian releases typically involve big changes that set the minimum time between releases, or is it because Debian [does] not really attempt to design and make smaller, more frequent increments in order to keep Debian stable releases from getting so (relatively) old (while maintaining quality standards)? Debian doesn't have a set release cycle, as you've noticed
Re: Release Cycle
Raquel wrote: On Tue, 30 Dec 2008 15:38:41 -0800 Ken Teague ktea...@pobox.com wrote: Is Debian's stable release cycle relative long because Debian releases typically involve big changes that set the minimum time between releases, or is it because Debian not really attempt to design and make smaller, more frequent increments in order to keep Debian stable releases from getting so (relatively) old (while maintaining quality standards)? Debian doesn't have a set release cycle, as you've noticed. It's long because they want to produce a distribution that's very stable and contains little or no bugs. Bugs that are submitted after a release are found after the relea... I, for one, am very thankful for Debian and the way that it releases. I run a couple of servers that I would just as soon just ran, instead of having to tinker or fix things all the time. I have more to do. Why do you (seemingly) think I'm saying Debian should reduce its quality level? As I wrote in my other message, I'm talking about changing the chunk size of releases, not the quality. Daniel -- (Plain text sometimes corrupted to HTML courtesy of Microsoft Exchange.) [F]
Re: Release Cycle
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
Re: Release Cycle
Just jumping in on one small point. On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote: 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. Doesn't actually make much sense, if you think about it. If the packages are updated by Debian developers, surely that would help Debian to its next release, too? Anyway, IIRC someone posted to this list last year that a great number of Ubuntu developers are also the Debian developer for the same package. -- Carl Fink nitpick...@nitpicking.com Read my blog at blog.nitpicking.com. Reviews! Observations! Stupid mistakes you can correct! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Carl Fink wrote: Just jumping in on one small point. Doesn't actually make much sense, if you think about it. If the packages are updated by Debian developers, surely that would help Debian to its next release, too? Anyway, IIRC someone posted to this list last year that a great number of Ubuntu developers are also the Debian developer for the same package. I was mainly referring to initial package development and Debianesque changes. This means that most of the work is done by Debian developers, leaving less work for the Ubuntu side of things. I'm not sure about the relationship/ratio of Debian:Ubuntu developers. If this is the case, it means that the developers not only have to work on Debian packages, but Ubuntu packages as well, giving them less time on their hands due to the separate release cycles. I could be wrong... - Ken -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote: Barclay, Daniel wrote: [...] 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. Well, maybe I'll prove to be understanding neither of you, but the point seems to be that you can't 'force' the maturity of a package. Halving the seed rate in a field of wheat won't make the wheat ripen twice as fast. Chemicals can no doubt make wheat ripen a little faster and intense activity by developers can remove bugs a little faster, but bugs have to be found in the first place. The longer a package has been in use, the more bugs will be found and, hopefully, eliminated. If that's not a complete load of rubbish, quality will be improved by longer release cycles. Cheers, David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Barclay, Daniel wrote: As I wrote in my other message, I'm talking about changing the chunk size of releases, not the quality. Debian releases work more or less like this: - new software versions are published upstream (source code). - this software is packaged into debian and enters 'unstable' - it is tested by users of 'unstable'. If no serious bugs are found within a certain time, the software is considered well enough for testing and enters the 'testing' distribution. - still some serious bugs are only discovered, *after* the package hits 'testing' - in order to limit the new bugs entering 'testing', at some time 'testing' becomes frozen, so only bug fixes are allowed to enter 'testing'. - after _all_ release critical bugs have been fixed, there are _zero_ RC bugs remaining and then the release manager will release the new version of debian. Because of the large number of packages, and hence the large number of bugs to be fixed, the frozen state of the next release lenny, has already been running since end of July with no release, yet. It doesn't seem reasonable to lower the barrier for improvements much, if the final stage of the release lasts for about half a year or so anyway. [By the way: many people actually prefer a stable system with not too many updates for longer periods of time. ] If you really need newer software and don't mind the lack of stability that goes along with it and the many more updates to be applied, you should consider ugrading to 'testing' or 'unstable'. In conclusion, the release cycles of debian are long because of both the extensive testing and because of the number of changes. I guess the limiting factor is rather the extensive testing than just the amount of release goals. YMMV, Johannes signature.asc Description: OpenPGP digital signature
Re: Release Cycle
David Jardine wrote: If that's not a complete load of rubbish, quality will be improved by longer release cycles. Makes sense to me. I also found this in a very old post to this list which points out a lot of pros and cons:: On Sat, 22 Sep 2007 00:36:15 +0530, Masatran, R. Deepak wrote: Subject: Debian release policy? I heard that because Etch has been released, and because Debian has got a new Project Leader, the Debian release policy might be changed http://wiki.debian.org/ReleaseProposals. Is the release policy being discussed? If so, where? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Tuesday 2008 December 30 12:30:40 Barclay, Daniel wrote: However, when you're releasing N thousand changes every 18 months or so, it's arguable that maybe you should be releasing N/2 thousand changes every 9 or 10 months. Bah. I think that 18 months is a fine amount of time between stable OS versions. Ubuntu's releases come out half-baked 2 out of 3 times anyway, so we only get a really stable release from them every 18 months. :P Microsoft will spend 18 months just *talking* about the release of their next OS, and longer to actually get it out the door, and it's *never* stable on day 1. :P There are downsides to rotating stable more often, too. Either Debian has to support more releases simultaneously or releases fall out of support more often and the users are forced to upgrade if they want to continue to receive security fixes. Perhaps it's just because it's happening right now, but I think the biggest problem with Debian's current release process is how disruptive a freeze is to unstable. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: Release Cycle
Boyd Stephen Smith Jr. wrote, on 07/01/09 09:09: On Tuesday 2008 December 30 12:30:40 Barclay, Daniel wrote: However, when you're releasing N thousand changes every 18 months or so, it's arguable that maybe you should be releasing N/2 thousand changes every 9 or 10 months. Bah. I think that 18 months is a fine amount of time between stable OS versions. Ubuntu's releases come out half-baked 2 out of 3 times anyway, so we only get a really stable release from them every 18 months. :P Microsoft will spend 18 months just *talking* about the release of their next OS, and longer to actually get it out the door, and it's *never* stable on day 1. :P There are downsides to rotating stable more often, too. Either Debian has to support more releases simultaneously or releases fall out of support more often and the users are forced to upgrade if they want to continue to receive security fixes. Perhaps it's just because it's happening right now, but I think the biggest problem with Debian's current release process is how disruptive a freeze is to unstable. My situation is that I'm having to patch some packages manually (kernel, gnu-fdisk, gthumb) because the fixes haven't entered unstable yet. 2 of the 3 patches are for bugs reported before the Lenny freeze. The third is for a bug that affected all 2.6.23-2.6.27 kernels using the eata SCSI driver for DPT controllers. Arthur. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Raquel wrote: I, for one, am very thankful for Debian and the way that it releases. I run a couple of servers that I would just as soon just ran, instead of having to tinker or fix things all the time. I have more to do. Thank you, Debian!! Yes, me too. I'm also using debian because of the release management. I appreciate the fact that stable is really stable. regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Koh Choon Lin wrote: Dear all Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. Look in http://bugs.debian.org/release-critical/ . The current number of bugs affecting the next release is 92 (the green line). When this bug number is 0 (or very close to it) then Lenny will be released. raju -- Kamaraju S Kusumanchi http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Funny. I always thought that latest testing was anointed stable by the release panjandrum when - and only when -- the latter determined that the relative positions of the planets were such to guarantee complete freedom of the new release from bugs. Ken Heard -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJXUJ6lNlJzOkJmTcRAtYkAJ4j2nWsruQisjMtt5tpjqnEzrjjRgCfWKl2 auDTtuMytrSo31JqMC7W/B8= =1rsN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
s. keeling wrote: Koh Choon Lin uselessm...@gmail.com: Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. Why? What's wrong with Etch and Lenny? They're both well usable now, yes? Are you looking for Lenny features in a stable release? Debian *takes its time and does it right* (generally speaking). That's what Debian's always been about. That's why *buntu exists. Also, when can binary for 4.0r6 be expected to be released? When it's right. This is *basic* Debian philosophy. If this doesn't work for you, you're either doing it wrong or you're in the wrong place. Why do so many defenses of Debian's release cycle length seem to ignore or skirt the issue of _how_ _much_ is planned to be in each release? (Saying when it's right still depends on what it is--which set of features/ changes are involved.) If there's only one feature or thing to do, it's easy to say whether it's done (right) or not. However, when you're releasing N thousand changes every 18 months or so, it's arguable that maybe you should be releasing N/2 thousand changes every 9 or 10 months. Obviously, not everything is simply divisible like that--e.g., a big change that takes many months to design, implement, and test. Is Debian's stable release cycle relative long because Debian releases typically involve big changes that set the minimum time between releases, or is it because Debian not really attempt to design and make smaller, more frequent increments in order to keep Debian stable releases from getting so (relatively) old (while maintaining quality standards)? Daniel -- (Plain text sometimes corrupted to HTML courtesy of Microsoft Exchange.) [F]
Re: Release Cycle
Barclay, Daniel wrote: Why do so many defenses of Debian's release cycle length seem to ignore or skirt the issue of _how_ _much_ is planned to be in each release? (Saying when it's right still depends on what it is--which set of features/ changes are involved.) How much of what? If I'm understanding this correctly, it would depend on each individual package and the features each of those packages have. It sounds like you answered your own question in the tail end of the paragraph. If there's only one feature or thing to do, it's easy to say whether it's done (right) or not. However, when you're releasing N thousand changes every 18 months or so, it's arguable that maybe you should be releasing N/2 thousand changes every 9 or 10 months. Debian is a package-based distribution. Mentioning the changes in N thousand packages is not only very time consuming, but it doesn't apply to each individual user. As such, I don't think the majority of us would want to weed through a long list of changes to find out what has changed. Also, with the way Debian is released (when it's ready), there's a time when the testing tree is put into a freeze. This means that the version of the package itself doesn't change and only bug fixes are implemented at this point. At this point, you can check for yourself which changes are in the packages you plan to use. Obviously, not everything is simply divisible like that--e.g., a big change that takes many months to design, implement, and test. Changes to the way Debian functions are mentioned in the mailing lists and is updated in its documentation. For example, changes to the Debian Installer or whatnot. Is Debian's stable release cycle relative long because Debian releases typically involve big changes that set the minimum time between releases, or is it because Debian not really attempt to design and make smaller, more frequent increments in order to keep Debian stable releases from getting so (relatively) old (while maintaining quality standards)? Debian doesn't have a set release cycle, as you've noticed. It's long because they want to produce a distribution that's very stable and contains little or no bugs. Bugs that are submitted after a release are found after the release is launched and they're normally not something that's easily found/reproducable or system-breaking. - Ken -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Tue, 30 Dec 2008 15:38:41 -0800 Ken Teague ktea...@pobox.com wrote: Is Debian's stable release cycle relative long because Debian releases typically involve big changes that set the minimum time between releases, or is it because Debian not really attempt to design and make smaller, more frequent increments in order to keep Debian stable releases from getting so (relatively) old (while maintaining quality standards)? Debian doesn't have a set release cycle, as you've noticed. It's long because they want to produce a distribution that's very stable and contains little or no bugs. Bugs that are submitted after a release are found after the release is launched and they're normally not something that's easily found/reproducable or system-breaking. I, for one, am very thankful for Debian and the way that it releases. I run a couple of servers that I would just as soon just ran, instead of having to tinker or fix things all the time. I have more to do. Thank you, Debian!! -- Raquel http://www.byraquel.com Censorship ends in logical completeness when nobody is allowed to read any books except the books nobody reads. --George Bernard Shaw -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Koh Choon Lin uselessm...@gmail.com: Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. Why? What's wrong with Etch and Lenny? They're both well usable now, yes? Are you looking for Lenny features in a stable release? Debian *takes its time and does it right* (generally speaking). That's what Debian's always been about. That's why *buntu exists. Also, when can binary for 4.0r6 be expected to be released? When it's right. This is *basic* Debian philosophy. If this doesn't work for you, you're either doing it wrong or you're in the wrong place. IMO. -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Thu, 25 Dec 2008, Mark Allums engaged keyboard and shared this with us all: --} Andrei Popescu wrote: --} On Tue,23.Dec.08, 07:37:18, Mark Allums wrote: --} --} Release schedule for Debian seems to be, whenever they feel like it. --} --} Maybe it's because I'm not a native speaker, but this sounds to me as if --} Debian Developers would release according to their mood :) --} --} --} It means that literally, but I was using it figuratively. It is a bit --} of humor. --} --} Mark Allums It's brilliant isn't it? All the software there if you want to use it, try it, or whatever and released when it's ready and not a moment before. Brilliant - no other word for it I reckon. Thank you to all who are responsible for all this software. Be well, Charlie -- Registered Linux User:- 329524 *** All wisdom is rooted in learning to call things by the right name. When things are properly identified, they fall into natural categories and understanding becomes orderly. Confucius *** Debian, just the best way to create magic ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Andrei Popescu wrote: On Tue,23.Dec.08, 07:37:18, Mark Allums wrote: Release schedule for Debian seems to be, whenever they feel like it. Maybe it's because I'm not a native speaker, but this sounds to me as if Debian Developers would release according to their mood :) Regards, Andrei Well, yes. :) It is a kind of a reference to Dilbert comic creator, Scott Adams, who would release a newsletter, aprroximately whenever I feel like it. 'Twas meant humorously. Mark Allums -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Andrei Popescu wrote: On Tue,23.Dec.08, 07:37:18, Mark Allums wrote: Release schedule for Debian seems to be, whenever they feel like it. Maybe it's because I'm not a native speaker, but this sounds to me as if Debian Developers would release according to their mood :) It means that literally, but I was using it figuratively. It is a bit of humor. Mark Allums -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Tue,23.Dec.08, 07:37:18, Mark Allums wrote: Release schedule for Debian seems to be, whenever they feel like it. Maybe it's because I'm not a native speaker, but this sounds to me as if Debian Developers would release according to their mood :) Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Release Cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrei Popescu wrote: On Tue,23.Dec.08, 07:37:18, Mark Allums wrote: Release schedule for Debian seems to be, whenever they feel like it. Maybe it's because I'm not a native speaker, but this sounds to me as if Debian Developers would release according to their mood :) Regards, Andrei Suppose that could be correct. When Steve McIntyre feels the release is at a point he will sign his name to then its released? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklSp+UACgkQejxzjThnMmJSCgCdFSx4YfA4P/HK4bbvaD/k0Kik fuEAoIiftPV/rDkr2IizU7gjq1NSh4gk =XDDr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Wed,24.Dec.08, 16:21:41, Daryl Styrk wrote: Andrei Popescu wrote: On Tue,23.Dec.08, 07:37:18, Mark Allums wrote: Release schedule for Debian seems to be, whenever they feel like it. Maybe it's because I'm not a native speaker, but this sounds to me as if Debian Developers would release according to their mood :) Suppose that could be correct. When Steve McIntyre feels the release is at a point he will sign his name to then its released? Steve McIntyre is the Debian Project Leader. The Release Manager (Marc Brockschmidt) is the one responsible for the release :) Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Release Cycle
Dear all Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. Also, when can binary for 4.0r6 be expected to be released? -- Regards Koh Choon Lin -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Tue, Dec 23, 2008 at 08:28:43PM +0800, Koh Choon Lin wrote: Dear all Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. When its ready. Generally every couple of years or so. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Koh Choon Lin wrote: Dear all Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. Also, when can binary for 4.0r6 be expected to be released? Binary for 4.0r6 should be out any day now. Might already be out. Release schedule for Debian seems to be, whenever they feel like it. Something like twelve-eighteen months, but can stretch out. Ubuntu is pushing it, releasing every six months. In the opinion of some. As a rule, Debian Testing is pretty usable six months after a new Stable release. So, if you are considering using Debian, go ahead. Then consider switching from the major release to the testing distribution after a suitable interval. Mark Allums -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
Douglas A. Tutty wrote: On Tue, Dec 23, 2008 at 08:28:43PM +0800, Koh Choon Lin wrote: Dear all Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. When its ready. Generally every couple of years or so. Mark Allums wrote: Release schedule for Debian seems to be, whenever they feel like it. Something like twelve-eighteen months, but can stretch out. Generally, our two answers are not really at odds. Twenty-four months is the usual stretch. Seems like. Mark Allums -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release Cycle
On Tue, Dec 23, 2008 at 08:28:43PM +0800, Koh Choon Lin wrote: Dear all Anyone has an idea what is the release cycle for Debian? I understand six months is the standard for Ubuntu. The operative rule for all recent releases is that each release happens when the release manager decides that the code is ready for release, and not a minute before. The Biref History of Debian lists all releases and their dates. The last release that did not have a code name from Toy Story was in Nov, 1995. The most recent named release is Etch which happened on Apr 8, 2007. This is an interval of 11.5 years, or 138 months. There have been 8 named releases. The mean interval between releases is 138/8 months, i.e. 17.25 months per release. With a history of eigth releases, it is beginning to be meaningful to calculate a variance of the release interval, but I'm too lazy to do it. ;-) -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Release cycle
Am 2006-03-10 22:23:48, schrieb David Berg: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Woody went faster then 2-3 years, but there was a changement in the Woody-Installer which took a litle bit and now it was debian-installer for Sarge... Please note, that I'm looking for information. I am quite aware that etch will be ready when it's ready and that its a volunteer organization and things take time. All I want to know is if there is any reason to think that etch might be different than previous releases. Normaly Etch will be released at the end of this century... pardon year! Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
Þann 2006-03-11, 22:07:44 (-0500) skrifaði Mark Fletcher: gawab wrote: Steve Lamb wrote: Marc Shapiro said: Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? Start working through Monsters, Inc.? I mean what's cooler than being able to say you run Debian Boo. :) Maybe we can call the next one Debian Hell, so we can wait for Hell to freeze :-) Many of the people who come to this list looking for help know exactly what it's like to be in Debian Hell... :-! Actually Hell freezes over every year, or allmost. http://en.wikipedia.org/wiki/Hell%2C_Norway Oli (who is not from Hell) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
Olafur Jens Sigurdsson writes: Actually Hell freezes over every year, or allmost. http://en.wikipedia.org/wiki/Hell%2C_Norway There is also a Hell in Michigan in the US (in the lower peninsula: Paradise is in the upper peninsula). -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
On Sat, 11 Mar 2006 22:07:44 -0500 Mark Fletcher [EMAIL PROTECTED] wrote: Many of the people who come to this list looking for help know exactly what it's like to be in Debian Hell... :-! Attempting to keep an up-to-date Sid system before I knew much about Linux, I have been to Debian Hell. It's mild. Cybe R. Wizard -- When Windows are opened the bugs come in. Winduhs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
Steve Lamb wrote: Marc Shapiro said: Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? Start working through Monsters, Inc.? I mean what's cooler than being able to say you run Debian Boo. :) Maybe we can call the next one Debian Hell, so we can wait for Hell to freeze :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
David Berg wrote:
I don't know if there's a good way to ask this question, and am very
tempted to just hit cancel now...
I'm curious to know when etch might freeze. Now, before you all jump
on me and tell me its ready when its ready, let me clarify. I'm not
[snip]
I think that your request is perfectly reasonable. In fact, it is
something which has bothered me about every Linux distro I've had
contact with, and I've had contact with a few.
It boils down to this: In order to be able to answer your question
meaningfully, one must have real requirements. But all Linux
distributions have none. A meaningful answer would be a list
of functional and performance requirements which must be met, along
with a list of deviations from those requirements, and estimates
of effort required (not elapsed time) to meet each requirement
which is not yet met.
Until this is done (and I have no hopes of it ever being done)
then there can be no meaningful answer to your question, as there
are currently no objective criteria by which one can judge readiness.
As it is now, when the development team either has some gut feel
that things are good enough, or just plain get tired of working
on a given release, then it is declared stable.
This is not anything peculiar to Debian, by any means.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
Marc Shapiro wrote: David Berg wrote: I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. I'm not looking for a date, or a month, or even a year necessarily as I realize they would all be guesses. Perhaps I could get the best answer by making this my question: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? Make a toy story sequel where there are lot more characters? -- http://groups.google.com/group/cornell-bazaar/about -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
On Friday, 10.03.2006 at 22:09 -0800, Steve Lamb wrote: Marc Shapiro said: Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? Start working through Monsters, Inc.? I mean what's cooler than being able to say you run Debian Boo. :) I'd be more interested in having Debian Wzowski (or Debian Googly-Bear), really... :-) Dave. -- Please don't CC me on list messages! ... Dave Ewart - [EMAIL PROTECTED] - jabber: [EMAIL PROTECTED] All email from me is now digitally signed, key from http://www.sungate.co.uk/ Fingerprint: AEC5 9360 0A35 7F66 66E9 82E4 9E10 6769 CD28 DA92 signature.asc Description: Digital signature
Re: Release cycle
gawab wrote: Steve Lamb wrote: Marc Shapiro said: Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? Start working through Monsters, Inc.? I mean what's cooler than being able to say you run Debian Boo. :) Maybe we can call the next one Debian Hell, so we can wait for Hell to freeze :-) Many of the people who come to this list looking for help know exactly what it's like to be in Debian Hell... :-! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Release cycle
I don't know if there's a good way to ask this question, and am very tempted to just hit cancel now... I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. I'm not looking for a date, or a month, or even a year necessarily as I realize they would all be guesses. Perhaps I could get the best answer by making this my question: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Please note, that I'm looking for information. I am quite aware that etch will be ready when it's ready and that its a volunteer organization and things take time. All I want to know is if there is any reason to think that etch might be different than previous releases. If you still feel the need to flame me, fire away. I'll simply read then file in /dev/null. --Dave
Re: Release cycle
On Friday 10 March 2006 21:23, David Berg wrote: I don't know if there's a good way to ask this question, and am very tempted to just hit cancel now... I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. I'm not looking for a date, or a month, or even a year necessarily as I realize they would all be guesses. Perhaps I could get the best answer by making this my question: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Please note, that I'm looking for information. I am quite aware that etch will be ready when it's ready and that its a volunteer organization and things take time. All I want to know is if there is any reason to think that etch might be different than previous releases. If you still feel the need to flame me, fire away. I'll simply read then file in /dev/null. --Dave Plan was to release Etch sometime in the December 2006 time frame. Freeze would certainly occur before that time. I don't know how long the freeze will be, perhaps several months if not more. This is the timeframe that I heard based on following the debian-boot (installer work) and other various mailing lists. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
On Fri, Mar 10, 2006 at 10:23:48PM -0600, David Berg wrote: I don't know if there's a good way to ask this question, and am very tempted to just hit cancel now... I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. I'm not looking for a date, or a month, or even a year necessarily as I realize they would all be guesses. Perhaps I could get the best answer by making this my question: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Hi David, there are release goals that are looked at. If you gauge how things are going based upon those goals, it may provide some insite. There are major transitions(abi/api/gnome/xorg), translation goals, deciding what packages get a last minute repreive (like webmin), including new arch(64bit) and not including others(68k) and of course the rate at which RC bugs are fixed. It seems each release cycle is an advanture. This one include ubuntu as a factor. They are working with Debian[0] and will hopefully speed up some issues. There has also been 'teams' and 'groups' forming to address issue which I think is a good thing(games,fonts,xorg,...). And folks hosting BSP's[1]. -Kev [0] there is [discussion/debate] as to what [this means/this will mean] amongst ubuntu and debian devs. [1] Bug Squashing Parties -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Release cycle
David Berg wrote: I don't know if there's a good way to ask this question, and am very tempted to just hit cancel now... I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. I'm not looking for a date, or a month, or even a year necessarily as I realize they would all be guesses. Perhaps I could get the best answer by making this my question: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Please note, that I'm looking for information. I am quite aware that etch will be ready when it's ready and that its a volunteer organization and things take time. All I want to know is if there is any reason to think that etch might be different than previous releases. If you still feel the need to flame me, fire away. I'll simply read then file in /dev/null. --Dave I know this is old, but it's the most up to date information I could find. It's an email from Steve Langasek about the plans for etch. http://lists.debian.org/debian-devel-announce/2005/10/msg4.html It suggests a freeze beginning in July, with a release at the end of this year. However, given Debian's policy of it's ready when it's ready, I think a better way to get a grasp on the release timeframe is to look at the feature list for etch, and compare it to the current testing snapshot. Unfortunately, details on what exactly should be in etch are also hard to find, but in the same email, Steve lays down some of the more major goals: - gcc 3.3 - 4.0 toolchain transition - xfree86 - xorg transition - amd64 as an official arch (and the mirror split as a pre-condition for that) - sorting out docs-in-main vs. the DFSG - sorting out non-free firmware - secure apt As far as I know, the first 2 are done in sid (and possibly etch, though I don't know because I don't have an etch machine). I think secure apt is also done, but the rest, I think, are still ongoing. I know that there have been a couple of C++ ABI transitions, but I'm not currently aware of any more that are pending, so that's good. I'm sure others can fill in a lot more blanks than me. Hope that helps, Justin Guerin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
David Berg wrote: I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. I'm not looking for a date, or a month, or even a year necessarily as I realize they would all be guesses. Perhaps I could get the best answer by making this my question: Has anyone heard/read anything that MIGHT indicate that etch MIGHT go stable faster than the 2-3 years that it took for Sarge, and Woody to go stable? Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? -- Marc Shapiro [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
Marc Shapiro said: Personally, my theory on the REAL reason that the release cycles have been getting so long is that we are running out of Toy Story character names. What do we do when there are no more characters left? Start working through Monsters, Inc.? I mean what's cooler than being able to say you run Debian Boo. :) -- Steve Lamb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release cycle
On Fri, 2006-03-10 at 22:23 -0600, David Berg wrote: I don't know if there's a good way to ask this question, and am very tempted to just hit cancel now... I'm curious to know when etch might freeze. Now, before you all jump on me and tell me its ready when its ready, let me clarify. FYI, Distrowatch's summary of expected upcoming releases has Debian Etch pegged for 2006-12-06, with a link to this post: http://lists.debian.org/debian-devel-announce/2005/10/msg4.html As yet I haven't investigated the current odds in Las Vegas. I lost the office Oscar pool this year (damn that Crash!), so I'm strategizing for the Etch release pool. :-) -- Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
entrevista com o novo líder do projeto Debian: Branden Robinson / pacotes KDE 3.4 / release cycle
Olá, no link abaixo tem uma interessante e rápida entrevista ( em inglês) com o novo DPL: Brande Robinson. http://www.linux-mag.com/content/view/1870/2107/ Ele aborda vários assuntos em pauta 'quente' no meio Debian. Por exemplo: o que falta para lançar oficialmente o Sarge debates sobre o release cycle ( http://wiki.debian.net/?ReleaseProposals ) SPI DFSG Ubuntu O ingresso do KDE e Gnome no Testing foram críticos mas estão finalizando. O kde 3.4 já tem pacotes PREVIEW (a quem interessar, vi um link para o repositório do 3.4 no debianwiki na pagina do kde http://wiki.debian.net/?DebianKDE ) , mas só vai entrar no UNSTABLE quando o sarge for oficialmente lançado, devido ao alcance das dependências. O sarge vai sair com kde 3.3, para não provocar mais atrasos no lançamento. O novo instalador está indo muito bem no RC3 (praticamente sem bugs novos) e não é mais motivo de preocupação ou atrasos. Boa sorte. André Felipe
Fw: [Semi-OT] Funding for speeding up debian release cycle
From: Alvin Oga [EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 5:24 AM On Tue, 26 Oct 2004, Shriram Shrikumar wrote: Would it be feasible to hire one or more full time developer to spend all their time ironing out the release critical bugs? buggs are fixed daily ... let the resumes flow in :-) How much would this developer need to get paid? in silly con valley ... a good developer can pull down $150K/yr or more and gazillion in stock options - you get what you pay for ... in terms of quality of coding, productive work, qa, bug tracking, doc que ment a tion, testing, etc release cycle can be daily or weekly or monthly ... - you can release a CD anytime you like and that daily build already exists - the developers tasks is probably just 10% of the overall release cycle before it gets blessed to go out - if you want a stable release ... where there are minimal buggs, you already have that ( sarge ) - and making more releases does NOT mean better sw ( even silly ms takes 5 years to release a new OS vs ( patching their mistakes every 2-3 yrs w/ about 500 ( developers and we wont even try to count their ( qa/documentaion/bug tracking/etc folks .. - latest/greatest usually fixes known problems, but always creates new ones - pick the problems you want fixed and watch for those apps and test those apps flame suit on c ya alvin /* Just a newbie question, but if you hire someone any pay rate to write software for debian, Wouldnt they want to get paid? i.e. Somebody is going to have to start charging for something to pay for the develvoper's salary, and the admin's salary, etc. Just a thought. */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Semi-OT] Funding for speeding up debian release cycle
On Tue, 26 Oct 2004, Shriram Shrikumar wrote: Would it be feasible to hire one or more full time developer to spend all their time ironing out the release critical bugs? buggs are fixed daily ... let the resumes flow in :-) How much would this developer need to get paid? in silly con valley ... a good developer can pull down $150K/yr or more and gazillion in stock options - you get what you pay for ... in terms of quality of coding, productive work, qa, bug tracking, doc que ment a tion, testing, etc release cycle can be daily or weekly or monthly ... - you can release a CD anytime you like and that daily build already exists - the developers tasks is probably just 10% of the overall release cycle before it gets blessed to go out - if you want a stable release ... where there are minimal buggs, you already have that ( sarge ) - and making more releases does NOT mean better sw ( even silly ms takes 5 years to release a new OS vs ( patching their mistakes every 2-3 yrs w/ about 500 ( developers and we wont even try to count their ( qa/documentaion/bug tracking/etc folks .. - latest/greatest usually fixes known problems, but always creates new ones - pick the problems you want fixed and watch for those apps and test those apps flame suit on c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Semi-OT] Funding for speeding up debian release cycle
Hi, Would it be feasible to hire one or more full time developer to spend all their time ironing out the release critical bugs? How much would this developer need to get paid? Any ideas as to whether people would be willing to commit a certain amount of annual donations to this etc. would also be beneficial and I can put together details of whether this is actually feasible or not. I should also be able to set it up or at least help to do so. All opinions on this matter gratefully received. Thanks best wishes, Shri -- Shri Shrikumar Kraya Solutions Tel: 0845 644 4745 Project Manager Edinburgh, Scotland Mob: 0773 980 3499 Web: www.kraya.co.uk Email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two Debian Release Cycle Issues
On Thu, Mar 13, 2003 at 09:24:00PM -0500, Abdul Latip wrote: * The Multiple Architecture Support Issue Each additional architecture support will significantly increase the Debian release cycle, including security update, as well as moving from unstable to testing. I don't believe that this is true to anywhere near the extent frequently claimed. Moving from one architecture to multiple architectures certainly introduces a good deal more work; moving from 11 to 12 makes very little difference. You'll probably have seen comments about the extra architectures in woody having slowed things down, but that's because some of the infrastructure wasn't up to the task. That's been fixed now. Of the glibc bugs that slowed things down recently, a number were just as visible on i386. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two Debian Release Cycle Issues
also sprach Abdul Latip [EMAIL PROTECTED] [2003.03.14.0324 +0100]: * The Essential Packages Issue I guess that there are a few essential/ very important packages. (100?) compared with the whole set of Debian packages (1?). However, the amount of packages (100 or 1) has very little relation to the Debian release cycle. yes, i would call this correct. it is actually about RC bugs, so-called release-critical bugs. If there is one of those, then the frozen testing release is not ready for rollout. Each additional architecture support will significantly increase the Debian release cycle, including security update, as well as moving from unstable to testing. sure. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Keyserver problems? http://keyserver.kjsl.com/~jharris/keyserver.html Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc pgp0.pgp Description: PGP signature
Two Debian Release Cycle Issues
Hi, First of all, apology for my poor English. This following is *NOT* a complaint, but I would like to know if I have got the picture correctly in regard of the Debian release cycle (e.g. from Woody to Sarge). Please let my know the URL if this issue has been discussed before. * The Essential Packages Issue I guess that there are a few essential/ very important packages. (100?) compared with the whole set of Debian packages (1?). However, the amount of packages (100 or 1) has very little relation to the Debian release cycle. * The Multiple Architecture Support Issue Each additional architecture support will significantly increase the Debian release cycle, including security update, as well as moving from unstable to testing. Thank you very much for any clue. Again, this is not a complaint, and apology for my poor English. Regards, -- Abdul Latip -- Angkasa Internet Junior Staff -- ANGIN.com http://people.WebIndonesia.com/dullatip/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
