What is the problem with ports PR reaction delays?
aryeh.friedman at gmail.com
Sun Jan 26 02:18:10 UTC 2014
On Sat, Jan 25, 2014 at 9:04 PM, Alfred Perlstein <alfred at freebsd.org>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
>>>> to do (get new ports into the system)... to that end automating
>>>> that can be automated is sure help free up comitter time so they can
>>>> at what is interesting
>>>> Yes. I just can't imagine any generic port tests that can't be
>>> 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
>>> 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
I am sorry your the one who does not get it.. not everything is either
testable remotely or should be... how do you propose to test device drivers
> Why? Because then we offload the problem to another org.
With a hybrid cloud with most of the work being done on the
commiters/developers machine where is the overhead?
> The FreeBSD project should be about innovation in OS design, platform and
> software. Ops work is bunk and just slows us down.
Sorry to tell you but the ability to handle a complex automated system is
one of the key things a OS must do... what better test then to build it
> The more we can outsource the better we'll be. (and what if that service
> blows up? well we move on! it's simple!)
What a total cop out if the service blows up fix it... or should we end up
with some of the real atrocities of linux like I/O times that are
impossible (claiming it takes less then a second to copy 10GB for
example)... note the above timing issue it makes resource scheduling next
to impossible in a distributed environment if you get different timings for
the same operation... bottom line writing and maintain a OS *IS* about
operations and nothing else.
> 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 never said our selves it is outsourced to the developer/maintainer with
100% automated stuff... once I am doing with the next small version of
petitecloud I will post the 6 line script we use to test the port
(including cranking up a few vm's)... have fun doing that anywhere else
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
More information about the freebsd-ports