On 1/26/14 10:32 AM, Aryeh Friedman wrote:
Forgot to mention and aegis in almost every case implements the very
same features in a much smoother way (no stupid http bs or anything)
If aegis is so much better then we should use it. Or everyone should
use it... but why isn't everyone using it?
Can you explain?
Seriously, if it's so much better then please do tell!
-Alfred
On Sun, Jan 26, 2014 at 1:31 PM, Aryeh Friedman
<aryeh.fried...@gmail.com <mailto:aryeh.fried...@gmail.com>> wrote:
If it is so new then why when I looked into git and git hub for
the first time about 2 years ago it didn't have a *SINGLE* feature
that aegis didn't have in the mid-90's... all it is a bunch or
pretty pictures to make those who are addicted to newness be able
to claim they are actually making progress with their "newness"
when in fact they are reinvinting the wheel for the 15th time
On Sun, Jan 26, 2014 at 1:26 PM, Alfred Perlstein
<alf...@freebsd.org <mailto:alf...@freebsd.org>> wrote:
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
<alf...@freebsd.org <mailto:alf...@freebsd.org>>wrote:
On 1/26/14 5:25 AM, Big Lebowski wrote:
On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein
<j...@ohlste.in <mailto:j...@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
<y...@rawbw.com <mailto:y...@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 <spankthes...@gmail.com
<mailto:spankthes...@gmail.com>>
<spankthes...@gmail.com <mailto:spankthes...@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
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
