Split Trunk

Juan Manuel Palacios jmpp at macports.org
Thu Oct 4 23:56:57 PDT 2007


	Top posting to make some general comments.

	If you guys may remember, I suggested a somewhat large rearrangement  
of our svn tree a while ago, but all in all I was met with quite a  
bit of opposition so I simply dropped it (the initiative at the time,  
not the desire to do it ;-). Basically, my thoughts were along the  
line of:

-) forego the svn {trunk,branches,tags} standard top level dirs model  
as I believe it doesn't suit us, the only thing we're ever branching  
and/or tagging is the 'base' component;
-) based on that, rearrange as so (leading / indicate I'm referring  
to top level dirs):
	/base
		trunk/
		branches/
		tags/
	/ports (read explanation below)
		release/
			aqua/
			audio/
			(etc)
		test/
			aqua/
			audio/
			(etc)
		<some other tree and children categories>
	/www
		<files>,
		<dirs>.
	/docs
		<files>,
		<dirs>.


	Most of that layout is self-explanatory, I believe, but my view of  
the "new" ports tree(s) does warrant some explanation. It was my idea  
that in making the ports dir a top level one (and thus decoupling it  
from the erroneously implied "trunk" category), we could leverage the  
opportunity to create different "sets of trees", the "release" one  
being the one we distribute to users by default and where "most"  
things submitted by contributors would go. I don't like the Fink idea  
of a stable (release) Vs. unstable tree, the last one holding the  
equivalent of our *-devel ports, as I believe it has been proven that  
that approach condemns the "stable" tree to an always-out-of-date  
jail and as a result pushes everyone to the "unstable" tree (a lot of  
users come to MacPorts complaining Fink only has outdated packages).  
I did, however, propose a "test" tree of some sort where we would  
instead test MacPorts itself, freely using whatever new features/ 
constructs that may be in our trunk base code but not in a MacPorts  
release at any moment; currently, any new MacPorts feature has to  
wait for a new release before being adopted in Portfiles, which  
hinders our ability to test. "mysql5" and "mysql5-devel" ports would  
both live in the "release" tree if they work with whatever MacPorts  
release is current, but (a copy of) any of those would have to move  
to the "test" tree if the corresponding Portfile starts using syntax/ 
code only available in base's trunk. Users would be free to use the  
"test" tree against base's trunk or the recommended "release" tree  
against the current MacPorts release.

	But that layout is not limited to only those two trees, as any other  
purpose-specific tree could be created to fulfill whatever need we  
may have should they arise. For instance, platform specific trees  
could be created:

	/ports
		tiger/
			aqua/
			audio/
			(etc)
		leopard/
			aqua/
			audio/
			(etc)

	Do we really need this....? Certainly not now... but who knows if we  
ever do...? ;-) In any case, having the room to grow is a big plus, I  
believe, and we don't have it now.

	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? [1] Secondly.... and obviously... logging support!  Can't do  
any sort of automated software building if we don't have any mean to  
catch errors and report them. I've spoken at lengths about this  
already, and since this mail is a tad too long already (were you  
expecting any different form me? ;-), I'll just point you to the  
formal proposal I wrote on it:

http://trac.macports.org/projects/macports/wiki/PortLoggingProposal

	As a treat, while evangelizing that to Chris tonight on IRC, he was  
kind enough to put together a small mock-up of what an xml MacPorts  
log would look like:

http://xml.sfiera.net/macports-log.xml

	Once I'm done with the new website I plan to devote to some serious  
energies to this feature that we're so sorely lacking -- do not feel  
one bit shy to chime in if you feel like helping in any way!

	And all that having been said, I should be in bed ;-) Regards,...


-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




More information about the macports-dev mailing list