Thomas Klausner <wiz%netbsd.org@localhost> 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