2007/10/5, Juan Manuel Palacios <[EMAIL PROTECTED]>: > 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 > > [email protected] > > http://lists.macosforge.org/mailman/listinfo/macports-dev > >
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
