Mailinglist Archive: opensuse-buildservice (250 mails)

< Previous Next >
Re: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory
  • From: Peter Poeml <poeml@xxxxxxx>
  • Date: Wed, 22 Apr 2009 16:35:21 +0200
  • Message-id: <20090422143521.GA16299@xxxxxxx>
Hi Jeff, Greg, Brandon,
hi list,

On Wed, Apr 22, 2009 at 09:49:15AM -0400, Jeff Mahoney wrote:
Greg Freemyer wrote:
On Wed, Apr 22, 2009 at 8:44 AM, Peter Pöml <poeml@xxxxxxx> wrote:
Am 16.04.2009 um 19:48 schrieb Brandon Philips:
<snip>
Since git is distributed I could have made my patch commit to a private
repo and you could have pushed my change into the "mainline" repo
without giving me commit rights to the mainline repo. It would have
saved the longish process of getting me commit rights.
This is the part that I don't understand. How can an arbitrary person (in
this case, that would be you) push a change into the "mainline" repository?
You would need to be authorized to do that, no? I can't imagine that a git
repository would be set up in a way that anonymous users would have write
permissions; it would sound dangerous for practical reasons, but I don't
know much about git.

Peter

Peter,

I think Brandon slightly mis-worded it. Git is a pull based system,
not a push based system.

Hi Greg -

He misworded it here, but Git is both a push and a pull system. We use
the push functionality to manage our kernel repository.

So he could have maintained a local git repository and created his
patch, tested it etc. Then sent you a pull request. You would have
the responsibility of deciding if it was safe to pull or not. That
should take less time than deciding if Brandon should have full commit
rights to the source repository.

It's also a step up in the trust relationships git allows you to foster.
You can accept patches, accept pull requests, and ultimately allow
direct push access if there is an agreed-upon "master" repository.

Yes, that's what I had in mind. Although it's nice to be able to provide
a change (patch) in a convenient way (convenient at least for people who
are trained in git), that ultimately doesn't make a change go into
mainline by itself. There needs to be someone who "takes" it. That's the
same kind of barrier like giving someone commit access. Giving commit
access is a bigger (single) step but it fits our development well. We
don't need several levels of trust (or lots of branches).

The fact that it took long to give Brandon write access ("direct push
access") was not due to the used SCM, and it was not at all hindered by
a complicated decision process in the way. In fact, it was all decided
in a split second, however the act of granting the access was something
that only one person could do (bottleneck) which didn't happen (for
unrelated reasons). Giving direct push access to a git repository will
always also require somebody to do "something", which can constitute
just the same kind of bottleneck.

The fact that git patches can be "pulled" is nice and neat, but we don't
need that, if direct access is to be granted anyway (which is the
development model which we use so far). Somebody else could of course
have applied Bandons patch since long (or would have pulled it when we'd
use git), but the problem was not that we don't have ways to get a
change applied to mainline, the problem was to give direct access.

Hence my initial statement (and I do maintain that viewpoint), that it
doesn't help to switch to another SCM, when it comes to give someone a
way to directly change mainline.

Peter
--
Contact: admin@xxxxxxxxxxxx (a.k.a. ftpadmin@xxxxxxxx)
#opensuse-mirrors on freenode.net
Info: http://en.opensuse.org/Mirror_Infrastructure

SUSE LINUX Products GmbH
Research & Development
< Previous Next >