Re: Partners
Hi, Jonathan: On Saturday 18 December 2010 02:06:27 Jonathan Wiltshire wrote: > Please keep this discussion on-list, that is > debian-project@lists.debian.org, and avoid top-posting > (http://idallen.com/topposting.html). > > On Sat, Dec 18, 2010 at 12:51:50AM +, anthony budd wrote: > > If a system could be arrnaged what would be the terms? Also could a > > pro version be made. When I say made I just mean make it look diffent > > with minor changes. So that people can buy a new and inovative > > product. > > You don't seem to have understood the purpose of Debian, or its philosophy, > or read the links I sent you. Of course you can take our works, make them > look prettier and redistribute them for money, but you still have to honour > the license terms of each package. Humm... don't think so. Building, say, a "Debian Professional" distribution would indeed be a Debian's trademark violation and that's probably what the original poster was asking to do. Cheers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012191949.09689.jesus.nava...@undominio.net
Re: QTS ( was Re: user support - Shapado instance for Debian)
Hi, Stefano: On Friday 08 October 2010 10:22:24 Stefano Zacchiroli wrote: > On Thu, Oct 07, 2010 at 11:03:42PM +0100, MJ Ray wrote: > > Lars Wirzenius wrote: > > > ask.debian.net is not taking anything away from you. You can ignore it > > > the way you ignore Debian web forums, for example. ask.debian.net is > > > not there to replace mailing lists, it is there to add to them, for > > > those who want to use it. > > AOL. > > > It makes us look bad if there are bad answers or no answers there. > > ask.debian.net seems unconnected to the lists - it adds nothing to them > > and that's disappointing. > > I wonder if you forget a "at least for me" in the last sentence or not. > It's a triviality that, for the mail only user, ask.d.n adds > nothing. But it adds a lot for the web user. Does it? With regards to any assymetric relationship, benefit is in finding common grounds. What I mean is, think of an extreme scenario, one where only newbies asking for help visit, say, a web forum with no expert over there. This extreme case would be worse than no help at all, since it would be bound to rise both cargo cult (I saw once a so called expert and he did something like this, though I don't know why, I know it worked) and bad practices (think of ten year old children explaining one another how babies are made). I for one would want an expert coming to my workplace instead of me, do for free my stuff and allow me to stay at home, but I know that won't work: if I want the expert advice I should go where the expert is, not the other way around. And for a utilitary/communitary point of view is better to "cattle" all the experts on a single place, even if it's not the best one, than split them away (I already explained my point of view about that in a previous message). > Luckily, it also gets > nothing away from the mail only users—as Lars commented above—since I'm > confident not a single mail only user will move from a mailing list to a > web-based system like ask.d.n. Not my experience. I did great use of NNTP and I still find it lightyears beyond anything else, including mail lists. But communities are basically expressions of the network effect, so here I am using a mail list. More on that: due to the popularity of web forums you end up with a lot of projects that rely *only* on them, even for things like announcing new versions or, even worse, having a mail list which is of no use but misleading people (since it's not used by the developers themselves). > Do-ocracy is still the main thrust in the Debian community Do-ocracy is a great thing, probably the best way to drive achievements, but it's not free of problems, the most obvious one being that there's nothing within do-ocracy that ables "the system" to avoid self-destructive practices. As an extreme and crazy example, taking a gun and start firing people down is a meritable action from the sole do-ocracy point of view, while telling "do not do that" is not. Cheers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010081339.20724.jesus.nava...@undominio.net
Re: QTS ( was Re: user support - Shapado instance for Debian)
Hi Tshepang: On Thursday 07 October 2010 19:02:39 Tshepang Lekhonkhobe wrote: > On Thu, Oct 7, 2010 at 18:13, Andrei Popescu wrote: [...] > > You ask a question, and someone answers. If you find the answer > useful, you vote it as correct, and the answerer gets points for that. > You also get email notifications if you so wish if you got a new > answer. Go have a look and see (ask.debian.net). It's quite a good > idea. That's knowledge by consensus. How it deals with nonsenses? I.e.: Q: I downloaded a script from the Internet and I can't execute it. A: cd ~ && chmod -R a+x Hey, it works! I think I should mod up this guy. It's not a theoretical scenario: I visit Ubuntu forums from time to time and there's an ashtounding number of answers in the line of my previous example. Cheers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010081318.47399.jesus.nava...@undominio.net
Re: Improving coordination / support for upstreams
Hi, CJ: On Wednesday 01 September 2010 21:49:31 CJ Fearnley wrote: [...] > Here are some concrete ideas that might positively improve our > coordination with upstreams: [...] > - Add a reportbug --kudos-upstream facilitity to send kudos upstream >* This will require a standard metadata a field for contacting upstream > which DEP-5[11] seems to address with its Upstream-Contact field. > > - Extend thank.debian.net to send kudos upstream as well. > > - E-mail upstream after each major release of Debian apprising them of >the release and the location of the portal page where they can find out >more about how Debian is re-distributing their software. We could >note that they may find this data useful in grant applications, >budget requests, and for career development support materials. >* This could be an automated process for all packages. These should be 'opt-in' options for the upstreamer, otherwise they could be seen as spam. Cheers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009052239.57031.jesus.nava...@undominio.net
Re: possible abuse of debian and GPL
On Tuesday 27 October 2009 20:10:10 MJ Ray wrote: > richard newton wrote: > > The following site appears to be selling a computer with a modified > > Debian system. I could find nothing on the site about the OS or where I > > might get the source code. > > In one of the screenshots I noticed it was using iceweasel so I assumed > > it was using Debian. > > > > http://thegocomputer.com/index.html > > Thanks for the email. I'm not sure the debian project can fix that. Maybe it can do something: http://arstechnica.com/open-source/news/2009/09/big-gpl-copyright-enforcement-win-in-paris-court-of-appeals.ars -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian money
Hi, Bernd: On Wednesday 16 September 2009 19:14:41 Bernd Zeimetz wrote: > Giacomo A. Catenazzi wrote: > > Some months ago Debian asked for sponsored hardware: > > http://www.debian.org/News/2009/20090208 > > > > I did not read any news about his, so maybe we could use some > > money for such infrastructure hardware. > > We were and are still hoping to get at least one machine sponsored as > described - please note that a performant SAN infrastructure is REALLY > expensive. If you look at normal market prices, you start with $100k, You can get an AoE-based SAN from Coraid for much less. Not the best performer nor the most feature-rich but still it's worth have a look at it (I'm not at all involved with Coraid; just a quite enough satisfied user). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian money
Hi, Alexander: On Thursday 10 September 2009 22:11:24 Alexander Reichle-Schmehl wrote: > Hi! > > Jesús M. Navarro schrieb: > >> 4 Marketing stuff: > > [..] > > > So, if Debian can be truly so great for companies from IBM to Alfresco, > > to Oracle (and the end result can be so great for we, mere users), how is > > it that we won't have "certified" stuff from them? It can't be the > > platform or else they wouldn't certify with, say, Ubuntu. It's my > > opinion that's because while Dell's and Red Hat's (or Canonical's) CEOs > > get to play golf together that's not the case for Debian. > > So what do you propose? Spend Debian money on golf lessons for Steve? Not. But trying to get face to face with choiced high ranked bussiness people so they get to see what Debian could offer to them. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian money
Hi, Steve: On Thursday 10 September 2009 01:57:14 Steve McIntyre wrote: [...] > 4 Marketing stuff: Yes. There's a kindof "market point" I've been wishing on Debian for years "knowing" that it simply could happen: certifications and generally rising attention to commercial producers, both hardware and (free/open) software. I think there's right now a thread on debian-users of an individual asking for hardware 100% supported because of management. I know that, say, Dell certifices/is certified by Red Hat because both the companies have the management the time and the money to reach each other, talk and find their common interest points. It's may opinion that Debian is the perfect platform for them: all development being in the open you know from far away if your hardware/software will be able to play along next Stable version; if you need/want to maintain your own (free) software is quite easy to get into Debian repos (you just need to "play nice"); even if you plan to develop on the proprietary side, you will be able to use the very same tools than Debian for easy and smooth integration. Being Debian a non for profit with high ethics you can count on it not trying to stab you in the back if the wind blows in favor of your competitors... So, if Debian can be truly so great for companies from IBM to Alfresco, to Oracle (and the end result can be so great for we, mere users), how is it that we won't have "certified" stuff from them? It can't be the platform or else they wouldn't certify with, say, Ubuntu. It's my opinion that's because while Dell's and Red Hat's (or Canonical's) CEOs get to play golf together that's not the case for Debian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: time-based release freezes
Hi, Sylvain: On Sunday 06 September 2009 17:06:24 Sylvain Sauvage wrote: > Hi, > > Jesús M. Navarro, dimanche 6 septembre 2009, 16:34:45 CEST > > >[…] > > So you advocate for a 3 year release. You are aware that with a 2 year > > release and at least one year of warranteed support for oldstable you > > already get your 3 year release "for free", don't you? > > Nope. That’s not a 3 year release, that’s a 2 year release > with 3 year support. You don’t have a _new_ 3 year warranteed > support release after the 3 years of stable/oldstable Neither you get "five years support" on any other distribution if you happen to get into one on its forth support year; you only get one more year. I of course know that if releases are fixed each two years that means that on average you'll end up upgrading each two years since support for any given release will end up each two years. *But* for any given release, say that you install "foo" the very day is officially made into Stable, then you'll be able to get this very release for the next three years which is more up to the point that it might seem in the beginning since people is not so worried because the "upgrade mill" (except for really short-lived distributions) but about any given service needing to be disrupted due to an upgrade. No matter what, if only due to hardware constrains, a complex system will end up with various versions of the environment (like X, X+1 and X+2); that's usually a minor problem unless you end up having too many of them. The problem comes when you have a perfectly valid service (say, an internal mail relay) that you don't want/need to upgrade: the longer it's supported, the better for you and *this* issue (which is the one most sensible on production environments) is already managed by the oldstable support, not by avaliability of new versions. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: time-based release freezes
Hi, Stefan: On Saturday 05 September 2009 17:27:22 Stefan Krueger wrote: > Hello Debianteam, > > I hope you understand my terrible english ;) > > It is the fixed release cycles, my opinion ist that 2years are too short, > because Debian is used more as a server operating system, the people how > would like an actuelly version of an program can use Debian testing. Don't be fooled by the fact that Debian's internal development is made completly public: the only public "product" from Debian is "Stable"; everything else are "development tools" so telling "if you want to use something more current, you could use Testing" is not an answer; you should say instead "if you want Debian to be released more on time and with higher quality you could help by using Testing". > > I would make every 3years a feature freeze and every 1.5 years a > "stable-and-a-half", then the topicality also ensures version of Debian > (kernel, Xorg, etc). So you advocate for a 3 year release. You are aware that with a 2 year release and at least one year of warranteed support for oldstable you already get your 3 year release "for free", don't you? > The old stable, must be supported for 6years, has been published until the > new version(testing to stable) You mean for a grand total of nine years? If that's your point, are you aware that this would mean supporting up to eight different versions at any given point in time (four releases plus four stable-n-half)? Even with a three years grandtotal that would mean four to six releases. > I hope I could possibly give one food for thought ;) The food for mind is: where are you going to get the manpower from? And I mean the absolute manpower and the relative effect it will take on developers knowing that their efforts only will be seen on a three year timeframe and that most of their efforts will go to support "old, boring versions from almost a decade ago". It's my bet that if you tried to go that path you not only would lack the manpower now but that the project would lose manpower on the long run. Of course I would want Debian's support "for the most current software by the day I happen to deploy a new service -still it should be rock-stable; and then it would have to be supported for as long as I happen to want that system running, be it one year or a decade", but you need reality into account: even those like Red Hat that offer "long time support" do it by means of point-releases that in fact are different systems: they change behaviour on the way -and I've been bitten for such changes in the past, and their "support" for some of those changes are "upgrade to latest point release; you will have to test if any change behaviour is a problem on your environment on your own". I feel for my systems that two years between releases is just a bit too short for my taste on average but too long on fastly evolving services but I feel is quite a reality balance on average, having two years plus at least one year window for upgrade planning. As long as upgrades continue to be as sweet as they are now, I find the burden acceptable but there are problems that need to be taken care of: new hardware and services exposed to external interaction (currently they try to be taken care of by means of release-n-half kernels and volatile repo, but probably more thought and effort could go on this side). After all if you really *need* the long support (which is boring and expensive) corporations are known to be good on that part (money for boreness): you can go with Red Hat or if you really like "the Debian way" you can get it from Canonical (and you can push Canonical with your money if you feel they derive to much from Debian). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
Hi, Tollef: On Monday 24 August 2009 10:27:07 Tollef Fog Heen wrote: > ]] Andreas Barth > > | Eh. This translates to: "it is ok that the admin cannot switch back > | from insserv to oldstyle booting". > | > | And that is a statement that I heavily disagree with. I think neither > | our users nor our developers at large considers that a feature, but > | rather a very grave bug. > > Downgrades have never been officially supported, though. Isn't this > approximately the same thing? Not more than changing from/to exim/postfix is a downgrade in any of both directions. Maybe in some releases from now going back to sysrv will be considered a "downgrade", certainly not now. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
Hi, Steve: On Monday 24 August 2009 09:19:28 Steve Langasek wrote: > On Mon, Aug 24, 2009 at 08:38:21AM +0200, Andreas Barth wrote: [...] > > Eh. This translates to: "it is ok that the admin cannot switch back > > from insserv to oldstyle booting". > > > > And that is a statement that I heavily disagree with. I think neither > > our users nor our developers at large considers that a feature, but > > rather a very grave bug. > > I don't presume to know what the majority of developers think about this, > but *I* think the traditional sysv-rc boot system is broken beyond repair. > I am not at all concerned with giving users infinite choices in their boot > systems - I think there should be exactly one, which should be bug-free. > > > We should definitly continue to support oldstyle booting, at least for > > the time being. > > Why? > > So far, the only bugs that have been highlighted in this thread appear to > be bugs that happen when trying to remove insserv. If there aren't any > problems with the new system, why do we need to support downgrading? It is not "downgrading" but certainly an structure that has been there for whole decades. It is *the* expected way (not meaning that a better way won't be gladly accepted but that for quite some time it will be the "new" thingie, not the "standard"). It is quite within "the unix way" to follow the "least surprise principle". For most admins over there (i.e.: me) the new dependency-based init process will be a "let's try and see"; it certainly will come to a great surprise knowing after the fact that there's no rollback path. Following this trend the best you could do is advertising in big bold letters on the release notes that there's no way back from insserv but for concious and busy admins that will mean not the time to try the new thingie now which in turn will mean the subtle nasty bugs won't be rised. Even after decades there're still are problems on the init sequence hard to address *even* on a case by case basis by the local admin (i.e.: LVM local in order to mount root but then LVM failing on SAN volumes because network is still not ready). Be ready to discover subtle and nasty bugs on any dependency-driven init process as soon as it starts being widly adopted. Not having a rollback for those that find it the less troublemaking path seems to be not a wise decision. I'd say that two stable releases where sysv-rc and insserv should cohabitate and there's guaranteed chances to go back and forth between them is the conservative option. > > So you are telling us here that anyone who depends on the 20+ years > > working method of ordering boot with decimal numbers is using a > > regression? Sorry, but this is just plainly wrong. > > Not really. There are longstanding bugs with the sysv-rc approach that are > never going to be fixed except by migrating to a new system designed with > these problems in mind. Which in turn will bring its own lot of bugs too. > The fact that symlinks have to be changed by hand whenever one daemon gains > a dependency on another, possibly in cascading fashion, is one such bug. > > I have seen that insserv does still have some rough patches at the moment, > and I think these are documented in the BTS and I have every confidence > that they will be addressed. But I think "insserv doesn't permit removal" > is the least important of these. Maybe on squeeze+2, not now. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
Hi, Manoj: On Wednesday 19 August 2009 02:10:04 Manoj Srivastava wrote: > On Tue, Aug 18 2009, Steve Langasek wrote: > > On Tue, Aug 18, 2009 at 03:25:30PM -0500, Manoj Srivastava wrote: > >> > And really, if some logical conclusion is so broken that this > >> > brokeness has its own name, then everybody should be able to see it. > >> > >> This is a nice theory, but in reality one does see people arging > >> against the person, or their perceived personality, or their > >> traits, or ascribing motives to them all the time. > > > > Except that this is *not* the definition of the ad hominem fallacy. The > > ad hominem fallacy is claiming that a person is bad, *and therefore their > > arguments are wrong*. > > I would say it is attacking the character or motives of a person > who has stated an idea, rather than the idea itself. The most obvious > example of this fallacy is when one debater maligns the character of > another debater (e.g, "The members of the opposition are a couple of > fascists!"), but this is actually not that common. A more typical > manifestation of argumentum ad hominem is attacking a source of > information -- for example, responding to a quotation from Richard > Nixon on the subject of free trade with China by saying, "We all know > Nixon was a liar and a cheat, so why should we believe anything he > says?" [0] It's only that no matter what Cal State may say that's not an 'argumentum ad hominem' by lack of argumentation. If Richard Nixon states some facts and you pose them because of Nixon's authority (i.e.: I back those facts on the basis that Nixon said it) its acceptance becomes an 'argumentum aucthoritas' therefore is perfectly sensible challenging said authority. You cannot revoke an argumentum (i.e.: a sylogism) by appealing against the reasoner's morals but you perfectly can challenge it when it is his morals (authority, reputation, etc.) the basis of it. So, you can't challenge "if Cretans are liers and Epimenides is from Crete, then Epimenides is a liar" because Nixon said it but you certainly can challenge "China forced us into Korea's war" if all your argument is "Nixon said it". And here comes the point why it's not such a good idea point out others' logical fallaies: they are so impervous through the whole history of enlightment, from ancient Greece to-dat,e because we're are quite bad at pointing them out, so you can bet a quite significant number of such " that's logical fallacy X, let's move on" will be as wrong (and as challenged) as the argument it's pointed against. > > Pointing out that someone is being a jerk on the mailing list is *not* an > > ad hominem fallacy. Certainly it is not. But it is a matter of opinion so I don't think pointing it out will make a constructive position. > But saying that their message should not be heeded because at > some other point in the past they had been jerks is one. Discounting a > message because of a (perceived) character trait of the author is also > suspect. But very in the human character. I think it is disrecpective and unconstructive pointing out something on the lines of "I won't follow your path because I know you are a jerk" but quite proper just passing through the messages of somebody without even read them "because I know he's a jerk" (in fact, that's what scorefiles are for). > So you are saying that I misidentified some mail as an attack on > a person. Which is perhaps an argument for my point: we need to > identify that such a post has been made. I do not see the basis for > your refutation here. And who do you propose to be the "high tribunal" to state what are real logical fallacies and of what kind? Will their decision be challengellable? I consider myself not absoluty obtuse on logics but I certainly won't appoint for such a position (of course, not that anyone asked me). > > In all of these cases, the relevant question is not who makes > the argument, but whether the argument is valid. Quite true. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Hi, Julien: On Wednesday 05 August 2009 22:09:04 Julien BLACHE wrote: > "Jesús M. Navarro" wrote: > [...] > > > > Why? I really don't see your point unless you mean for the packager > > under current conditions where no real branches are allowed on Debian > > (but the > > That's exactly my point. We suck at freezing. The problem is not "we suck at freezing". Quite on the contrary I think Debian developers, the release team, the debian-installer team... all of them have done a really *amazing* work in the past, and I can say this without being suspected being just "a mere user" myself. The problem is that there's no non-sucking way to freeze the vast amount of packages and archs managed by Debian as a monolithic single entity. In the early days of Debian, the lesser number of packages and archs made (barely) possible the monolithic freeze. When people where overhauled (I think I remember it by the slink->potato or maybe potato->woody days) new tools pushed forward the frontier (and due to this package and arch numbers skyrocketeed), then the woody->sarge days again exposed the problem. The "monolithic freeze" is the simplest way both technically and from perception but maybe it's time to look for less straigthforward but more powerful ways to deal with the engineering challenges a project like Debian rises. > It all boils down to the current testing system being inadapted to our > needs. But that's something we couldn't really know for sure until we > had tried it for a couple of releases, and I think we still won't know > for a release or two because of the new tools that have been put in > place to handle transitions (and others). They might help but only on a "diminishing returns" way: it is the management itself (the monolithic freeze concept) the one that is being stretched past its natural bounds (where complexity tends to grow exponentially as the number of packages/archs -and DDs! grow just linearly). > A lot of things need to line up for a release. Debian is very large > and the windows of opportunity are few and small. True. But that adds more value to the cartesian "divide and conquer" idea for problem approaching. This, of course, wouldn't be without its own share of problems, but they would probably be less weigthening (instead of a release being done three years from the last one as is to-date the worse case scenario with current methods, you would have a "less than glamorous" but decently actualized release on time due to the shiny changes not being in time to be on board -but they'll have a new chance on next release). > Deciding on versions > of core packages between distributions could help, but a fixed-date > freeze probably won't. It could even make things worse, as it could > make it harder to iron out the issues (like having to convince the > release team to let a new upstream in to fix something because there's > really no better way). You forget that on a branched dependency path it would be quite difficult for something really nasty reaching testing (for a conceptually similar approach see FreeBSD backports from CURRENT to STABLE; No: CURRENT->STABLE->RELEASE is not the same as Unstable->Testing->Stable although it might seem at first glance) and, of course, everything (but death) can have its (rare) exceptions. > Seriously, everybody gets bored and fed up > during a freeze. Not because of the freeze itself but because it takes so long. Again, i.e. FreeBSD devels don't feel that pain and they still manage to produce quite robust releases. > I am of the opinion that no matter how hard you try, you can't *make* > a Debian release happen. I never thought about it that way but I think you marked the bull-eye. I think to remember something Schopenhauer said once about intuitions. And then, following Schopenhauer on this, although you cannot "make it happen" you still can make it easier for it to happen. > There's some point at which the release > starts to happen, a point where a critical mass of DDs is reached, the > point where everybody uses the word "release" more than any other > word. All of which have some very real technical grounds and a heavy psycological nature too. Just the fact of being seriously comitted to a time-based release instead of current "we aim towards this or that date" that nobody takes really seriously but as a wishful grosstimate would heavily help for the critical DD mass and the "going for the release" attitude to happen. > > > to push it to a latter date in order to have time for the tools to be > > developed (hey, Mr. Canonical, there you have a very interesting case > > wh
Re: On cadence and collaboration
Hi, Mark: On Wednesday 05 August 2009 23:28:19 Mark Shuttleworth wrote: [...] > I think most are waiting to see if Debian and Ubuntu can do this. If we > can, I am very confident we will get a group of other distributions > participating in the version harmonisation discussions in the first > round. To win Novell we would have to actually demonstrate the process > works, I think. And to win Red Hat we would need to demonstrate it works > with everyone else first. At least, that's my impression from > conversations to date. I don't think too many conversations are needed to reach such a conclusion but plain common sense: Red Hat is the big guy in this yard and it's a for-profit company (just like Canonical) so, at least in the short run, it benefits from their bussiness enemies (like SUSE or Canonical) to stay divided and flakey. Only in the case that their competitors make a deal that can put in danger their lidership they'll contemplate going into the fest if only to leverage the field. On the other hand Canonical it's obviously the company that benefits the most with such maneouvre (not saying this is a good or bad thing 'per se': bussiness are there for the profit and in this specific case I'm inclined to think that, properly managed, Canonical's benefit is quite aligned with Debian's and even the Linux user comunity as a whole one). On the other hand and being quite cynical, if it would happen the "freeze at a time" among Red Hat, SUSE and Canonical, being all of them for profit, this would be a very unstable equilibrium since they all would be very pushed into cheating to their own advantage (hey! you released one week earlier... yes, but you launched your press release two weeks in advance! etc.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Hi, Jan: On Wednesday 05 August 2009 21:53:20 Jan Hauke Rahm wrote: [...] > > I'm interested in the reactions of other distributions. Are they likely > to change their release cycle to fit yours? Or would you be willing to > change Ubuntu's release dates if SuSE proposed LTS releases to come out > in odd years or similar? Remember this is basically a meritocracy and that open sourced software tends to grow like a snowball down a hill: the first to do something seen as useful on a less than stinky way will "attract" attention and activity around him. Even know it's working just that way: why is it Shuttleworth now gossiping about time-based releases but because he believes on its value, probably based on ideas developed out of the fact of Ubuntu working -and working well, at least on his eyes, that way? That's why I said something in the lines of "don't worry about Red Hat, SUSE, whatever..." if you go and do it, you'll show it's possible and if it's useful others will "jump" onto your backseat in due time... and if it ends up not being so useful/good idea, well... hours and hours wasted on comitees to reach consensus won't make it any better anyway. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Hi, Marc: On Wednesday 05 August 2009 22:24:56 Marc Haber wrote: > Hi, > > On Wed, Aug 05, 2009 at 09:32:36PM +0200, Jesús M. Navarro wrote: > > In other words: freeze on december the first doesn't mean that if, say, > > Gnome will publish it's new shiny 1.2 version by december the 15, the > > last beta should have to be included, but that the december version will > > ship version 1.1 (or whatever is the previous known to work stable). > > It's up to the upstreamer to decide if next time they will publish by > > november the 15th instead of december the 15th so their latest greatest > > gets to be shipped. > > So we basically force a time-based release schedule upon our upstreams > when we do time-based freezes? I am not sure whether upstreams are > going to like this. Force? No!!! How in hell could a user (a user of a royalty-free, freely distributable software no less) force anything on the provider? It's the other way around if any! *BUT* you give them information, you know information is power, and they can do with it whatever they see fit. They don't need to change their schedule, they don't need to care about a distribution at all, but you give them an (hopefully) easy to understand and remember schedule *in case* they want to take it into account. On a different message Julien Blache states that "The freeze date for the past few releases has always been known in advance and refined as we went" but that's only true for Debian users and developers and even then not for any Debian user but only those really interested on the march of the distribution. On the other hand, I know Ubuntu produces new versions each six months about april/october or OpenBSD more or less the same and I don't even use them. I never went to the Olympic Games and still I know they are every four years starting from 00, but I'm Catholic and I don't know the dates of next year's Holy Passion but that it will be about mid spring (I put this examples because they both are time-tied but while Olympics follow an easy rule, Holy Passion follows a convoluted one), see the trend? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Hi, Julien: On Wednesday 05 August 2009 20:42:03 Julien BLACHE wrote: > Manoj Srivastava wrote: > > Hi, > > >> From the very start of the Debian Project, Debian has been different > >> from everything else: different package management tools, different > >> philosophy, different organization, you name it. > > > > But most of these will not be lost if we have a time based > > I think we'll lose part of the "we release when it's ready" philosophy > (that our RMs seem to despise so much). Because part of this is to > freeze when it's ready. Not at all if done properly. Freeze on a date simply means that what it's ready on that date is included, what it's not ready won't be included, simply as that. When you couple that with a freeze date well known in advance, you allow interested people to plan properly. In other words: freeze on december the first doesn't mean that if, say, Gnome will publish it's new shiny 1.2 version by december the 15, the last beta should have to be included, but that the december version will ship version 1.1 (or whatever is the previous known to work stable). It's up to the upstreamer to decide if next time they will publish by november the 15th instead of december the 15th so their latest greatest gets to be shipped. The fact that they'll know well in advance when the freeze is to be expected is what will allow them space enough to make a savvy decision while now, with the "freeze when ready" is a matter of luck and a point of friction (pleeease, wait for another two weeks for our new and shinny). > A time-based freeze could mean for some teams that they'll have to > stop work basically for months to a year. It already takes too much > time to recover after a release, this won't help. Why? I really don't see your point unless you mean for the packager under current conditions where no real branches are allowed on Debian (but the everbody's bag that it is 'experimental' that has demonstrated not to be a solution at all). This needs to be changed and I expect the time-based freeze to be the tick that will finally push this change. I envision a system where a new upload will create kind of a branch and trigger a dependency cascade where all dependent (depend, suggest and recomend) packages are alerted so their maintainers can test for obvious problems and ack the upgrade or release a new change on the branch that again triggers the dependency cascade for its dependants. Once everybody acks or upgrades the whole branch gets commited into what currently is "testing" (the ack mech will in turn help for the MIA case: an unanswering maintainer would -under proper conditions, automatically meant for the package to be orphaned or even retired; a maintanier whose last package goes that way would be automatically marked for MIA process). This way, you could freeze testing almost any day without problems (and Ubuntu could easily go on their own if in the end that's better for their interests, since the health of testing would be much better any day going almost without the "upgrading storms" current process almost guarantee on testing from time to time). If that's what you meant, I think you don't have an argument against time-based freezes but against the "first time-based freeze on Dec-2009" but to push it to a latter date in order to have time for the tools to be developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). > In this day and age, you have to look at features in addition to the > version number, because the latter isn't necessarily very telling of > the real changes from one release to another. Major features are > delivered in minor releases nowadays... I already said that to be simply malpractice and beyond a distribution's ability to correct (while I'm with Shuttleworth in that concurrent freezes would help to "show the proper path" to upstreamers). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Hi, Mark, I'm glad you took towards this list the effort of this message: On Wednesday 05 August 2009 11:21:38 Mark Shuttleworth wrote: > Hi folks > > I've stayed quiet in this discussion, though several folks have invoked > my name and ascribed motivations to me that were a little upsetting. I'm > not responding to that here, instead I'd like to focus on what we can > achieve together, and how we can lead a very significant improvement in > the health of the whole free software ecosystem. > > Apologies in advance if this mail is lengthy and not particularly witty! The issue at hand it quite witty too, so I wouldn't take you for guilty (Wow! now I re-read my own message, it seems a perfect example on what NOT to do on the executive/project sponsor level -I hope, while I can't expect, you'll show the patient to read this to the end). > Imagine you are the leader of a key upstream component. You care about > your users, you want them to appreciate and love the software you write. > But you also know that most users won't get the code from you From my experience that's not usually the case. As already stated, it's more "you are not using last week's version, go figure for yourself". I already told my opinion (on a more "hatred" and witty way) here http://slashdot.org/comments.pl?sid=1318967&cid=28922369 so I won't repeat myself. > I hear this story all the time from upstreams. "We'd like to help > distributions, but WHICH distribution should we pick?" That's a very > difficult proposition for upstreams. They want to help, but they can't. > And they shouldn't have to pick favorites. The main point of my above URL is that basically most upstream projects do not plan in advance for long term maintenance (neither regarding their own code -that's basically why Debian is forced to backport instead of using the bugfixing branches from upstreamers) nor regarding their environment (while I can understand why they do it, it's still no good practice, maintenance-wise, using the bleeding-edge code from toolkits, libraries, etc. they depend upon). > Adopting a broad pattern of cadence and collaboration between many > distributions won't be a silver bullet for ALL of those problems, but it > will go a very long way to simplifying the life of both upstreams and > distribution maintainers. If upstream knows, for example, that MANY > distributions will be shipping a particular version of their code and > supporting it for several years (in fact, if they can sit down with > those distributions and make suggestions as to which version would be > best!) then they are more likely to be able to justify doing point > releases with security fixes for that version. I think your point is quite a sensible one and shows why you have been a successful entrepeneur (it shows "soft" abilities towards making things happening) but still I don't think that's something distributions need to be strongly looking after. If distributions A, B, C take version X, Y, Z from the upstream project "Foo" is mainly because such project doesn't provide clear notions on why X should have to be preferred over Y or Z. On the upstream projects that already do so, distributions do already take the published version that better fits their mood and intentions. For instance, disregarding end user misinterpretations, KDE is quite good and consistent -while not perfect, about their versioning policy and as a result of this, Debian decided not to rush for KDE 4 on lenny but still stay on the rock-solid KDE 3.5 while other, more edge-adicted distributions (like, say, Fedora) would start distributing KDE 4 and since the upstreamer properly does its homework it's all well and good. So, resuming: it's good for distributions that share some kind of "spirit" to somehow mildly try to converge on versions as a way to combine efforts and "show the path" to upstreamers while certainly it's still upstreamer's right and responsibility to do things properly -or not. > We're already seeing a growing trend towards cadence in free software, I don't think it's a free software property but that it's the proper way to go for these kinds of project (aided with proper dependency cascading and branching). The "problem" here is that the proper cadence for each project and even for a single project on different times it's their own so either the upstreamer does its homework the proper way or you won't be able to find the minimum common multiple you need to get stable and maintained versions for the thousands of packages that make up a distribution in a hundred year period (I speculated once on a "best practices for a project from distributions point of view" and the ability to declare some software projects as "blessed" and so preferred for a given task and managed on different, more efficient ways... but I'm disgressing) so, again, go with your "soft" abilities but don't worry about it too much (it's not on your hand, anyway). > OK,
