FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-24-2012, 09:00 PM
"Aaron W. Swenson"
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2012 03:57 PM, Dan Douglas wrote:
> Git is about decentralized version control. When you clone a repo,
> you have your own "fork". When everyone has their own branch,
> everyone is effectively equal. So yes you can expect much much
> more forking. In Git land, forks are good. There's no way to
> enforce that people only pull from some "official" source.
>
> It works out in practice so that 99% of the time people only care
> about a couple branches of one repository. Counterintuitively, this
> comes as a side- effect of git actually doing distribution properly
> and making it easier for everybody's workflow. The overlay model by
> contrast is quite broken on its own and virtually forces creation
> of new overlays in order to make changes without the benifits of
> version control (with regards to the rsync tree at least).
>
> What Github does is facilitate making it easy to fork/branch and
> provide a central way to push changes back into a remote through
> pull requests. Pull requests and other web services around git
> hosting are pretty much the thing that makes github worth using.
> From the standpoint of accepting patches, the differenc e to you is
> rather than (or in addition to) accepting patches through bugzilla,
> you can choose to accept a push directly from someone else's copy
> of the repo. It isn't like a wiki - everybody commits to their own
> repositories and pushing to a remote is on a whitelist basis just
> like in centralized version control.

This gets us into another topic altogether.

I do believe git pull-requests should go through Bugzilla. A
pull-request is the equivalent to bump requests, patch fixes, and all
sorts of stuff that we already handle through Bugzilla. Bugzilla also
contains our history.

If they happen to be needing to be pulled from github, that's fine.
Definitely convenient for the contributor.

We'll also need to clearly document how the pull-request is to be
generated. (I vote for requiring signed pull-requests. [1])

github should not be our central point of contact. We have b.g.o for
that. github should be on the fringes as a tool that we can use if we
want to.

[1]
http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
=MVyV
-----END PGP SIGNATURE-----
 
Old 05-24-2012, 09:14 PM
Alexey Shvetsov
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

In gentoo git tree all git commits will be signed by commiter gpg keys
(and this will be requerd!)


Aaron W. Swenson писал 2012-05-25 00:00:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2012 03:57 PM, Dan Douglas wrote:

Git is about decentralized version control. When you clone a repo,
you have your own "fork". When everyone has their own branch,
everyone is effectively equal. So yes you can expect much much
more forking. In Git land, forks are good. There's no way to
enforce that people only pull from some "official" source.

It works out in practice so that 99% of the time people only care
about a couple branches of one repository. Counterintuitively, this
comes as a side- effect of git actually doing distribution properly
and making it easier for everybody's workflow. The overlay model by
contrast is quite broken on its own and virtually forces creation
of new overlays in order to make changes without the benifits of
version control (with regards to the rsync tree at least).

What Github does is facilitate making it easy to fork/branch and
provide a central way to push changes back into a remote through
pull requests. Pull requests and other web services around git
hosting are pretty much the thing that makes github worth using.
From the standpoint of accepting patches, the differenc e to you is
rather than (or in addition to) accepting patches through bugzilla,
you can choose to accept a push directly from someone else's copy
of the repo. It isn't like a wiki - everybody commits to their own
repositories and pushing to a remote is on a whitelist basis just
like in centralized version control.


This gets us into another topic altogether.

I do believe git pull-requests should go through Bugzilla. A
pull-request is the equivalent to bump requests, patch fixes, and all
sorts of stuff that we already handle through Bugzilla. Bugzilla also
contains our history.

If they happen to be needing to be pulled from github, that's fine.
Definitely convenient for the contributor.

We'll also need to clearly document how the pull-request is to be
generated. (I vote for requiring signed pull-requests. [1])

github should not be our central point of contact. We have b.g.o for
that. github should be on the fringes as a tool that we can use if we
want to.

[1]

http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
=MVyV
-----END PGP SIGNATURE-----


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru
 
Old 05-24-2012, 09:16 PM
Kent Fredric
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

On 25 May 2012 09:00, Aaron W. Swenson <titanofold@gentoo.org> wrote:

> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.

+1

>
> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
>
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
>
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.
>

+/-1 : Not sure, for new people, it should definitely be the go-to way
to do things.

But people who are regular contributors ( which we want to encourage )
will feel slowed down if they have to open a bug report for every
change.

And I can see github facilitating "proxy maintainers" much better.

If a proxy maintainer has another gentoo person who all their changes
get proxied through, the proxy maintainer and the gentoo dev could
both have forks on github, and the proxy maintainer could send their
pull requests to their proxy to vet and merge, somewhat like Linus'es
Generals model.

> [1]
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html
>
> - - Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
> IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
> =MVyV
> -----END PGP SIGNATURE-----
>



--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 
Old 05-24-2012, 09:20 PM
Kent Fredric
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

On 25 May 2012 09:14, Alexey Shvetsov <alexxy@gentoo.org> wrote:
> In gentoo git tree all git commits will be signed by commiter gpg keys (and
> this will be requerd!)
>
> Aaron W. Swenson писал 2012-05-25 00:00:

Something that still confuses me about commit signing that I haven't
seen answered: How does a signed commit work with rebasing? I don't
see any flag to allow rebase to sign commits rebased, and rebasing
*does* change the commit fundementally in ways I'd expect to void any
signature.

Sure, you may not want rebasing in the master, but I sure as hell want
to use it in a branch. People who maintain a long-parallel-merge
history instead of rebasing their branches are on my personal shitlist
=p.

--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 
Old 05-24-2012, 09:27 PM
Alexey Shvetsov
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Kent Fredric писал 2012-05-25 01:20:

On 25 May 2012 09:14, Alexey Shvetsov <alexxy@gentoo.org> wrote:
In gentoo git tree all git commits will be signed by commiter gpg
keys (and

this will be requerd!)

Aaron W. Swenson писал 2012-05-25 00:00:


Something that still confuses me about commit signing that I haven't
seen answered: How does a signed commit work with rebasing? I don't
see any flag to allow rebase to sign commits rebased, and rebasing
*does* change the commit fundementally in ways I'd expect to void any
signature.

Sure, you may not want rebasing in the master, but I sure as hell
want

to use it in a branch. People who maintain a long-parallel-merge
history instead of rebasing their branches are on my personal
shitlist

=p.


You can rebase signed commit untill you dont push it to master
But yes i'm not sure how it works with signed commits
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru
 
Old 05-24-2012, 10:01 PM
Dan Douglas
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

On Thursday, May 24, 2012 05:00:49 PM Aaron W. Swenson wrote:
> This gets us into another topic altogether.
>
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.

This discussion was sort of in the context of proxy-maintainers. A pull
request isn't equivalent to a bump request or entirely overlapping with most
bugs that go through bugzilla. A pull request is just "here take my code", or
is useful for code revewing just because it integrates with the git workflow. I
suppose you would have to define the sorts of things that should go through
Bugzilla. I can't imagine it being reasonable to use github for most types of
bump requests.

> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
>
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
>
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.

This reminds me of Linus' old Google talk on Git in which He said something
along the lines of: "Many companies using Git internally don't know they're
using git - they're using it whether they like it or not". There are ALREADY
Gentoo projects using github and even pull requests. It doesn't really matter
because everything more or less comes back to one point in the end. It's the
repo that's the history of the project, not bugzilla. I've "filed" more bugs
over IRC and had them fixed in the tree within 60 seconds than I have gone
through bugzilla formalisms. FWIW, I think having the entire tree in one big
repo is a bad idea to begin with.

But ok it's a good point. Github isn't a good central point of contact. People
have to use their discression. It's just uncommon these days for a project as
big as Gentoo to have ultra-centralized corporate-style procedures where
everything happens exclusively though official channels. And anyway you couldn't
"enforce" that sort of thing if you tried.

> [1]
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.h
> tml

--
Dan Douglas
 
Old 05-25-2012, 12:58 AM
Rich Freeman
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

On Thu, May 24, 2012 at 6:01 PM, Dan Douglas <ormaaj@gmail.com> wrote:
> But ok it's a good point. Github isn't a good central point of contact. People
> have to use their discression. It's just uncommon these days for a project as
> big as Gentoo to have ultra-centralized corporate-style procedures where
> everything happens exclusively though official channels. And anyway you couldn't
> "enforce" that sort of thing if you tried.
>

++

There is no policy that every commit in cvs needs to be referenced to
a bug, and I doubt we're going to change that. So, if I call up
another dev on the phone and tell them they have a typo in an ebuild,
and they fix it and commit it, nothing has gone wrong. That isn't the
most efficient way to work usually, but there is no policy against it.
In general users should file bugs and not contact devs directly, but
if somebody has a private arrangement otherwise, no harm no foul.

Github is just another overlay. If in the course of working on the
next kde release the kde team makes 385 changes to their overlay, we
don't make them log and close 385 bugs on b.g.o before they merge in
the files from the overlay.

So, if a team wants to use non-official tools, by all means go ahead.
The QA standards apply to anything hitting the main tree, and must be
followed at that point in time. We should keep our tools working
well, but if in some case there is a better way of working, or a small
team has some other preference, well, have at it!

Rich
 
Old 05-25-2012, 01:40 AM
Maxim Kammerer
 
Default Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

On Fri, May 25, 2012 at 1:01 AM, Dan Douglas <ormaaj@gmail.com> wrote:
> This reminds me of Linus' old Google talk on Git in which He said something

I have to ask: was the pronoun capitalization intentional?

> along the lines of: "Many companies using Git internally don't know they're
> using git - they're using it whether they like it or not".

IIRC, it was about git-svn specifically, although I think you are
right: developers will use git and GitHub because they fulfill a need,
regardless of policies.

--
Maxim Kammerer
Libert Linux: http://dee.su/liberte
 

Thread Tools




All times are GMT. The time now is 02:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org