tech-repository archive

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

Re: CVS commit: pkgsrc/net/ocamlnet



On Thu, Jul 19, 2012 at 07:50:47AM -0400, Greg Troxel wrote:
> 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.

AFAIK we're currently pretty up-to-date with pkgsrc-wip-review requests.

> > 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.

I agree. I understood Jonathan's proposal that way though.

> > 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.)

No, I don't want to handle pull requests, I want to give everyone
commit access, just like right now. But getting to a similar state as
we have right now for wip (where already very many people have commit
access) will cost time.

> > 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).

My question was more intended in a practical howto for a useful
workflow if we were to convert pkgsrc(-wip) to git.

What would you recommend?
 Thomas


Home | Main Index | Thread Index | Old Index