What is the problem with ports PR reaction delays?

[Aryeh Friedman]

On Sun, Jan 26, 2014 at 10:00 PM, Alfred Perlstein <alfred at freebsd.org>wrote:

>
> I'm not addicted to newness.  I think you just hate anything that is
> popular and you're butthurt that something that's may have been ahead of
> it's time was missed out on.  This is no reason to dig your heels in and
> complain as that accomplishes nothing.
>

I don't hate everything that's popular.  For example, I use various popular
applications such as Open Office and xfce, and I use Java.  What I hate is
stuff that doesn't work as advertised, no matter how popular.

If popularity and hordes of "code monkeys" (as you insultingly call them)
are so important to you, then why are you using FreeBSD instead of
Windows?  Better yet, if you like newness, how about Windows 8?


> What I am interested in is:
>
> 1) leveraging the hordes of people that can submit changes to the project
> because they know git.
>

This is a non-issue because, even if the ports team uses aegis and cook,
the average port maintainer can still use svn and makefiles or whatever
build tools they like.  So the only important question here is whether
aegis and cook can save a lot of time and trouble for the ports team
specifically.


> 2) leveraging the existing tooling that's available for FREE!!! for us to
> use. (instead of rewriting wheels).
>

Perhaps you missed this, but aegis and cook are both free and open source
(GPL).

3) reducing the overhead of contribution to our project by using existing
> solutions and not requiring accounts to be made.
>

Even more reason NOT to go with something that is relatively new and
largely untested in mission critical applications.  Aegis, though not
popular, is used in not just mission-critical but life-critical
applications, i.e. things that absolutely must work the first time and
every time.  For example, one aegis user is St. Jude Medical.

Have you actually installed and tested aegis are you just bad mouthing
it?   The reason for asking is it was designed on purpose to be a
plug-gable architecture... namely all aegis does except for enforcing the
dev/review/integrate cycle is act as a glue for *EXISTING* tools (see the
manual for a full list of ones supported out the box and the requirements
new ones must meet [note cook is used not make only because make is not
powerful enough to take full advantage of aegis]


> So what would using this aegis system buy us?
>

See http://osdir.com/ml/version-control.aegis.user/2005-05/msg00001.htmlfor
a discussion of using it in linux kernel development


> 1) doesn't have hordes of people that know how to use it.
> 2) doesn't have a free hosting solution for it which provides tooling we
> need for free.
>

Why does an internal version control system need any kind of web hosting at
all?  Be that as it may, aegis does have a web front end -- including RSS
feed and other XML output -- as well as its command line interface.


> It's not about NEW THINGS, although NEW THINGS tend to lead to better
> systems... it's more about leveraging users and existing facilities.
>

?!?!?!?!? How the <bleep> does forcing everyone to learn something new
every 6 months lead to the ability to leverage existing users and
facilities... maybe my logic is faulty but isn't this almost a guarantee
that no one will know what they are talking about because stuff moves too
fast for them to keep up?

I would rather see a list (even if a small list) of solid users who all use
the system for mission critical apps (like hospitals).


> Anyhow, it's not important, you want your toy, even though no one uses it.
>  Enjoy it. :)
>

For a list of some aegis users (every single one uses it for mission
critical systems) see http://aegis.sourceforge.net/propaganda/sites.html

>
> If you want to be part of an "exclusive club" that only uses esoteric
> tools and home-built Rube Goldberg scripts to accomplish what people are
> doing with modern tools in less than half the time


Aegis itself does not require scripts, although it can be used to
encapsulate scripts.  Every routine action (including distribution of
baselines) is already encapsulated into a single command that typically
requires only one or two arguments, in contrast to the much more
complicated command lines associated with github's api (via cURL).  For
example, we use the following command line to create a new release of
petitecloud:

      aeb cook-blank/deploy-remote

and a normal everyday build requires just:

     aeb

.... and in the same conversation be annoyed that there's a lack of people
> signing up to work under those conditions then you need to take a deep
> breath and look in the mirror.
>
> When your toy has a huge community that fulfills the requirements that I
> have I'll check it out.  When switching to Aegis gets FreeBSD the same
> benefits of the github community and "millions of code monkeys" I'll be
> cheering for it.
>

If having a million "code monkeys" is the mark of a good system, does this
mean you regard healthcare.gov as a supreme master piece of software
engineering?  After all it has 500 million lines from god knows how many
contributors... therefore it must be better?

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