What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14 10:21 AM, Aryeh Friedman wrote:
> just do us a favor and do not assume newer means better...

I've been using newer almost exclusively for the past several years and 
it is better.

Open your eyes, people have moved on.


-Alfred


>
>
> On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein <alfred at freebsd.org>wrote:
>
>>   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> 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> 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> <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 Planck said:
>>
>> "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
>>
>>
>>
>