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 for example). 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 epsilon). 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. Paul