Thomas Klausner <wiz%NetBSD.org@localhost> writes: > On Thu, Jul 19, 2012 at 09:07:58AM +0100, Jonathan Perkin wrote: >> However, what I wanted to suggest was that we move pkgsrc-wip to >> github. It's possible I've drunk too much kool-aid in the last few >> years, but I think that it would be a very good proof-of-concept, and >> would also hopefully encourage more contributions - I don't know of >> anyone choosing to use Sourceforge these days, everyone I know is on >> github, and pull requests make it easier for them to contribute. In general I have a mild philosophical objection to hosting free software projects using non-free tools and on hosting provided by other than a Free Software nonprofit. sourceforge fails on that count too, but if pkgsrc-wip moves I'd like to avoid recreating the problem. It seems people get a sourceforge account if that's what they need. It seems to me that lots of people contribute to wip, and the current issue is lack of netbsd-developer time to bring tthings from wip to pkgsrc. > Easier than committing to the main repository themselves? The notion of pull request is just syntactic sugar around patches. (That said, it's very useful because it removes lots of human work.) In wip, contributors can just make changes, without approval. I think moving to curated pull requests would be a step backwards. > To make it the same as we have now, we'd have to give everyone direct > github commit access to the new repository. That's a big piece of > work one time. Perhaps, but are you volunteering to review all the pull requests and respond within 24h? Are you proposing to institute quality standards, or just push ok without looking? (I'm not trying to be nasty - I don't understand what your vision is of how things would work.) I don't see how putting users on the acl when they ask is that hard; it's what we've been doing for wip. > What do you suggest as merge method? That's one thing that's not very > clear to me, what a good general procedure would be with many > committers on a big mostly independent tree like pkgsrc(-wip). Best'd > probably be automatic-pull-before-commit-plus-push, to mirror what CVS > does; that'd give the least merges. I'm interested in suggestions for > this point. One of the good/bad things about git is the merge mechanism. The mechanism itself is the best I've seen, but in the hands of people that don't deeply understand it there will be merge commits that should have been rebased out (from private trees) and merges that are ff but which should have been explicit merge commits (merge master to feature branch, test, merge feature branch back to master). In a private tree (with 50-100 live branches at most times), I ask people to both rebase out merges from commits that aren't yet in the official repo and create explicit merge commits for all branch merges. This has significantly helped our ability to look at the repo state and understand it. But it requires a great deal of git-fu. So I wouldn't want to see merge commits all over pkgsrc-wip's history. They generally aren't helpful and are just noise. (If there were a branch to make a structural change, then I would, but that is at most a few branches a year, not every commit.) It could be that NetBSD could host wip, and that would be a good experiment with git. (It seems obvious to me that git is the only reasonable choice these days, but perhaps that's not the common view here.)
Attachment:
pgpuVomtCx6Pk.pgp
Description: PGP signature