pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Moving pkgsrc-wip away from SourceForge

Thomas Klausner <> writes:

> I agree that we should move away from sourceforge, and I don't see a
> good reason for staying with CVS either.

Agreed strongly and agreed.

> I would really prefer to self-host the repository though, and a VM for
> that is already available; otherwise we might end up in the same
> position that we have with sourceforge now in a couple of years again.

I believe something similar, which is that Free Software projects should
be hosted by a charitable organization whose charter includes support of
Free Software.  TNF certainly is one such organization, and self-hosting
is an entirely reasonable option.

I don't have any particular reason to suspect github in the future.
But, I will observe that github looks now like sourceforge used to look
- aligned with community, shiny, and popular.  So there's no real basis
to be sure it will be ok either.

There's another issue, which is that I don't think pkgsrc (or anything
TNF) should encourage/require contributors to enter into agreements with
random companies.

> From the contributor side that'll be less effort than with sourceforge
> now to get push access (just send an ssh public key to me or another
> wip admin).

Sure, that's easy enough.  I don't understand the desire for the "pull
request" model.  Certainly that can make sense when actual push access
is restricted to a limited set.  But with wip, commit (would be push)
access has been handed out just for the asking.  Or rather, even without
asking - I have often written to people who send patches and asked for
their account name to add them to the ACL.  I don't think we've said no
to anyone.

> For me there are two open points.
> * I prefer hg to git, so it's not as clearcut to me as it seems to be
>   for most people in this discussion that we should switch to git.

I think this is coming down to a preference for hg based on cleanliness
of UI for some subset of people, vs a much larger number of people
preferring git.  One of the reasons to prefer git is that many potential
contributors already know it, far more than know hg (real data anyone?).
A VCS is a necessary tool for wip, not a core point of the project, and
we are optimizing a social-human-computer system, which means how many
people choose to participate is an important consideration.

As for CVS, as someone who gets patches from others to integrate, I
really like it that in hg or git one gets an actual commit to review.
All too often with CVS there's a partial patch or a patch without a
commit message.

> * I want a good conversion of the wip repository (see my
>   tech-repository post).

Agreed, and I don't think that's controversial.

The other open issue is assuming we move to a DVCS, what our norms are
relative to having gratuitous merge commits (that could be rebased out).
In a large (not open source, not public) project I ran, I required that
commits to master rebase out the merge commits, and that branches be
rebased before merging (to blend in the fixup commits, and get up to
date for testing prior to merging), and that branch merges have explicit
merge commits.  It's slightly more effort, and requires a bit more
understanding, but the history is far far easier to read.

Attachment: pgp4Y1H7jyZZ7.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index