Git Repo

[Stythys]

Just separating this from the previous thread.

Anyways, I know what 'pull' requests are, but never heard of a 'push'
request. How exactly do those work?

[Tom Wambold]

On Sun, Apr 19, 2009 at 3:47 PM, Stythys <twilig...@gmail.com> wrote:
> Anyways, I know what 'pull' requests are, but never heard of a 'push'
> request. How exactly do those work?

If I said push request, I actually meant pull request. Silly me. =)

Yeah, so each developer could fork the main repo, make some changes,
then send me a pull request. I'll then pull their changes, examine
them, and merge them into the main repo. I think this would be a good
way for managing stuff, especially if we get more contributions later
down the road.

-Tom

[Stythys]

ahh, I see. It still seems a bit over-the-top to me, having everyone
have their own separate repo, since it keeps track to the changes
people make anyways, and unless you want to restrict ssh access to
just yourself, and have every package be your responsibility, everyone
will have the ability to build and upload their packages regardless

On Apr 19, 12:58 pm, Tom Wambold <tom5...@gmail.com> wrote:

> On Sun, Apr 19, 2009 at 3:47 PM, Stythys <twilight.l...@gmail.com> wrote:
> > Anyways, I know what 'pull' requests are, but never heard of a 'push'
> > request. How exactly do those work?
>
> If I said push request, I actually meant pull request.  Silly me. =)
>
> Yeah, so each developer could fork the main repo, make some changes,
> then send me a pull request.  I'll then pull their changes, examine
> them, and merge them into the main repo.  I think this would be a good
> way for managing stuff, especially if we get more contributions later
> down the road.
>
> -Tom
>

[Stythys]

doesn't matter a whole lot to me though. Just lemme know what you
decide, and something seems to be wrong with your github page for the
main repo. Did it 'depend' on mine or something, since I deleted it?

[Tom Wambold]

On Sun, Apr 19, 2009 at 4:05 PM, Stythys <twilig...@gmail.com> wrote:
> ahh, I see. It still seems a bit over-the-top to me, having everyone
> have their own separate repo,

One quick thing, you do realize that cloning a git repo creates an
entirely new git repo? Each clone is completely stand alone. Simply
by cloning a repo, you have just created another separate repo.

Forking on Github just allows a nice interface for keeping track of
who has forked (cloned) someone's repo. Just check out how many
people "forked" ruby on rails [1]. This does not mean that they
started separate projects, its just how git works.

This distributed nature completely eliminates the need to grant
permissions to a centralized public repo. This will allow users who
just want to contribute one fix to a package, to clone the package
maintainer's repo, make the change, and submit the pull request to the
package maintainer, who then can verify the fix works, and then can
contribute it to the master repo.

Again, using a single repo that everyone pushes and pulls from is
using it just like Subversion, and removes many of the benefits of
using git in the first place.

The main thing to realize is that forking repos does not lead to
fragmentation of the project, but better organization in the long run,
as you remove a lot of the administrative issues with maintaining
access to a single shared repository.

-Tom

[1] - http://github.com/rails/rails/network

[Tom Wambold]

On Sun, Apr 19, 2009 at 4:13 PM, Stythys <twilig...@gmail.com> wrote:
> something seems to be wrong with your github page for the
> main repo. Did it 'depend' on mine or something, since I deleted it?

Yes, I noticed that too... hmmm. I'll send a message to their help
system in a minute.

-Tom

[Stythys]

ahhh, I get it now :D. Sorry, guess I haven't done larger projects
with git yet =P. Yeah seems like a good idea. I think that's the
problem with your git page too, since I think it was a fork of mine,
which is now gone. Just recreate it.

I'll go edit the wiki.

On Apr 19, 1:17 pm, Tom Wambold <tom5...@gmail.com> wrote:

> On Sun, Apr 19, 2009 at 4:05 PM, Stythys <twilight.l...@gmail.com> wrote:
> > ahh, I see. It still seems a bit over-the-top to me, having everyone
> > have their own separate repo,
>
> One quick thing, you do realize that cloning a git repo creates an
> entirely new git repo?  Each clone is completely stand alone.  Simply
> by cloning a repo, you have just created another separate repo.
>
> Forking on Github just allows a nice interface for keeping track of
> who has forked (cloned) someone's repo.  Just check out how many
> people "forked" ruby on rails [1].  This does not mean that they
> started separate projects, its just how git works.
>
> This distributed nature completely eliminates the need to grant
> permissions to a centralized public repo.  This will allow users who
> just want to contribute one fix to a package, to clone the package
> maintainer's repo, make the change, and submit the pull request to the
> package maintainer, who then can verify the fix works, and then can
> contribute it to the master repo.
>
> Again, using a single repo that everyone pushes and pulls from is
> using it just like Subversion, and removes many of the benefits of
> using git in the first place.
>
> The main thing to realize is that forking repos does not lead to
> fragmentation of the project, but better organization in the long run,
> as you remove a lot of the administrative issues with maintaining
> access to a single shared repository.
>
> -Tom
>

> [1] -http://github.com/rails/rails/network

[Loic Nageleisen]

On 19 Apr 2009, at 22:27, Stythys wrote:

>
> ahhh, I get it now :D. Sorry, guess I haven't done larger projects
> with git yet =P.

yeah, git really starts to show its collaborative power when one comes
in contributing to large projects.

> Yeah seems like a good idea. I think that's the
> problem with your git page too, since I think it was a fork of mine,
> which is now gone. Just recreate it.
>
> I'll go edit the wiki.

don't take it bad, but would you be kind enough to respect TOFU (text
over, fullquote under) ?

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

;)

--

Loic

[Stythys]

On Apr 19, 1:54 pm, Loic Nageleisen <loic.nagelei...@gmail.com> wrote:


> don't take it bad, but would you be kind enough to respect TOFU (text  
> over, fullquote under) ?

Ah, sorry 'bout that =P

[Kevin Barry]

> and unless you want to restrict ssh access to

> just yourself, and have every package be your responsibility, everyone
> will have the ability to build and upload their packages regardless

I think this is an important point. I like the idea of Tom managing the changes from others, this way we have a human's eye over everything to avoid conflicts. But do we want him to be responsible for building the packages also? In a way it makes sense, if we have a developer we don't know do a pull request to Tom and the PKGBUILD looks fine, we still want to build it ourselves for security. But among the trusted-group? I'd be fine with having Tom build all the packages himself, but I feel like that's a pretty big burden. I suppose we could setup a script to compare Tom's repo to the posted binaries and build the new/updated packages and email all the warnings/errors to Tom and CC the PKGBUILD author. Thoughts?

[Stythys]

I agree with you, and the only two solutions I see at the moment is to
either scrap the forking repo idea, or have a larger group of 'core'
devs that look over the main repo.

[Kevin Barry]

> either scrap the forking repo idea,

I kind of would like to keep the forking repo idea as that is a key component of Git and could be very useful if we end up with a lot of non-core contributers, which I think is possible. Look at AUR for example. However I do imagine that most people will share a single PKGBUILD rather than a big repo change.

> have a larger group of 'core' devs that look over the main repo.

This definitely would work but I'm not sure it's the best solution.

I think the big advantage of having a single person in charge of one repo is that all work gets reviewed so we don't end up with PKGBUILDs that don't work.

I suppose an alternative would be some kind of setup with mandatory peer review prior to getting into the main repo. Perhaps no one is in charge of the main repo, but every core developer has their own repo. When you finish a patch you submit it to the mailing list, someone aside from the original author takes it, tests it, and adds it to their personal repo with a "reviewed" tag, then main automatically pulls that. Now we end up with two binaries, the original author and the tester. We could have both users upload their binaries and have them md5 compared. If this worked it could be pretty neat. I'm sure some files would always fail (including compile time date/times or something) but if that triggered a warning email and another human had to go in and authorize one of the binaries for posting. But if there were major differences we could investigate. This would help point out problems of depends not being set correctly and also potential trojan horses.

Maybe all of that is overkill and too much work.

[Tom Wambold]

> On Apr 19, 2:32 pm, Kevin Barry <bar...@gmail.com> wrote:
> I'd be fine with having
> Tom build all the packages himself, but I feel like that's a pretty big
> burden.

So, I wasn't trying to say that I was going to build every package.
My idea is that, for now, I could collect the "main" set of PKGBUILDs
for every package. Each individual package maintainer would be
ultimately responsible for building/uploading their packages. I was
just thinking that I could, from time to time, build packages after
pull requests, if there is a large change or something else, just as a
second test to verify that it works. I'm not saying I'd do this for
every package, as then I probably would not have time to do much else!
;)

On Sun, Apr 19, 2009 at 5:36 PM, Stythys <twilig...@gmail.com> wrote:

> I agree with you, and the only two solutions I see at the moment is to
> either scrap the forking repo idea, or have a larger group of 'core'
> devs that look over the main repo.

Again, every time you clone a repo, you fork it. Once someone sends a
pull request, and I pull their changes, our repositories will be
exactly the same.

Here is how I see the developer workflow:
1.) Clone my git repo
2.) Add/Edit PKGBUILDs
3.) Commit to their personal repo
4.) Submit a pull request to me -AND-
5.) Build a package, and upload it to a testing repo.
6.) I look over the changes, _POSSIBLY_ build the package myself, or
try the package in testing, then:
7.) I merge the developer's changes, and move the binary to main.

Now, if each of us has our own repo on Github (note, it does not
necessarily need to be on github, it can be on any publicly accessible
area), how can we share our work-in-progress PKGBUILDs? Easy, with
git's remote hosts capability.

For example, say Kevin has a repo at github.com/Kevin/arch-osx, and he
maintains the Vim package. Now Kevin is in the middle of
restructuring the Vim PKGBUILD, and has a package in testing, but its
not ready for the main repo. He creates a branch on his repo called
"vim-testing":

git checkout -b vim-testing
<...Make changes...>

Then, if anyone wants to see Kevins testing stuff, they can clone my
repo, then do:

git remote add kevin github.com/Kevin/arch-osx
git checkout kevin/vim-testing

They will now be on his remote branch, and can see his changes. If
they wanted to share some changes with him:

git checkout -b vim-testing -t kevin/vim-testing
<...Make changes..>

Now, they can submit a pull request to Kevin, who can merge their
changes, and then, once its ready, submit a pull request to me.

I hope this rambling made some sense. I think this sort of workflow
is powerful, and takes advantage of Git's features.

-Tom

On Sun, Apr 19, 2009 at 5:36 PM, Stythys <twilig...@gmail.com> wrote:
>

[Stythys]

On Apr 19, 2:49 pm, Kevin Barry <bar...@gmail.com> wrote:

> I suppose an alternative would be some kind of setup with mandatory peer
> review prior to getting into the main repo. Perhaps no one is in charge of
> the main repo, but every core developer has their own repo. When you finish
> a patch you submit it to the mailing list, someone aside from the original
> author takes it, tests it, and adds it to their personal repo with a
> "reviewed" tag, then main automatically pulls that. Now we end up with two
> binaries, the original author and the tester. We could have both users
> upload their binaries and have them md5 compared. If this worked it could be
> pretty neat. I'm sure some files would always fail (including compile time
> date/times or something) but if that triggered a warning email and another
> human had to go in and authorize one of the binaries for posting. But if
> there were major differences we could investigate. This would help point out
> problems of depends not being set correctly and also potential trojan
> horses.
>
> Maybe all of that is overkill and too much work.
>

Yeah I agree with it's a tad too much. Do you think it's opssible to
just tell the devs who make the patches to hold off on uploading until
the changes are merged?

[Tom Wambold]

On Sun, Apr 19, 2009 at 5:49 PM, Kevin Barry <bar...@gmail.com> wrote:
> I kind of would like to keep the forking repo idea as that is a key
> component of Git and could be very useful if we end up with a lot of
> non-core contributers,

I agree.

> However I do imagine that most people will share a single PKGBUILD rather
> than a big repo change.

I'm not sure what you mean by this.

> I suppose an alternative would be some kind of setup with mandatory peer

> review prior to getting into the main repo. [...]

I do think this is a bit overkill. I think the workflow I wrote just
before this mail is much more manageable, and reduces administrative
headaches, etc.

-Tom

[Stythys]

There we go. Sounds like a plan :D