Date: Sun, 26 Jan 2014 14:25:46 +0100 From: Big Lebowski <spankthespam@gmail.com> To: Jim Ohlstein <jim@ohlste.in> Cc: Alfred Perlstein <alfred@freebsd.org>, Aryeh Friedman <aryeh.friedman@gmail.com>, freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: What is the problem with ports PR reaction delays? Message-ID: <CAHcXP%2Bfk2T1%2BoYW45BjcimujedJJ2uE%2BS-FutGbyam2i3QRnog@mail.gmail.com> In-Reply-To: <52E47EF7.7040402@ohlste.in> References: <CAHcXP%2Bf6e-t--XbQPTH1goJp_CL7P=zTj5trZVWd4YZ_EsO9gw@mail.gmail.com> <CAGBxaX=t3e5SXoBDHnzAbx=SWbEFMJHNPQL13FnwNgKWM3gCiA@mail.gmail.com> <CAHcXP%2Bew5qt5hc9Y%2BR_njPkfhUMsDDAqNk9aYSacV4PwBmqjfw@mail.gmail.com> <CAGBxaXnXwo4JxnRdffZfdvfETfhgJNkFM-N23H1SOT0G3-oMwA@mail.gmail.com> <CAE-m3X2dQTTsbrTJg2iPT3qkfq7h9U8oGbRZXGAXH%2BJ2T4MFNw@mail.gmail.com> <CAHcXP%2BdtHPHT%2BFD8RdcqhGANBPf1Gk4N4coEpZY-eAuQE3iZtg@mail.gmail.com> <CAE-m3X2rWk-0k_yH1PK0iN_5YhvSh1UsV0VCrroJq==687X1ZQ@mail.gmail.com> <52E43A80.4030501@rawbw.com> <CAGBxaXnfb2yPZZCaf6mYzASzT13b68A8iPT6eUwUdU9W1ya_Qg@mail.gmail.com> <52E44BC1.7040404@rawbw.com> <CAGBxaXkCWAAfA%2B7x9-icTwO4Vd78EGOeh5-4eG3DUJ_gGVHT1g@mail.gmail.com> <52E46D44.6050403@freebsd.org> <52E47EF7.7040402@ohlste.in>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein <jim@ohlste.in> wrote: > Hello, > > > On 1/25/14, 9:04 PM, Alfred Perlstein wrote: > >> On 1/25/14 3:48 PM, Aryeh Friedman wrote: >> >>> On Sat, Jan 25, 2014 at 6:41 PM, Yuri <yuri@rawbw.com> wrote: >>> >>> On 01/25/2014 14:44, Aryeh Friedman wrote: >>>> >>>> The key seems to be that no one has time to do the stuff they really >>>>> want >>>>> to do (get new ports into the system)... to that end automating >>>>> everything >>>>> that can be automated is sure help free up comitter time so they can >>>>> look >>>>> at what is interesting >>>>> >>>>> Yes. I just can't imagine any generic port tests that can't be >>>> automated >>>> and coded into the script once and for good. >>>> Ideal system should be like github with the added automated testing >>>> between pull request submission and merge. It should either fail and >>>> notify >>>> the submitter, or succeed and notify the committers. >>>> >>>> Git hup (or *ANY* remote service for that matter) is a no go IMO >>> >> >> You just don't get it. >> >> Again, you just really, really, don't get it. >> >> You WANT a gateway to a remote service that the project does not have to >> handle. >> >> Why? Because then we offload the problem to another org. >> >> The FreeBSD project should be about innovation in OS design, platform >> and software. Ops work is bunk and just slows us down. >> >> The more we can outsource the better we'll be. (and what if that >> service blows up? well we move on! it's simple!) >> >> Continuing to insist that we run the services ourselves it just wasting >> our limited resources. Not only that but we get emotionally attached to >> technologies that are old, dying and dead when off the shelf stuff works >> just fine. >> > > I've read all 60 or so messages in this thread and there really are two > related but distinct issues here. > > The thread title is "What is the problem with ports PR reaction delays?". > This has meandered into a philosophical debate about who knows what and who > knows squat about version control systems, whether we need to maintain > certain requirements, testing ports, etc. > > I like the KISS approach myself. This can be boiled down to those two > issues, one of which is a symptom of the other. Arguing and debating over a > long term solution to the OP's question does nothing to solve the problem > in the short to intermediate term. There are 1680 current ports related > PR's at this moment. > > As we all know, the committers are volunteers, mostly with real jobs and > real lives and they obviously cannot keep up with the current load. The > short to medium term solution for that is more committers. I'll add my name > to the list of those who are willing to step in and help to clean up the > mess. I'm certain that if a request went out, there would be many who are > more qualified than I. > > At the same time, a group of interested individuals should offer input to > the folks who already are looking at changing the bug reporting system away > from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan. > Doing it in one fell swoop might make sense. It's "ripping off the bandaid" > but I'd rather do it only once myself. > > What does *not* make sense is a new port for what might be a very useful > tool waiting since September for someone to look at it. Arguing over git > and subversion et alia does nothing to fix that. As they say on the ESPN > NFL pregame show, "C'mon man!". I can't agree more. I can see, understand and accept reasons why we cant move from SVN to GitHub/Git and I certainly dont think that it would be solution to current problems. It seems like this is not neccessary, it wont happen, so I think we can end that discussion here. However, we do have all the tools to automate this process, so I really dont understand why not to do this, especially it is perfectly doable with SVN, Redports are already doing so, and there are people willing to work on it. And when it comes to number of ports commiters, that seems to be too low to handle current, manual process, why exactly this number is so low? I would think there is not enough skilled people, but given Martin mentioned there are sloppy commiters not doing their work exactly right, this doesnt seem to be the case - what then? Could that process be more formalized, transparent, so people interested could have a path to follow and the ability to become commiters to support the ports team? I've mentioned the idea of 'junior commiters' in my previous message, perhaps that's something we could talk about? One another thing I would do, is to handle the problem of amount of the work that needs to be done, that tends to be a huge demotivation for people to do work - when there's over 1600 PR's waiting to be handled, it seriously harm the hope for getting the work done (emptying the queue) and that's a stopper. Perhaps it would be possible to make a cut off for PR's opened more than X weeks/months/years ago, their submitters arent answering to emails, their emails are dead, neither submitters nor other users are asking for, send emails to submitters and ports list, that in case of no response withing X weeks those are going to be closed, and then handle those answered, and close the rest? Apparently no one takes care about them on commiters side, original authors do not care anymore, and community doesnt need them, because no one is asking about them, and no one submits them again - what's the point of keeping them around haunting productivity and blurring the view of how much work is to be done for real? I know this might seems to be radical, but waiting monhs for a port to be looked at is nonsense as well. And thank you all, who had expressed their views, I hope we can work out a viable solution that will serve for better good for everyone. Regards, B. > > > -- > Jim Ohlstein > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHcXP%2Bfk2T1%2BoYW45BjcimujedJJ2uE%2BS-FutGbyam2i3QRnog>