Split Trunk

[libc]

2007/10/5, Juan Manuel Palacios <jmpp at macports.org>:
>         And about automated testing through automated ports build runs: this
> is one of the primary goals I am aiming for in the mid-term future,
> but there are in my opinion a couple of key components we are still
> missing to be able to do it properly. One of those is full a blown
> trace mode so that we can have all the needed information about
> everything that goes on outside the destroot sandbox; this depends on
> Eugene's GSoC work so I guess this is a great oportunity to ask for a
> status update on that (as I did tonight with Chris on IRC ;-).
> Eugene, could you please bring us up to speed with the state of your
> work?

http://trac.macports.org/projects/macports/wiki/soc2007/epimenov

> -jmpp
>
>
> [1] I asked Chris for a status update on his GSoC work spanning a few
> key points:
>
>   -) original goals;
>   -) if they were modified along the way, how?
>   -) how successfully did you achieve your original and/or modified
> goals?
>   -) future plans for your end result product(s), most certainly
> including how you plan to use it (them) in MacPorts
>
> Eugene and Elias, you think you could please put something like that
> together for us? It would greatly help us plan future MacPorts
> releases. Thank you!
>
>
>
> On Oct 4, 2007, at 2:54 AM, Anders F Björklund wrote:
>
> > Ryan Schmidt wrote:
> >
> >>> I just think it would be a good idea, even if it moved really
> >>> really slow.
> >>>
> >>> One could start out with a copy of the "archive", and then merge
> >>> ports
> >>> one by one from the "trunk" - either manually or maybe just by
> >>> timer...
> >>
> >> I think it's a bad idea, specifically because we're in such a
> >> nonoptimal state already. This topic has been discussed on the
> >> list before. You may want to look that up in the mailing list
> >> archive.
> >
> > Took a quick look, but it was mostly about "are you guys crazy".
> > Will take another look...
> >
> >> Half of our portfiles (2139 of 4300) are currently unmaintained.
> >> Even ports that are maintained are not necessarily working
> >> properly. How could we in good conscience even declare that the
> >> current port collection is "stable"? How would dividing our
> >> efforts between stable and unstable branches help us to improve
> >> our ports collection faster than we do now?
> >
> > Actually I didn't use the terms "stable" and "unstable" (I think
> > those were from Fink), I used the terms "release" (since the term
> > "archive" means that it is frozen) and "development" (or the SVN
> > term of "trunk").
> >
> >> We don't even know which ports currently work and which don't. We
> >> don't have any automated build process that tries to build every
> >> port on every supported OS & architecture. I kinda feel that would
> >> be more useful at this point.
> >
> > It's much easier to do packaging and testing, when the rate of
> > change slows down. The automated build and packaging process is
> > being revised now (using it to build RPMS), and that is very useful
> > to have either way.
> >
> >> We currently get emails or tickets occasionally asking for updates
> >> that have already occurred; the user has just forgotten to sync,
> >> or the update was just committed and the portindex has not yet
> >> been regenerated. If we introduce a quarantine of some sort
> >> whereby updates do not immediately appear to users, the frequency
> >> of these emails and tickets will increase, and we will have to
> >> deal with them, further reducing the amount of time we spend
> >> actually fixing the ports.
> >
> > Impatient or out-of-date users will occur either way, the easiest
> > path to help them is probably have an updated ports list for easy
> > viewing - such as a web page with versions and recent updates.
> >
> >> By what mechanism would you suggest that changes move between
> >> these two hypothetical ports trees?
> >
> > "Release Engineering". Eventually, someone will have to take a look
> > at it. But maybe just not today ?
> >
> > --anders
> >
> > _______________________________________________
> > macports-dev mailing list
> > macports-dev at lists.macosforge.org
> > http://lists.macosforge.org/mailman/listinfo/macports-dev
>
>