From owner-freebsd-ports@FreeBSD.ORG Thu Sep 1 21:47:47 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 412D5106564A; Thu, 1 Sep 2011 21:47:47 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93AC48FC13; Thu, 1 Sep 2011 21:47:46 +0000 (UTC) Received: by fxe4 with SMTP id 4so1440496fxe.13 for ; Thu, 01 Sep 2011 14:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=BigBrTMElw2YeSP56rK9LXKHhMty8NAj8odcnJE8ark=; b=d2JdN1KwT/ZyY/TScITwZ0V/Pht6a2OSaXGOFvFcpfKjgzjE8WT/Uu8G3f4cNrKMLf n+Ccf111/LLMLokYio/A1EvzsbnsT9rg5JTKbBRw0Z85NKaWQwigb0X2vWWYZlLdQ9WH kXP5X7wgqUfRqc/1a0oeYfdQ66F8eGDstBU28= Received: by 10.223.75.154 with SMTP id y26mr454349faj.104.1314913665551; Thu, 01 Sep 2011 14:47:45 -0700 (PDT) Received: from [10.0.101.2] (254.166.broadband10.iol.cz [90.177.166.254]) by mx.google.com with ESMTPS id c5sm136322fai.20.2011.09.01.14.47.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 14:47:43 -0700 (PDT) From: Michal Varga To: Mark Linimon In-Reply-To: <20110901092349.GB9509@lonesome.com> References: <20110828181356.GD277@magic.hamla.org> <20110828183300.GX17489@deviant.kiev.zoral.com.ua> <20110828184542.GE277@magic.hamla.org> <20110828152234.54cc9fac@seibercom.net> <20110828193046.GA668@magic.hamla.org> <1314564889.82067.89.camel@xenon> <4E5AB672.4020607@FreeBSD.org> <1314585798.82067.338.camel@xenon> <4E5B0EFB.6000900@FreeBSD.org> <1314596096.82067.419.camel@xenon> <20110901092349.GB9509@lonesome.com> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Thu, 01 Sep 2011 23:47:40 +0200 Message-ID: <1314913660.1744.136.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Doug Barton , freebsd-ports@FreeBSD.org Subject: Re: Ports system quality X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 21:47:47 -0000 On Thu, 2011-09-01 at 04:23 -0500, Mark Linimon wrote: > On Mon, Aug 29, 2011 at 07:34:56AM +0200, Michal Varga wrote: > > - While nobody probably cares much about that guy and his missing > > browser images, what would you tell to the GIMP guy? That he should have > > waited longer before upgrading the (for him, 30 levels deep) "Foo" > > dependency? With furious client breathing down his neck and everything? > > Either we want to have ports as a "big repository of colorful stuff that > > even builds", or we want to have some actual products that people can > > use after they build them. And that needs an additional level of quality > > control that FreeBSD currently, and horribly, lacks (patches welcome, I > > know). > > In that case, you should not be updating that rapidly. I've covered that aspect earlier in the discussion. There is no option to 'upgrade less rapidly', as at any single point in time, there is *always* something that just hit the tree moments before. This would require all ports users always perfectly know every single port in their systems and have detailed knowledge about what exactly every single dependency does, affects, and when it's safe to upgrade this or that, and how soon to do it after a particular (and every single) commit. And letting other people get burned while simply "waiting it out" doesn't a quality control process make. Just stating the obvious. [And to cut it right here - no, answer to that is not "Ok, so everyone should be a tester then". This never worked anywhere outside of dreams and wishes. And no other sane project does, nor tries to go this way.] > IMHO you should look at installing PC-BSD, who has a release process > where they go through the apps based on a stable state of the ports tree, > based on paid employees. Telling people to go using different operating systems when they point out some shortcomings in FreeBSD was already pretty old some decade ago. While I'm not the kind of person to get in any way offended by it, I can easily imagine why so many get bittered by such 'suggestions' and eventually just leave for good. If I was looking for another OS, I wouldn't be wasting all this time pointing out what's broken on FreeBSD (or more specifically, in FreeBSD ports), I would be spending that time migrating, as I would have my options long time researched by then (which I have, actually, as significant part of my work depends on fully working desktop systems and FreeBSD no longer cuts it in that domain for some time). > > - That particular maintainer of Foo graphics library should be forced, > > by threats of violence [...] > > And what happens if he doesn't respond to the threat? We fire him? > > Look: you can't fire volunteers. Only employees. Yes, and you now single-handedly discovered what's the major point of failure in the current system (and I don't mean that as a sarcasm, nor making fun of anything). While I was making a hyperbole with all the violence and stuff, it still boils down to this. Nobody is really steering this ship anymore and it just happily rams icebergs along the way, with volunteers occasionally throwing buckets of water (and sometimes pieces of furniture) overboard to somehow keep it afloat for a while longer. The current mechanisms for dealing with ports (and their maintainers) were put in place ages ago in different times and with, frankly, somewhat different people around [citation needed]. Over the course of time, amount of ports grew by magnitudes, dependencies, especially for desktop environments grew by magnitudes, and maintainers are no longer the special dedicated bunch of highly motivated people that know every single port and their whole ecosystems inside-out. This is no longer even possible, among other issues (and there are few). But the system in place still pretends things work this way. They don't. Ports are failing, horribly. And it's not the concept that is wrong, it's the execution. Or more like, lack of any proper. But I'm all fine with pretending that nothing really happens and that few more automated -exp runs will save all and forever. Another five years from now, when FreeBSD definitely sinks into the realm of 'irrelevant' and when the finger pointing finally (and way too late) starts, I'll just bring some popcorn and quietly watch the show, just so that I don't offend someone again with my unsubstantiated whining. > And let's say that I, as portmgr, tried to impose some kind of rule > about what's going to happen to you if you don't do things my way. > The upshot? The volunteers will just leave. (They get mad when > portmgr tries to bring some sanity to certain chaos-filled areas, as > it is.) Yes, and I remember some of 'those' situations. As we - the people who 'don't actually do the work' but sometimes actually use this system - for this or that reason even somehow keep track on what's happening around, as it's affecting both our short- and long- time FreeBSD decisions too. But you're just not doing enough. Doug too doesn't realize he isn't doing enough, and only now tries fixing some of the consequences of the broken system instead of focusing on the root causes. But that's way too late, way too little. So in the long run, nothing will change and FreeBSD ports will just keep rotting, failing and breaking further. But at least, they will compile better. That's so 2011. > And why would anyone new agree volunteer to maintain a port if they knew > that someone was just going to dump on them when it didn't work? I would anytime, and in fact I would never expect any less than the approach you just described. I can't obviously speak for anyone else. For me, it's perfectly obvious that volunteering or not, by joining "the system", there comes responsibility - at least in the minimum - for not breaking other people's stuff. Maintaining a dependency means exactly that - other people are DEPENDENT on *you* (and your port). If one can't bear that responsibility and act accordingly to it, they shouldn't be doing that job in the first place (and yes, should be fired if they can't realize it on their own). Even if there is no one better to do it. Advertising (however randomly) breaking and failing stuff as working, only because there is currently no one else to do it proper, just, in minds of bystanders, turns FreeBSD into some kind of weird parody of Windows Millennium (yes, it's not that much fun advocating FreeBSD these days as it was 10 years ago). And this is not a way that will win you new volunteers, they will simply flock volunteering for projects that work better. > You're not looking at this from the point of view of the people who > actually do the work to bring you this system. > > mcl You would be surprised about how much I've done to bring me (or anyone else) this system even through my every odd post doesn't come with a full @freebsd resume for the past 15 years (hey Doug, don't take it any personally). My point of view is slightly wider than you're implying, but I'm not going to back that up by bullets of "what I have ever done". If what I wrote is not sufficient on its own, then that makes it one less reason to spend any time with it at all. I'm really not going to explain why. But not being part of the "golden club" allows me to speak more freely about things right as the are now, without fears of offending half of my @freebsd buddies (as I obviously don't have any) and getting torn apart on IRC after. That probably makes me state some things in ways that are not very popular these days, but honestly, I mean no offense. Just that padding my emails with "I really love FreeBSD!" and "All of you do a great job and I love you too!" every odd paragraph would make for even more boring reading than this here now. m. -- Michal Varga, Stonehenge (Gmail account)