Proposal for a new repository layout

[Paul Guyot]

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