Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sun, Mar 18, 2007 at 03:20:59AM +0800, Thomas Goirand wrote: > I want to cry about this issue... > > Few weeks ago, it was possible to setup php5, mysql5 and apache2 in > sarge using the backports. But seems few weeks (maybe 1 week ?), if you > do setup php5-mysql and mysql-server-5 from the backports, then BOOM, > it's impossible for any php-mysql enabled application to authenticate. > > I know how to fix, you "simply" have to recompile php5 using the > backports.org sources, but that's not the issue. I had a big bunch of > user of our control panel complaining about it, and most of it thought > it was the fault of our app, when it is really a backports.org issue. well, what did you expect? if you're using backports.org, you may as well be using unstable. in fact, you're better off with unstable because there are more people using it, so it is better tested. with backports.org, you can be pretty sure that NOBODY else is using your exact combination of libraries and other packagesso you may be the ONLY person to ever encounter a particular bug. IMO, backports.org is just a second-rate way of running 'unstable' for people who are scared by the name 'unstable'. (and 'testing' is a way of running 'unstable' with a long delay for any urgent fixes. although at least it also serves the useful purpose of testing the next release so it's a good thing that some people use it) craig -- craig sanders <[EMAIL PROTECTED]> BOFH excuse #160: non-redundant fan failure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sat, Mar 17, 2007 at 06:20:52PM -0400, Roberto C. Sanchez wrote: > On Sun, Mar 18, 2007 at 08:11:15AM +1100, Craig Sanders wrote: > > > > well, what did you expect? > > > > if you're using backports.org, you may as well be using unstable. > > > That's not quite true. You may as well be using unstable for the > packages you are pulling from backports. yes, it's not quite true. it's not as good as using 'unstable. but in terms of what it does to the 'pristine' status of an allegedly 'stable' system, it's effectively the same. if you're using backports, then you're no longer running 'stable' and it's just plain stupid to fool yourself that you are. > > in fact, you're better off with unstable because there are more people > > using it, so it is better tested. with backports.org, you can be pretty > > sure that NOBODY else is using your exact combination of libraries and > > other packagesso you may be the ONLY person to ever encounter a > > particular bug. > > Really? So, he's better off with unstable so that he can potentially be > the first user to find it there instead of in backports? So that he can > also be potentially bitten by any number of bugs which invariably hit > unstable first? yes. MUCH better off. i've been running unstable on hundreds of servers and desktops for over 10 years. i don't even need a whole hand of fingers to count the serious problems caused by packages in unstable in that time. only once has a problem occured that took me more than an hour minutes to fix. and only a few times has a problem occurred that took me more than 10-15 minutes to fix. most "problems" are trivial - changes in config file format between one version of a program and the next. OTOH, i've upgraded numerous servers from one version of 'stable' to the next version of 'stable' over the years. that is *ALWAYS* a massive PITA because it has generally been at least a year or two between stable releases...and even with all the testing done before a release, some things don't go anywhere near as smoothly as they should. IMO, it's better to upgrade a couple of dozen packages every few weeks than a few thousand packages every few years. less to go wrong at any one time. > > IMO, backports.org is just a second-rate way of running 'unstable' for > > people who are scared by the name 'unstable'. that needs saying again. 'unstable' isn't anywhere near as scary as the name implies. if you NEED a stable (as in "unchanging") system then just stick with 'stable' and security-updates. don't fool yourself that stable+backports is any better than 'unstable', because it isn't - and it's often worse. otherwise, use 'testing' or 'unstable'. don't waste your time with third-party stuff like backports. > > (and 'testing' is a way of running 'unstable' with a long delay > > for any urgent fixes. although at least it also serves the useful > > purpose of testing the next release so it's a good thing that some > > people use it) > > If an orphaned package is the subject of a security advisory, who > fixes it? In stable, it is the security team. In unstable, there is > no obligation for anybody to provide security support. Someone on the big deal. in practice, security updates are in stable either at the same time as in stable, or the package concerned was upgraded months before anyone even discovered that there was a security hole in it. keeping months or years ahead of the script kiddies is one of the reason i use unstable. > security team or the QA team may be nice enough to do a QA upload of > the new version of the package (as many upstream developers release > security fixes by releasing whole new versions), but nobody is > obligated to do that. read the fine print. nobody's *obligated* to do it for stable, either. and certainly not for backports (which has inherent security implications because backporters aren't vetted and don't have to be in the web of trust like debian developers are - yes, many are DDs...not all). like everything in debian, security updates are done on a "best-effort" basis. the fact that debian's "best-effort" tends to be miles ahead of any commercial, paid-for "guarantee" doesn't change the fact that it's a best-effort. craig -- craig sanders <[EMAIL PROTECTED]> BOFH excuse #261: The Usenet news is out of date -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sun, Mar 18, 2007 at 05:25:30PM +0800, Thomas Goirand wrote: > I just expected it to work like it did before, for more than 1 year, and > that it worked AT LEAST as good as with Etch or SID. well, if you wanted it to just keep working without change then you should have stuck with 'stable'. that's the whole point of stable. > > if you're using backports.org, you may as well be using unstable. > > I do, but for development purposes only, like many. If it's about me, I > use apache 1.3, php4 and mysql4.0 because I don't need anything else. > But it's NOT about me this time, it's about other people, and I can tell > you that there are a lot doing this. you miss the point. backports is no better than unstable. once you use it on a stable system, you've stopped running stable. if you think a 'stable' system with some packages from backports is still 'stable' then you are just fooling yourself. it's not. > > in fact, you're better off with unstable because there are more > > people using it, so it is better tested. with backports.org, you > > can be pretty sure that NOBODY else is using your exact combination > > of libraries and other packagesso you may be the ONLY person to > > ever encounter a particular bug. > > Do you REALLY think that using php5, mysql5 and apache2 under Sarge is > uncommon? If you do, I can tell you it's not! the *EXACT* combination of libraries and other packages on your system MAY WELL BE UNCOMMON. certainly more uncommon than the packages in systems running 'unstable'. there may be obscure bugs that only show up under obscure combinations of libraries and packages. running backports lets you be the guinea-pig to find out. > > IMO, backports.org is just a second-rate way of running 'unstable' > > for people who are scared by the name 'unstable'. > > For me, it's just a way of using packages that are really missing > because of the way that Debian works. I don't like it either, but > sometimes there is no other way. yes, there is another way. a better way. run 'unstable'. or run 'stable' with some packages from 'unstable' (use apt's pinning feature to keep most stuff as stable except the packages you specifically allow from unstable). that gives you everything that backports does, with better testing, better security, and packages by known & identified DDs rather than random members of the public. > P.S: Still, my question remains: who should I contact? whoever's responsible for backports.org. which isn't debian. craig -- craig sanders <[EMAIL PROTECTED]> BOFH excuse #49: Bogon emissions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sun, Mar 18, 2007 at 09:57:49PM +1100, Craig Sanders wrote: > > > if you're using backports.org, you may as well be using unstable. > > > > I do, but for development purposes only, like many. If it's about me, I > > use apache 1.3, php4 and mysql4.0 because I don't need anything else. > > But it's NOT about me this time, it's about other people, and I can tell > > you that there are a lot doing this. > > you miss the point. backports is no better than unstable. once you use > it on a stable system, you've stopped running stable. > > if you think a 'stable' system with some packages from backports is > still 'stable' then you are just fooling yourself. it's not. btw, the other thing that makes backports just like 'unstable' is that you should test every upgrade on another machine *BEFORE* you upgrade production servers. you obviously didn't do that. otherwise you would have found the problem before b0rking your server. craig -- craig sanders <[EMAIL PROTECTED]> BOFH excuse #191: Just type 'mv * /dev/null'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Accounts Manager - Master or Servant?
On Sat, Jan 13, 2001 at 11:10:32AM +0100, Martin Schulze wrote: > Once important tasks are done and no other problems with new > applicants occur they will be accepted and receive their account. The problem with statements like this, Joey, is that you have no right at all to make them. if you're not willing to fulfil your duties in creating new maintainer accounts as they get approved by the NM team, then please step down and make room for someone who is. remember that your position as Accounts Manager for debian is a delegation of responsibility to you - the role is to be a servant of the organisation with duties to perform, not a master with the right to unilaterally make policy decisions such as "new maintainer is closed". you did the same thing about 18 months ago. you announced that you were closing New Maintainer. One of the excuses/reasons you gave was that it was too much work. then, as now, that sparked off a huge flame-war covering pretty much the same issues as now. ok, eventually we (actually mostly Dale, and some others) worked through that and came up with a great new system for processing New Maintainer applications. problem solved, you might think. unfortunately, nobecause you are being the same bottle-neck in the process as you were last time. you've effectively kept for yourself veto power over any new maintainers joining debian. this is unacceptable for any supposedly democratic organisation. it's even more unacceptable for an organisation like debian which claims to be the only truly open-source distribution - we're open source because anyone can join in and be part of it. that's the theory, anyway...too bad it's not allowed to work that way in practice. now, are you willing to do the job that you volunteered to do? if not, will you get out of the way and refrain from obstructing other volunteers(*) who ARE willing to perform those duties? (*) preferably we should have a group of half-a-dozen or so Accounts Managers. like the ftp archives, this is too important to leave in just one or two hands. craig -- craig sanders
Re: (long reply) Re: NM saga (all of it - Joey, this means you)
On Mon, Jan 15, 2001 at 04:56:47PM +0100, Bas Zoetekouw wrote: > 1) James did post on -private about this > 2) The DAM is the one who DECIDES whether you are accepted as a > developer or not. He is not just someone who creates accounts. As a > delegate of the project leader (e.g. Wichert), he may "may make > certain decisions which the Leader may not make directly, including > approving or expelling Developers or designating people as > Developers who do not maintain packages. " (Debian Constitution). the key point there is that the DAM is supposed to make decisions. i.e. approve or reject an application, not ignore it for months and hope it will go away. btw, those decisions are meant to be guided by a rough consenus of existing developers. additionally, those decisions (like all decisions made by the DPL or delegates) can be overruled via a vote on a general resolution. this fact highlights that the DPL and delegates are servants of the debian organisation, not the masters. Joey informed me that he is no longer a DAM, so James is the only one we have right now. (the NM web pages need to be updated.) Sure, James might have posted an "i'm away" message but that's no excuse for ignoring the NM applications that been piling up for months. if the job is too much for one person, or if James is too busy with other stuff then we need more people working on it. we have hundreds of developers. in fact, we have hundreds who have been around for several years, more than long enough to establish whether they are trustworthy or not. we should call for volunteers and choose or elect half-a-dozen or so to do the job. i can think of at least that many developers who have been around long enough and have demonstrated their integrity and their committment to debian who could certainly be entrusted with the responsibility. it's too important a job to leave in the hands of one or two people. Wichert, please appoint more DAMs ASAP, or call for an election to vote some more in if you can't decide on any names. craig -- craig sanders
Debian Accounts Manager - Master or Servant?
On Sat, Jan 13, 2001 at 11:10:32AM +0100, Martin Schulze wrote: > Once important tasks are done and no other problems with new > applicants occur they will be accepted and receive their account. The problem with statements like this, Joey, is that you have no right at all to make them. if you're not willing to fulfil your duties in creating new maintainer accounts as they get approved by the NM team, then please step down and make room for someone who is. remember that your position as Accounts Manager for debian is a delegation of responsibility to you - the role is to be a servant of the organisation with duties to perform, not a master with the right to unilaterally make policy decisions such as "new maintainer is closed". you did the same thing about 18 months ago. you announced that you were closing New Maintainer. One of the excuses/reasons you gave was that it was too much work. then, as now, that sparked off a huge flame-war covering pretty much the same issues as now. ok, eventually we (actually mostly Dale, and some others) worked through that and came up with a great new system for processing New Maintainer applications. problem solved, you might think. unfortunately, nobecause you are being the same bottle-neck in the process as you were last time. you've effectively kept for yourself veto power over any new maintainers joining debian. this is unacceptable for any supposedly democratic organisation. it's even more unacceptable for an organisation like debian which claims to be the only truly open-source distribution - we're open source because anyone can join in and be part of it. that's the theory, anyway...too bad it's not allowed to work that way in practice. now, are you willing to do the job that you volunteered to do? if not, will you get out of the way and refrain from obstructing other volunteers(*) who ARE willing to perform those duties? (*) preferably we should have a group of half-a-dozen or so Accounts Managers. like the ftp archives, this is too important to leave in just one or two hands. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (long reply) Re: NM saga (all of it - Joey, this means you)
On Mon, Jan 15, 2001 at 04:56:47PM +0100, Bas Zoetekouw wrote: > 1) James did post on -private about this > 2) The DAM is the one who DECIDES whether you are accepted as a > developer or not. He is not just someone who creates accounts. As a > delegate of the project leader (e.g. Wichert), he may "may make > certain decisions which the Leader may not make directly, including > approving or expelling Developers or designating people as > Developers who do not maintain packages. " (Debian Constitution). the key point there is that the DAM is supposed to make decisions. i.e. approve or reject an application, not ignore it for months and hope it will go away. btw, those decisions are meant to be guided by a rough consenus of existing developers. additionally, those decisions (like all decisions made by the DPL or delegates) can be overruled via a vote on a general resolution. this fact highlights that the DPL and delegates are servants of the debian organisation, not the masters. Joey informed me that he is no longer a DAM, so James is the only one we have right now. (the NM web pages need to be updated.) Sure, James might have posted an "i'm away" message but that's no excuse for ignoring the NM applications that been piling up for months. if the job is too much for one person, or if James is too busy with other stuff then we need more people working on it. we have hundreds of developers. in fact, we have hundreds who have been around for several years, more than long enough to establish whether they are trustworthy or not. we should call for volunteers and choose or elect half-a-dozen or so to do the job. i can think of at least that many developers who have been around long enough and have demonstrated their integrity and their committment to debian who could certainly be entrusted with the responsibility. it's too important a job to leave in the hands of one or two people. Wichert, please appoint more DAMs ASAP, or call for an election to vote some more in if you can't decide on any names. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
