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