A question about "massive" changes in the repository

[Mojca Miklavec]

Hi,

I have a tiny question about the intended massive change to wxWidgets.
I was thinking of doing the switch two weeks from now. (I first
thought of starting with wxPython which is already broken, but now
that almost all the ports are ready for a commit, it probably makes
more sense to change all at once.)

Approximately one half of the ports need an upgrade (mostly because
they are either nomaintainer or the maintainer didn't upgrade them
earlier; some ports are de-facto abandoned, but the maintainers
weren't removed yet), some of them need to be fetched from
svn/git/mercurial to allow compatibility with wxWidgets 2.9 (some of
those simply because the upstream stopped uploading tar.gz-s to the
server and only rely on VCS for distribution of their sources), but
all ports need a change to account for a different location of
wxWidgets.

I'm talking about a bit more than 40 ports in total.

My questions:

- 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.)

- 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'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.

Mojca

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.