What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14 5:25 AM, Big Lebowski wrote:
>
>
>
> On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein <jim at ohlste.in 
> <mailto:jim at 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 at rawbw.com
>             <mailto:yuri at 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.
>

Thanks Big Lebowski <spankthespam at gmail.com>!

I'm not sure if taking your word for it will be the be all and end all 
of progress on this issue.  I do have hope, after all as Max Plancksaid:

"A new scientific truth does not triumph by convincing its opponents and 
making them see the light, but rather because its opponents eventually 
die, and a new generation grows up that is familiar with it."

I just have my fingers cross that we are not so insular, so heels dug 
deep in the dirt, and so curmudgeonly that we drive away anyone 
interested in new technology.

I mean, if we're all so firm in our beliefs there are dozens of other 
open source projects that encourage new things that people will flock to.


-Alfred