Owner of MacPorts account on GitHub

[Clemens Lang]

Hi,

----- On 13 Nov, 2015, at 08:39, Mojca Miklavec mojca at macports.org wrote:

> I can check the list of names against mine. It's weird that you had to
> manually add some names to it.

I looked at the history and found a couple of commits that were done using
local accounts, done by root, or done by a cvs2svn conversion script.
Those had to be manually added.

Additionally, a number of MacPorts developers had their handle changed,
which isn't reflected on the MacPortsDevelopers page, but reflected in
the version control history.


> According to the definition of a "clean repository", I have some
> troubles understanding all the issues. I would assume that many GSOC
> projects would copy the core, do something in their branch and leave
> it at that. Do we need to manually identify all these cases and create
> a branch of the main tree with those changes?
> 
> How do you treat the cases when developers copy part of the code
> (either ports or core code) to their personal tree and then merge it
> back to the main tree?

That's exactly the issue that needs most attention, IMO.

A lot of GSoC projects copy only the base folder and work on that in
their branch. Some of those copy the base folder into their branch as
a subfolder but do not copy anything else. Others copy only the contents
of base into their branch. Both of those should be mapped to be branches
of the new base repository.

Some of those branches copied the base folder and also added files next
to the base folder (so basically next to the base, doc, doc-new, dports,
and www folders in trunk), but there is no equivalent to this location
after my conversion. For those cases, I've moved those files to
branch-named subfolders in base.

The GSoC projects that worked on Pallet often have branches of
MacPorts.framework and/or Pallet, some in conjunction with branches off
base. For this reason, I have chosen to split Pallet from the contrib
repo, so the branches are more similar to the content of master. In
case of branches off Pallet *and* base, I converted into separate but
equally-named branches in both base and the Pallet repo.

I think most of the conversions make sense, but it would still be nice
to get a review on the conversion rules that do this (currently at [1]).


> How many repositories would you make out of contrib?

I've only split Pallet because it was branched a couple of times. We
could of course split all contents of contrib, too. Opinions welcome.

Same goes for the user repositories -- what would be a good approach
for a conversion of those?

What should we do with the distfiles repository? It's probably the
most useless of them all after a conversion to Git. IMO it should just
go away completely and be replaced with a different mechanism (e.g.
user-wwwdirs on some server).


> (Subversion is simply a slightly different philosophy and I never
> thought about the many problems arising from trying to "switch the
> philosophy" when you end up with a completely different set of
> repositories as in the initial tree.)

What I currently don't like about our git-svn copies of the tree is
that it is clearly visible that they have been converted from SVN.
My goal with this conversion experiment was to provide a setup that
would be familiar to developers used to Git. After all, our repo was
initially converted from CVS, but it doesn't look like a CVS repo
anymore.


[1] https://github.com/neverpanic/macports-svn2git-rules

-- 
Clemens Lang