stable vs. unstable ports?

[Darren Weber]

I like the idea of an opt-in Xgrid system, whereby users could opt-in to
install an Xgrid client that provides a macports build system, binary
distributions, and meta-ports monitor.  Of course, some folks might
interpret it as too much big-brother, but really it's just so common now to
have integrated network clusters with two-way traffic.  The opt-in and
security settings on the facility may need integrity checking (code review -
so specific commit rights and few maintainers with security access) and
community monitoring to ensure security.  Just about every major desktop
system around has some kind of automated process monitoring and opt-in bug
reporting (windows, mac OSX, gnome, etc.).  I guess that Xgrid provides a
nice platform for a distributed build system.

I have no idea where to start with macports base.  If I had time to learn
it, I would try.  Even so, I would hate to screw around with it without
knowing what I'm doing.  Is there any documentation on how to get started
with hacking macports base - any kind of sandbox to play around with?

Anyone know how to work with Xgrid?  It's something on my todo list, but
I've not read anything about it yet.

Take care, Darren


On Sun, Mar 22, 2009 at 5:18 PM, Joshua Root <jmr at macports.org> wrote:

> Darren Weber wrote:
> >
> > I've noticed problems during port upgrades.
> >
> > What is the general consensus on having a TAG for each port to indicate
> > it's "success" status within the system?
> >
> > Is it possible to have a meta-port monitor that automatically tracks the
> > status of each package install and reports that status back to a central
> > repository to continuously flag the status of a port install.  A simple
> > dichotomy of stable and unstable might suffice (Debian uses stable,
> > unstable, and testing).  Perhaps the monitoring system could provide the
> > data required to justify these port status levels.
>
> IIRC, last time something like this was proposed, the consensus was that
> "phoning home" is evil and MacPorts shouldn't do it. (The focus then was
> more on collecting stats on how often each port is used.) Personally I
> don't see what the problem is as long as it's opt-in.
>
> Of course, if we had a build farm producing binaries (see discussion
> currently ongoing), this information could also be produced by it
> incidentally to its main function.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090322/9f4ba055/attachment.html>