What is the problem with ports PR reaction delays?

Aryeh Friedman aryeh.friedman at gmail.com
Mon Jan 27 07:18:05 UTC 2014


On Mon, Jan 27, 2014 at 1:59 AM, Alfred Perlstein <alfred at freebsd.org>wrote:

>
> On 1/26/14, 10:56 PM, Aryeh Friedman wrote:
>
>
> On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein <alfred at freebsd.org>wrote:
>
>>
>> I'm not sure, I'm going to go load up healthcare.gov to see if I can
>> order myself some free aspirin after this "discussion".
>>
>
>  At least my build system has never caused me to need an aspirin (normal
> debugging is bad enough).  Sarcasm aside, to bring this thread back on
> track, the important issues are:
>
>    * The development model used by aegis is likely the cleanest
> development cycle I have seen (main reason for this is Peter Miller is one
> of the few SCM and build management theorists [vs. just hacking something
> til it works]).   The model is namely (repeat as needed)
> develop->test->review->integrate... note that test comes before review for
> the simple reason to even get to review you must build correctly and pass
> all your own tests (isn't this the main goal of automating the port system
> anyways)... also keep in mind we can use this model without necessarily
> switching to aegis per se.  With or without aegis, it would save the ports
> team a lot of time to be able to build and test a port automatically before
> they spend any time reviewing the code.  Aegis, by default, enforces this
> model.
>
>    * GitHub *REQUIRES* all developers (including all port maintainers --
> not just the committers) to switch to GitHub.  On the other hand, if the
> ports team were to use aegis and/or cook, this would NOT require any
> changes at all from the POV of maintainers.  Even on the ports team, most
> members would need to learn nothing more than 6 new basic commands...
> (portmgr@ would need to learn a lot more though depending on what kind of
> non-standard processing needs to be done in integration).
>
> Using git doesn't require switching to github.  I'm not sure what you're
> smoking that's leading you to believe that, maybe you should also try to
> log onto healthcare.gov to figure out what's causing your level of
> confusion!
>

Again not 100% correct. it does require you to have githup-like
functionality (githup or a clone of it) if you want to do any sort of
distributed repos... aegis does not (all of its distributions are in normal
formats like tar.gz and patches [these are automatically generated on
demand])... and more importantly your solution seems to revolve around
requiring the use of a tool over the model that it enforces (which can be
done by many different tools).... have you ever heard of making your
requirements technology neutral and *THEN* seeing what techs (if any) fit
the bill... this is how we found aegis in the first place...   in some
cases we may find (and I think the current port system may be one of these
cases) that no new tools are needed; all that is needed is the reorganizing
of existing manual procedures (which can then later be automated if
desired).


>    * If there are modifications to the overall port system, switching to
> aegis and/or cook would not require changes to individual ports like GitHub
> seems to
>
>
>> I skimmed the rest of your message and nothing really stuck out as
>> something worth perusing.  I guess I have to say is that I hope you enjoy
>> Agis so much that you and the 10 other people using it are able to
>> proselytize it to the success that git and github have had.  You certainly
>> seem passionate about it!
>>
>
>  It would be nice if you could refrain from commenting on stuff you can't
> be bothered to "peruse."
>
>
> Likewise!
>

I at least took the time to check what GitHub could do and what it and what
it couldn't... this is just common sense when criticizing something



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


More information about the freebsd-ports mailing list