A question about "massive" changes in the repository

[Lawrence Velázquez]

On Aug 24, 2013, at 7:29 AM, Mojca Miklavec <mojca at macports.org> wrote:

> - Should this be addressed in a single commit or should ports be
> changed one-by-one? (If one-by-one, some ports will be non-functional
> for the time of updating.)

It's fine to do a single huge commit if all the changes are to fix exactly the same issue. Don't throw in version updates and maintainer changes.

> - If they go to a single commit, what's the proper way to document
> what has been changed in individual ports? Should I create a long
> ChangeLog documenting changes in each individual port and commit with
>    svn ci -F ?

I wouldn't bother. It would be fine to just say "Fix wxWidgets compatibility" or whatever. If you feel that your changes to a particular port merit some extended explanation, commit it separately.

> - I've done a bunch of commits to individual ports already. Is that
> history worth keeping (by merging changes from my personal branch) or
> is it better to simply copy the final change (a simple copy, not
> included any svn trickery) and document all changes in that commit? I
> assume it should be the latter.

No, please, do the merge. You should still write a summary of your changes in the merge commit, but maintain the connection to your branch history.

> PS: I believe that some ports are so out-of-date (not maintained
> upstream and most probably not used by anyone) that they should be
> deleted. I'll start a new thread about those because that's unrelated
> and needs special attention. My suggestion would be to have a standard
> procedure to nominate a port for deletion, maybe move it to a place
> like trunk/dports/nominatedfordeletion (but not necessarily) and add a
> PortGroup that would print a warning to anyone installing the port,
> asking to leave a note in a ticket if the port is still useful to him
> and working as intended. If nobody would leave a note for more than a
> year, the port could easily be removed. It could also be helpful to
> include a special PortGroup for ports whose builds or functionality
> are broken for a longer period of time. While we have tickets, it
> would be a lot more straightforward to indicate the brokenness also in
> the port which would warn the user about the problem before attempting
> to compile that port for half an hour just to find out that it's not
> usable. This could also help decide whether a port could be nominated
> for deletion. Related to the recent discussion that it's basically
> impossible to find material that has been deleted from the repository
> unless it's documented somewhere, I would suggest to create a branch
> next to trunk, called obsolete/deleted/removed, where removed ports
> could go (instead of deleting them), so that anyone who might get
> interest in those ports later (some have a certain historical value),
> could easily check that folder.


This all sounds like *way* too much bureaucracy and process. I have seen no problem with our current process for deleting ports (that is, using good judgment and maybe asking on a mailing list). And I certainly don't think we should get into the habit of becoming digital packrats. The repository has history for a reason. You can make a wiki page for deleted ports, if you really care.

vq