What is the problem with ports PR reaction delays?

Aryeh Friedman aryeh.friedman at gmail.com
Sun Jan 26 18:21:14 UTC 2014


just do us a favor and do not assume newer means better...


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
>
>
>


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


More information about the freebsd-ports mailing list