Re: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory

newer
Re: [opensuse-buildservice]...

older
[opensuse-buildservice] Packages...

Peter Poeml

30 Mar 2009 30 Mar '09

15:47

On Wed, Mar 25, 2009 at 01:38:42PM -0700, Brandon Philips wrote:

...

Any thoughts on why we don't move to git? If a community member wanted to interact it seems like giving them SVN access would be a bottle neck.

Just a thought.

I don't really understand how a switch to git (which would cost us quite some effort I assume) would enable you to get changes into mainline easier. How would that work, or avoid human bottlenecks? Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development

Attachments:

attachment.sig (application/pgp-signature — 197 bytes)

Show replies by date

Brandon Philips

16 Apr 16 Apr

17:48

New subject: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory

Oops, I seemed to have been dropped from CC- thus the long delay in replying. On 17:47 Mon 30 Mar 2009, Peter Poeml wrote:

...

On Wed, Mar 25, 2009 at 01:38:42PM -0700, Brandon Philips wrote:

...
Any thoughts on why we don't move to git? If a community member wanted to interact it seems like giving them SVN access would be a bottle neck.

Just a thought.

How would that work, or avoid human bottlenecks?

The human bottle neck was getting me commit rights- the code was already written. 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.

...

I don't really understand how a switch to git (which would cost us quite some effort I assume) would enable you to get changes into mainline easier.

Looking at it longer term that means you can have community members contributing code to the buildservice without having to copy around patches or hand out commit rights. I can't imagine moving the buildservice from SVN to git would be a lot of effort. I am sure most of the developers are already familiar since a lot of the Ruby on Rails community is uses git. Cheers, Brandon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Peter Pöml

22 Apr 22 Apr

12:44

New subject: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory

Hi Brandon, Am 16.04.2009 um 19:48 schrieb Brandon Philips:

...

On 17:47 Mon 30 Mar 2009, Peter Poeml wrote:

...

...
On Wed, Mar 25, 2009 at 01:38:42PM -0700, Brandon Philips wrote:

...
Any thoughts on why we don't move to git? If a community member wanted to interact it seems like giving them SVN access would be a bottle neck.

Just a thought.

How would that work, or avoid human bottlenecks?

The human bottle neck was getting me commit rights- the code was already written.

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 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Greg Freemyer

13:17

New subject: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory

On Wed, Apr 22, 2009 at 8:44 AM, Peter Pöml 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. 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. FYI: git was designed for by Linus himself for handling the thousands of patches a month that come his way through a hierarchy of maintainers / developers. He needed a highly scalable solution. A pull based system does not at first sound like a highly scalable solution, but it obviously is by the sheer fact that is handles the largest distributed development project around. Linus has a set of maintainers that he trusts. When they send him a pull request, he basically does it automatically with no review on his part. If he gets one from someone outside of that team he has to decide if it should be allowed to come straight to him, or if it should have gone through one of the trusted subsystem maintainers. I assume he rarely, if ever, accepts a pull request that is not from his core set of maintainers. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Jeff Mahoney

13:52

New subject: [opensuse-buildservice] [PATCH] osc: add -c flag to check package out to current diretory

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Freemyer wrote:

...

On Wed, Apr 22, 2009 at 8:44 AM, Peter Pöml wrote:

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

Am 16.04.2009 um 19:48 schrieb Brandon Philips: <snip> 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.

...

FYI: git was designed for by Linus himself for handling the thousands of patches a month that come his way through a hierarchy of maintainers / developers. He needed a highly scalable solution. A pull based system does not at first sound like a highly scalable solution, but it obviously is by the sheer fact that is handles the largest distributed development project around.

Linus has a set of maintainers that he trusts. When they send him a pull request, he basically does it automatically with no review on his part. If he gets one from someone outside of that team he has to decide if it should be allowed to come straight to him, or if it should have gone through one of the trusted subsystem maintainers. I assume he rarely, if ever, accepts a pull request that is not from his core set of maintainers.

It scales because he's made the workflow hierarchical. This is a good example of a project that is highly collaborative, but ultimately has one person in charge. Other collaborative projects are lead by a core team, who each have direct access to the repository. In reality, this is just convention since git doesn't have a built-in concept of a master repo. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknvITsACgkQLPWxlyuTD7J3LgCggp7bH4lOTEAmGNvVK1uKq1Cr RtAAnjAASmRJUcQ8MJi+A2GuVgw5SvEE =yBwu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

5490

Age (days ago)

5513

Last active (days ago)

List overview

Download

4 comments

5 participants

participants (5)

Brandon Philips
Greg Freemyer
Jeff Mahoney
Peter Poeml
Peter Pöml