Proposal for a new repository layout
pguyot at kallisys.net
Wed Apr 25 04:25:29 PDT 2007
On Apr 25, 2007, at 9:02 AM, Ryan Schmidt wrote:
>> I propose we start with those two trees and fill them up as
>> necessary, the first one being the existing trunk/dports which
>> would *have* to stay in sync with base/branches/release_x_y and
>> the second being a testbed for Portfiles that need unreleased
>> features and syntax to function (ports would be added to it as
>> needed, no need to mirror every single category and port in ports/
>> released if the corresponding Portfile doesn't pack anything
>> different). I would like to make clear that our released Vs.
>> testing split would be with respect to our *Portfiles* and not to
>> the projects we port; that is, emacs and emacs-devel would still
>> be in the released tree as long as their Portfiles are in sync
>> with MacPorts released code. This is contrary to the a la Fink
>> "stable" Vs. "unstable" model, which we all know condemns stable
>> to always be incredibly out of date and pushes everyone to use the
>> unstable tree, while alerting users their computers could catch fire.
> Having "released" and "testing" ports trees sound like a good idea.
I disagree. What's the point of putting portfiles in testing?
Who's going to move them to release when they are ready?
How installation will pick them?
Releases are already a big pain, which explains why we have them so
infrequently. Making this more pain will only make things worse.
I think we should postpone the versioning of the Portfile APIs and
condition it to the existence of a remote repository (through mpwa
And until we have continuous integration, I'm in favor of simply
dropping the very idea of releases. The 1.4.x series show that base/
is globally extremely stable, that major failures are introduced by
active developers who are able to fix them very quickly. It also
proved how wrong the release candidate workflow is. Active users who
might test release candidates and trunk/ do not run 10.3 (this means
that testing time is infinite), while we are able to fix bugs in
base/ and ship fixes within 48 hours (this means the update time is
And I definitely do not understand the interest of changing the
repository layout, except for the joy of requiring every developer
who has uncommitted code to move their files and fix their code
manually to adapt to the new layout and names.
Juan, I realize that I'm just proposing to simply cancel most of your
job within the project. And I realize this is partly why you are so
reluctant from dropping releases, you consider your job as the member
of portmgr responsible for releases is to be conservative against us,
the liberal developers. Well, from my liberal developer's point of
view, your contribution to the project is mostly beyond this
perceived job and your GSoC proposal seemed much more useful for the
project than this new repository layout idea. But this is just my
opinion, and I do not mean to dictate anyone's behavior.
More information about the macports-dev