Re: Moving pkgsrc-wip away from SourceForge

[Benny Siegert <bsiegert%gmail.com@localhost>]

On Mon, Jul 13, 2015 at 3:14 PM, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
> If you read your original mail again, you'll see that it is written in a
> form that suggests that consensus has been reached. It is written in a
> form as to notify others rather than in a form to start a discussion.

Yes, I was in fact reporting the consensus of the people around the table.

> I don't see rationale neither for VCS change nor for hoster change,
> and I'd like to see it.

Hoster:

http://www.sergiolopes.eu/2013/08/moving-away-from-sourceforge-net-and-their-malware-adware-spyware-offers/
(that was in 2013!)
http://www.pcworld.com/article/2938017/why-big-open-source-projects-are-fleeing-sourceforges-free-software-hub.html
etc.

In short: you do not want to be hosted by a malware distributor.

VCS: every discussion on tech-repository, ever. Literally. Plus many
of the private ones that you have access to as a dev. Look, I don't
want to rehash these threads here. What has been said about the netbsd
source repo applies equally to pkgsrc and pkgsrc-wip. I have spent a
quarter working only on the git conversion of pkgsrc (and manually
patching commits into the pkgsrc CVS tree with a very small shell
script), and it was absolutely fine.

> I strongly object to converting to git  for following reasons:
> 1. git doesn't support partial checkouts and other partial operations.

"git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>…

When <paths> or --patch are given, git checkout does not switch
branches. It updates the named paths in the working tree from the
index file or from a named <tree-ish> (most often a commit). "

This is how you move part of the tree to a different commit. This has
worked well for me in the past.

Yes, there are no partial checkouts unless you do some gymnastics. But
there are shallow clones, where you don't get the entire history. The
full pkgsrc tree (not wip) with history is 1.5G, hardly a lot of space
for modern hard drives.

> 2. git doesn't support interoperating with pkgsrc the way CVS does.
> (In particular, "cvs up" updates pkgsrc and wip transparently along the trunk.
> git doesn't do that.)

True.

> 3. Merge abilities of git are total mess. Worse than CVS. (Yes, I've heard
> all those lies many times. I cannot count merging head.1 with pom.6 as
> "better merge support.")

False. Once you learn how to merge, it is much better than what CVS
offers. There was an excellent article recently that made the rounds
(and that, unfortunately, I have not bookmarked) explaining basic git
concepts in terms of what the underlying code actually does. There is
fairly little magic involved.

> 1 and 2 apply to other similar version control systems. Changeset-only VCS
> is very horrible fit for pkgsrc and pkgsrc-wip.

This in itself is open for discussion. I disagree here -- again,
having done actual work with pkgsrc on git.

> I have checked the list archives, and what I see that this is the first time
> or nearly the first time this is discussed. Whatever happened on tech-repository
> (if happened at all) is irrelevant here. We're not talking about NetBSD right now.

Nearly the first time, hahahahaha.

>>> Where and when was it presented in public?
>>
>> At pkgsrccon 2015.
>
> This is not public by any means. There's a number of people actively
> using pkgsrc-wip who have never attended pkgsrcCon. The number of people
> who didn't attend pkgsrcCon 2015 is even larger. Because of this
> discussion happening at pkgsrcCon is essentially the same as behind
> closed doors.

That's why we are having this discussion.

>>> How did you determine that
>>> the number of those contributions is not a noise?
>>
>> I did not, so far, but one look on the page would tell you that they are not.
>
> "One look" doesn't demonstrate anything. You do understand that letting
> opponent to hunt your "evidence" down is at least not ethical, don't you?
> So far your claim is to be considered false until you demonstrate it in
> some sensible way.

Sorry for being so unethical.


> Yes, and I don't see how this prevents Joyent from passing changes to
> pkgsrc-wip right now. Pull requests are not commits, so they have to act
> as a gateway anyway. It is the same as me accepting changes in personal
> mail or pastebin service. Yes, some people do use mail and pastebin service
> to contribute to wip.

Again: How is that a reason for pkgsrc-wip, as a project, not to
accept pull requests?