Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Todd Goodman]

* Michael Orlitzky  [150923 08:31]:
> On 09/23/2015 04:40 AM, Todd Goodman wrote:
> > 
> > We haven't had too many problems with it.  Most of our problems seem to
> > be with people having issues with git itself (it was new to almost
> > everyone on the team) and not embracing a good workflow with it (or
> > trying to only use git via Eclipse.)
> > 
> > We have 80 or so Android repos and a much smaller handful of proprietary
> > repos in use.
> > 
> 
> Sorry to harp on this, but does your single gerrit user have write
> access to all 80 of your repos? Yours is internal so the risk is
> limited, but naturally, if we set one up, it would have to be public.

No, there are Projects (repos) which can have project owners and other
levels of permissions.  There's no need to allow wide open access.

We do have most of our small set of developers able to push reviews for
any of our repos but nothing can be committed without review so people
don't tend to "stupid" things (it's also a company so there's the whole
"do something stupid and you're likely to lose your job.")

Some branches are set up to require "gatekeeper" approval in addition to
reviewer approval.  And as I mentioned it's tied into our bug tracking
system as well so one can't even push a review unless the ticket has had
appropriate fields filled out, etc.

> 
> If there's a bug in the web UI somewhere and someone figures out how to
> make it run code, that would put all of our repos at risk. Even without
> being able to run code, a bug might allow privilege escalation: someone
> outside the e.g. portage project might figure out how to push to that
> repo because all of the logic is in Java and not the filesystem.

Yes, as I said we haven't had any formal security audit conducted.

I'd personally expect exploits against Google's accessible Gerrit
instances, but that's obviously not a formal security audit either.

For security of large chunks of software you either pay someone to
perform a formal security audit of it for you or else you get as many
people as you can that you trust to do so.

To me, it's a similar problem to your web server or database or anything
else running on a machine that's on a network.

> 
> The way we have it now, push access is granted through SSH and is
> therefore tied to your user. Implementing users/groups/permissions in
> code would really be a step backwards; this isn't a theoretical argument.

I'm certainly not arguing for or against Gentoo using Gerrit.  It was
mentioned and I just brought up my experience with it.

Though I don't see it as a step backwards.  A user authenticates in
either case and gets permissions based upon that.

Either you trust the authentication mechinism in each case or you don't.

Yes, I agree more complicated permission systems have the ability to
cause problems if set up improperly.

But with both SSH and Gerrit your authentication and permissions are "in
code."

> 
> These issues can totally be fixed -- I'm not saying they're endemic to
> web-based git hosting. But to move access control down to the filesystem
> deviates from how everyone else does things. So first you need to spend
> time getting familiar with the project, then you have to overhaul the
> way it works, and finally you have to get upstream to acknowledge that
> you aren't crazy and accept your docs/patches. That's a lot more work
> than just setting it up.

I don't understand why you said earlier the access control was in code
and now you're saying it's moved to the filesystem?

Filesystem access control for Gerrit is the most basic form you'd use
for any system.  e.g., database files are accessible to the database
user/group only not to anyone else and then per user/group access is
controlled via the "in code" methods.

Again, I'm not arguing for or against Gerrit, just relating my
experience with it.

Todd

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[wireless]

On 09/24/2015 09:59 AM, Todd Goodman wrote:


Again, I'm not arguing for or against Gerrit, just relating my
experience with it.


Hello Todd,

I'm not a dev, but I have over a dozen ebuilds I have hacked together.
They need work, and there are devs who are helping me. Some of these
ebuilds are becoming quite large, due to the numerous jars or the
extensive configuration of the initial config file setup. I enjoy the
learning and hacking part, but gentoo's tool collection presents itself 
as somewhat disjointed, imho.



If a  collection of overlays could be used to setup a prototype
of Gerrit, then, I'd be willing to participate in fully exploring Gerrit
and its use to 'unify' the  development effort between user hacked 
ebuilds and the portage tree. There is currently no well defined path 
for hackers to become contributors and maybe eventually devs, the flux 
is even more partitioned with github now in the mixxx. If Gerrit could 
unify (like an integrated, experimental restructuring of the devmanual 
into)the workflow tools, I think Gerrit could become a wonderful 
addition to gentoo. Maybe a prototype effort will allow the Gerrit 
community within Gentoo to flush out issues before being formally 
proposed to the larger gentoo dev community?



The devmanual, at least the version used by hackers  and those learning 
'the gentoo way' to create ebuilds, should become more open to 
enhancements, details and examples; and who is more qualified to make 
those mods than folks trying to use the devmanual to get codes stable 
and maybe eventually into the portage tree?  The current devmanual is 
good, if you know what you are doing; a bit weak in the teaching by 
example category, particularly for current and recent issues.



curiously,
James

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Todd Goodman]

* James Le Cuirot  [150924 04:55]:
> On Wed, 23 Sep 2015 21:55:00 -0700
> Daniel Campbell  wrote:
> 
> > I hadn't thought about that angle. If our access backbone is via SSH
> > (and thus the filesystem/machine users) then I'm really not sure how
> > to implement a GitLab or Gerrit instance while hooking into the
> > filesystem. Allowing users to open accounts in order to post bugs, etc
> > just isn't a great idea, imo, and duplicates the effort that already
> > exists in Bugzilla. Maybe it'd be smarter to find a way to `git-am`
> > patches from Bugzilla.
> 
> GitLab can feed off LDAP. Once logged in, the user can add an SSH key
> against the account in much the same way as GitHub. It still uses a
> shared git account for the SSH connection though.
> 
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer

Gerrit can get usernames, etc from LDAP as well.

You can then add SSH keys to use when pushing reviews (or whatever else
has been set up.)

Todd

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[James Le Cuirot]

On Wed, 23 Sep 2015 21:55:00 -0700
Daniel Campbell  wrote:

> I hadn't thought about that angle. If our access backbone is via SSH
> (and thus the filesystem/machine users) then I'm really not sure how
> to implement a GitLab or Gerrit instance while hooking into the
> filesystem. Allowing users to open accounts in order to post bugs, etc
> just isn't a great idea, imo, and duplicates the effort that already
> exists in Bugzilla. Maybe it'd be smarter to find a way to `git-am`
> patches from Bugzilla.

GitLab can feed off LDAP. Once logged in, the user can add an SSH key
against the account in much the same way as GitHub. It still uses a
shared git account for the SSH connection though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Michael Orlitzky]

On 09/23/2015 04:40 AM, Todd Goodman wrote:
> 
> We haven't had too many problems with it.  Most of our problems seem to
> be with people having issues with git itself (it was new to almost
> everyone on the team) and not embracing a good workflow with it (or
> trying to only use git via Eclipse.)
> 
> We have 80 or so Android repos and a much smaller handful of proprietary
> repos in use.
> 

Sorry to harp on this, but does your single gerrit user have write
access to all 80 of your repos? Yours is internal so the risk is
limited, but naturally, if we set one up, it would have to be public.

If there's a bug in the web UI somewhere and someone figures out how to
make it run code, that would put all of our repos at risk. Even without
being able to run code, a bug might allow privilege escalation: someone
outside the e.g. portage project might figure out how to push to that
repo because all of the logic is in Java and not the filesystem.

The way we have it now, push access is granted through SSH and is
therefore tied to your user. Implementing users/groups/permissions in
code would really be a step backwards; this isn't a theoretical argument.

These issues can totally be fixed -- I'm not saying they're endemic to
web-based git hosting. But to move access control down to the filesystem
deviates from how everyone else does things. So first you need to spend
time getting familiar with the project, then you have to overhaul the
way it works, and finally you have to get upstream to acknowledge that
you aren't crazy and accept your docs/patches. That's a lot more work
than just setting it up.

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/23/2015 05:30 AM, Michael Orlitzky wrote:
> On 09/23/2015 04:40 AM, Todd Goodman wrote:
>> 
>> We haven't had too many problems with it.  Most of our problems
>> seem to be with people having issues with git itself (it was new
>> to almost everyone on the team) and not embracing a good workflow
>> with it (or trying to only use git via Eclipse.)
>> 
>> We have 80 or so Android repos and a much smaller handful of
>> proprietary repos in use.
>> 
> 
> Sorry to harp on this, but does your single gerrit user have write 
> access to all 80 of your repos? Yours is internal so the risk is 
> limited, but naturally, if we set one up, it would have to be
> public.
> 
> If there's a bug in the web UI somewhere and someone figures out
> how to make it run code, that would put all of our repos at risk.
> Even without being able to run code, a bug might allow privilege
> escalation: someone outside the e.g. portage project might figure
> out how to push to that repo because all of the logic is in Java
> and not the filesystem.
> 
> The way we have it now, push access is granted through SSH and is 
> therefore tied to your user. Implementing users/groups/permissions
> in code would really be a step backwards; this isn't a theoretical
> argument.
> 
> These issues can totally be fixed -- I'm not saying they're endemic
> to web-based git hosting. But to move access control down to the
> filesystem deviates from how everyone else does things. So first
> you need to spend time getting familiar with the project, then you
> have to overhaul the way it works, and finally you have to get
> upstream to acknowledge that you aren't crazy and accept your
> docs/patches. That's a lot more work than just setting it up.
> 
> 
I hadn't thought about that angle. If our access backbone is via SSH
(and thus the filesystem/machine users) then I'm really not sure how
to implement a GitLab or Gerrit instance while hooking into the
filesystem. Allowing users to open accounts in order to post bugs, etc
just isn't a great idea, imo, and duplicates the effort that already
exists in Bugzilla. Maybe it'd be smarter to find a way to `git-am`
patches from Bugzilla.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWA4IfAAoJEAEkDpRQOeFwyR0P/jc6oLr5CV7J+31B5wPm+W/n
KEDUVb+EMjyfgitAx1rcRxNxrQMlq9ZTGYdNeus8+OOnDg2z7WZuSlOsmIQPamiY
aqHu2LUhsix9xUjGu6nYJHWzvE96ISkbrUtBwVxE/I04Gcdpm4Xwx9VPCpRzrMA8
J8dj/QXu7pKZPEXv98pH0jHWHlDpKzT0jmEbgX/EOOImatJlkLNKuZ88vyalAoAQ
kCfN+8ThbvyhEqknmUA/p/yaGTDGw+f7cjO2utYfDsgo7ug9zD4JraaqoQl0XKSb
sH5aDJyE4Ra43o990Bvxx+pq7nTiFiAXZBLB+CVfMT+Qau8V+uatHFfuRufFftBW
2DOXiApJLODZjGwG/qUKdcXL/y4Y41lQcRlGUrLLUssiwn0WrpDBQVxQugUt5ZGD
GGQsC6fQkYBN7XnLL/jC6jzGTQEgDedba7NfL8EsvQK7eEN2EuGrfkzrc5onz0qr
wruWGhnolWbzkIWtJSY6OHzcv3SUXOlSjLdApXkl57zIAsbAWK1jBXvMyf4XBzss
x17T30gjSW98puWg3Gwd0VPBm43M+Dwc2WEncpDetbqewbs3uCmfdhT4FsX3b0p2
x8jygv7LPRNiXHbmUcEmbiMUXqK5//M052xpld993+onCmHZ+28LwVlXEkoWUS+G
B9EZD2RezYd2u1FeMCm0
=ybn4
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[James Le Cuirot]

On Sat, 19 Sep 2015 20:12:06 -0400
Michael Orlitzky  wrote:

> Has anyone ever set up Gitlab or Gerrit, managed by a package manager,
> in a way that a small bug won't grant anonymous write access to every
> single repository?
> 
> Web projects tend to assume that they're the only application/user on
> the server. And as far as security is concerned, that the server is
> in a locked closet with no internet connection. Most of them crash
> when you try to fix those assumptions.

We use GitLab at work and I do like it but I don't know how it fares
for much larger projects. I know less about Gerrit but it is used by
high profile projects like CyanogenMod. We've also had it recommended
numerous times in #gentoo-java by zxiiro, who works for the Linux
Foundation and used to work for the Eclipse Foundation. I think it's
worth a try but no, I'm not volunteering. ;) Having said that, it is
written in Java and if we insist on installing these things through
Portage (I suppose we should eat our own dog food) then I would be
willing to make a push on getting it into the tree. It might be tricky
though, not least because it uses the Buck build system, which I've
never seen used anywhere else and isn't currently in the tree either.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpajjAZIRett.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Michael Orlitzky]

On 09/19/2015 05:16 PM, Daniel Campbell wrote:
> 
> We'd just need a developer who's experienced in maintaining and
> setting them up.
> 

Has anyone ever set up Gitlab or Gerrit, managed by a package manager,
in a way that a small bug won't grant anonymous write access to every
single repository?

Web projects tend to assume that they're the only application/user on
the server. And as far as security is concerned, that the server is in a
locked closet with no internet connection. Most of them crash when you
try to fix those assumptions.

Github fails the second criterion[1], but it's not pointed directly at
our repositories. A developer still has to review and push each commit,
so the risk is mitigated.

The infra team has high standards when it comes to this stuff, and to
fix it would require more than just a weekend of experimentation.


[1] http://homakov.blogspot.com/2012/03/how-to.html

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/16/2015 03:07 PM, Maciej Mrozowski wrote:
> On Saturday 12 of September 2015 21:12:25 Michał Górny wrote:
> 
> | What are your thoughts? Any other proposals?
> 
> Well, there's always an option to set up infra hosted Gerrit or
> Gitlab and forget about Github workflow altogether...
> 
> regards MM
> 
I'm inclined to agree with this, mostly because GitHub is a private
entity; any changes on their end could upend our development
tea-table, so to speak. But we're also faced with a lack of manpower,
so GitHub as a stop-gap seems okay enough. Perhaps we should mentor a
few interested developers on infra business and see if anyone's
interested in maintaining such an instance. It's my understanding that
infra is rather busy as it is, so adding a few extra hands wouldn't
kill them.

We'd just need a developer who's experienced in maintaining and
setting them up.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV/dC9AAoJEAEkDpRQOeFwTuUP/RioW7IMzeN6XDBMjzElzEEI
ne7jVKaAMCnnQUoBXFqYVKTWKnhNVFGWaiqdQSPruGBZjuuTyYeMyL8iPmURrETP
SLFT0mEPTuthP7g+DvHdKgLQqO3fZzvQMgoAE2n4tLDuwuTYivEWkRekZiJHVBnE
IKUJVeEE6giWkFhz0jE5lG6On/9oR93X9IA99OiBdxYezxgklmpAuZ5LpErTxMuq
6b//up2d4uH+xd/+3f/fdsvLvqSj6d0CKTD+ZQt7R5dNUB2zf35PeaDZG6x7r+zm
dilcXqsRFp46J3Q0rx/d5Y5YpTnrB4aF46bGQpEddDEWLSJL9K/VPTmsEoyJdYtF
nJp8JYHDEPRHzwDG3AZA7ADMP7Xzd8lxJO+JLZTntISFDN4bwZY0M5ZbQX62gl2I
VEdd1OATprmRPC6UE/s8hmqLr54jHm9LqApn3M3ZMXDOgT+ywuBrcxH1fPePsNPB
4Y2D6tI8arKsY3X8lc004xpfp3vvxLWORsbTsHL/wan/BD+BSa9HhqYTYRGhGLDP
guyukJ0njCxaJeQsf6ilD+GiCM+ekPMM2mWmoYVigPlSkR672WsTLomxuyfC1Jus
+igVESvQihljxMlK8yi4MST96WuocBVfAKi6MhNJbAbZUFNxc8KQtebs7odG2pKB
oKnkiWjggGVa9jVojVdh
=aCyP
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/19/2015 05:12 PM, Michael Orlitzky wrote:
> On 09/19/2015 05:16 PM, Daniel Campbell wrote:
>> 
>> We'd just need a developer who's experienced in maintaining and 
>> setting them up.
>> 
> 
> Has anyone ever set up Gitlab or Gerrit, managed by a package
> manager, in a way that a small bug won't grant anonymous write
> access to every single repository?
> 
> Web projects tend to assume that they're the only application/user
> on the server. And as far as security is concerned, that the server
> is in a locked closet with no internet connection. Most of them
> crash when you try to fix those assumptions.
> 
> Github fails the second criterion[1], but it's not pointed directly
> at our repositories. A developer still has to review and push each
> commit, so the risk is mitigated.
> 
> The infra team has high standards when it comes to this stuff, and
> to fix it would require more than just a weekend of
> experimentation.
> 
> 
> [1] http://homakov.blogspot.com/2012/03/how-to.html
> 
That's completely reasonable. I'm not advocating for any specific
solution; infra knows the systems and it'd be up to them to choose a
good solution. This makes me wonder now though, if the reason we
settled on GitHub was because the others weren't good and/or secure
enough. Personally I'm find with e-mails and cgit like we currently
have, but I assume the goal of GitHub was to encourage more community
involvement and make contributing easier. Still, were something to
happen to GitHub we'd lose that ability and go back to standard
overlays, e-mail, etc.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV/g3BAAoJEAEkDpRQOeFwPoIQAI76TxONizirRc6bF58n+kKE
Xxvlh/tl1lhFmJiyGLuy1HILEIbeeWX+8U9PFGWzYkh30Ie+7rc/L7Ya4jx3JrvE
3Iu6nHrRCArPNeTMYiNqiCrGVqhQ8qW/27AaalUNstrBXwK0RGKjB5DBYrNDKGl9
6UD5N3JFXo6xHQULuVRY8IjI+2FOR+d/Yww/L22SFfkdVjxHuXGkwk9QP1ZEYwXZ
eRx7Nb9RcJppcsSRtfeYI8Po4mRUZTRekMk36iOt35PC/eaw6wQePdC3pb0KJKaG
lmSb6XMlvooEsipzTsycA1AwOPgou9Vtsj7G6O5Jxj9n3rCROygIFCSYVujlWXeQ
mcZgZoxQpEo3oNTwKcz7XnY15d8IY/5Zd5rZ5LU6aHfknztJxlHsbDMTubJVM3nB
IFRQ5q8McHfTXHNy6A91FL4eKN1IPLF0naRCN/7ipa94GeTIb2Xe8GyQ9wGG42Oi
NCGSmjnc9GQP2F5X/qgqPLH4+8GPg6PXJNXl1gmkma20NdOS3ivBFX2pD6FFj8A3
Ju4fLKgFE+tD8Wv2+tnbo6oysd3zOODREi1fy/q/Ypik5wIxx1KKdntq1eFgvP6m
VZOi+AOjhygM9TM8PjmBkmQ0HAUn2W3irqWpMUCiupaEwyyyZHA0iKzKHEVOhhut
qHiucPnDyt+53WNkmzMN
=cCuf
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Maciej Mrozowski]

On Saturday 12 of September 2015 21:12:25 Michał Górny wrote:

| What are your thoughts? Any other proposals?

Well, there's always an option to set up infra hosted Gerrit or Gitlab and 
forget about Github workflow altogether...

regards
MM

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Brian Dolbec]

On Sun, 13 Sep 2015 15:37:17 +0200
Michał Górny  wrote:

> Dnia 13 września 2015 11:48:54 CEST, Jason Zaman
>  napisał(a):
> >On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> >> Potential solution: bi-dir github <=> bugzilla integration
> >> ==
> >> 
> >> My current idea would be pretty much that:
> >> 
> >> 1. a new dedicated Gentoo bug would be automatically created for
> >every
> >> pull request on github,
> >
> >Will this be only github PR's? will github issues be mirrored too? or
> >are the issues not supposed to be used on github at all?
> 
> Issues are already disabled and I don't see any point in enabling
> them.
> 

I've been doing github api work in my new job.  Pull-requests ARE
issues, just a special version of an issue is all.  Your suppose to be
able to call up the pull request number using the same number in an
issue call.

Do you mean the issue tracker is disabled?  Then they are only allowing
pull request issues, not general issues.

> >
> >Also, I think the new bugzie version allows multiple aliases on a
> >bug, so can we automomatically assign them github-pr-123 and
> >github-issue-234
> >etc?
> 
> Sounds good.
> 
> >
> >> What are your thoughts? Any other proposals?
> >
> >Overall I like the idea. I think the quoting and other issues can be
> >fixed in an acceptable way.
> >
> >-- Jason
> 
> 



-- 
Brian Dolbec 

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Pacho Ramos]

El lun, 14-09-2015 a las 00:19 +0300, Andrew Savchenko escribió:
[...]
> Yes, but as long as choice of core components and infrastructure is
> free one. Read Gentoo Social Contract:
> 
> https://www.gentoo.org/get-started/philosophy/social-contract.html
> 
> "However, Gentoo will never depend upon a piece of software or
> metadata unless it conforms to the GNU General Public License, the
> GNU Lesser General Public License, the Creative Commons -
> Attribution/Share Alike or some other license approved by the Open
> Source Initiative (OSI)."
> 
> What actually happens now is that several individual are trying to
> undermine this concept and to tie Gentoo to the proprietary
> metadata. And some point this dependence will become irreversible.
> It is a pain for me to see that several developers under disguise of
> "community" and "integration" are trying hard to make that happen,
> step by step.
> 
> Best regards,
> Andrew Savchenko

I completely disagree with you pointing to some concrete people and
accusing them about they trying to break the social contract. I see no
proof at all to support your accusation, and I think you should refrain
from doing that kind of accusations without any base. If you have any
kind of "proof" supporting that accusations, please explain them
briefly, otherwise this looks just like trolling to me :/

The only thing I see here is some people trying to mirror github and
bugzilla, and that will likely help a lot of people (like me) that
don't use github, letting people that need their features to work with
other people that don't need or don't want to use it. What is the
problem then? :| Why people tend to think that others have obscure
intentions or similar? Isn't much easier to think that all people here
are contributing for free for the sake of improving things? Why do we
need to be so rude when discussing things on mailing lists or IRC? I am
sure that if we could meet in the "real life", face to face, we would
see that there are no conspiracies and no obscure intentions and most
of the arguments come from misunderstandings, overreactions and similar
:|

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Jason Zaman]

On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> Potential solution: bi-dir github <=> bugzilla integration
> ==
> 
> My current idea would be pretty much that:
> 
> 1. a new dedicated Gentoo bug would be automatically created for every
> pull request on github,

Will this be only github PR's? will github issues be mirrored too? or
are the issues not supposed to be used on github at all?

Also, I think the new bugzie version allows multiple aliases on a bug,
so can we automomatically assign them github-pr-123 and github-issue-234
etc?

> What are your thoughts? Any other proposals?

Overall I like the idea. I think the quoting and other issues can be
fixed in an acceptable way.

-- Jason

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Jason Zaman]

On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> Potential solution: bi-dir github <=> bugzilla integration
> ==

I just noticed this:

https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1308105
it appears to mirror the xfce bugtracker too.

Comment 31 in the launchpad link is the same as comment 1 in the xfce
bug. Is this kind of mirroring common other places? I have never noticed
it till now but was wondering if there is something pre-existing that we
can use.

-- Jason

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Michał Górny]

Dnia 13 września 2015 11:48:54 CEST, Jason Zaman  
napisał(a):
>On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
>> Potential solution: bi-dir github <=> bugzilla integration
>> ==
>> 
>> My current idea would be pretty much that:
>> 
>> 1. a new dedicated Gentoo bug would be automatically created for
>every
>> pull request on github,
>
>Will this be only github PR's? will github issues be mirrored too? or
>are the issues not supposed to be used on github at all?

Issues are already disabled and I don't see any point in enabling them.

>
>Also, I think the new bugzie version allows multiple aliases on a bug,
>so can we automomatically assign them github-pr-123 and
>github-issue-234
>etc?

Sounds good.

>
>> What are your thoughts? Any other proposals?
>
>Overall I like the idea. I think the quoting and other issues can be
>fixed in an acceptable way.
>
>-- Jason


-- 
Best regards,
Michał Górny

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[hasufell]

On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> 
> Gentoo workflow should not depend on a proprietary tools like
> github issue tracker and github pull requests.
> 

It doesn't. That's what this thread is about, so people who refuse to
collaborate on github PRs can still collaborate on bugzilla.

Also, in case you don't know, the github issue tracker is _deactivated_.

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Michał Górny]

Dnia 2015-09-13, o godz. 20:56:07
Andrew Savchenko  napisał(a):

> On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote:
> > Hello, everyone.
> > 
> > The current workflow for handling github pull requests is at least
> > suboptimal. Handling pull requests takes a fair effort from the few
> > developers contributing there, and the progress is often stalled by
> > package maintainers which are either unresponsive or not registered on
> > github at all. That's why I'd like to get your ideas on how we could
> > improve the workflow.
> > 
> > 
> > 
> > Current workflow
> > 
> > 
> > Let's summarize the current workflow first. Right now, there's a few
> > Gentoo developers who actively monitor pull requests on gentoo/gentoo
> > repository. Those developers review incoming pull requests and help
> > submitters get their contributions in shape. Some of those developers
> > also try to 'CC' (@-mention) package maintainers to get their attention
> > on the pull request.
> > 
> > Sadly, @-mentioning sucks for a few reasons:
> > 
> > 1. Many of the Gentoo developers have different nicknames on GitHub.
> > Some developers don't even set their real names which makes them even
> > harder to find.
> > 
> > 2. Teams can be created only by repository 'owners' (which pretty much
> > is equivalent of Infra). Which practically means I'm the only person
> > migrating teams (projects, herds) to GitHub.
> > 
> > 3. GitHub notifications are not very reliable. Some developers get only
> > some of them via mail, some don't. And some simply don't care.
> > 
> > 4. Some developers openly refuse to work with contributors via GitHub.
> > Proxying them manually is not really productive.
> > 
> > 
> > 
> > Potential solution: bi-dir github <=> bugzilla integration
> > ==
> > 
> > My current idea would be pretty much that:
> > 
> > 1. a new dedicated Gentoo bug would be automatically created for every
> > pull request on github,
> > 
> > 2. all comments from github would be automatically copied to bugzie.
> > All bugzie comments would be automatically copied to github,
> > 
> > 3. resolving the bug would automatically close the relevant pull
> > request.
> > 
> > This way, all pull requests can be assigned to package maintainers in
> > Bugzilla without having to resort to GitHub user or team names. All
> > involved parties would get more reliable Bugzilla notification mails.
> > They could choose to either use the provided URLs to discuss the pull
> > request on GitHub, or discuss it directly on Bugzilla, whichever is
> > more convenient to them.
> > 
> > The additional Bugzilla load should be manageable, though we may want
> > to employ some kind of rate limiting in case someone though it'd funny
> > to spam our bugzilla via spamming github.
> > 
> > Problems:
> > 
> > - handling line comments (probably a Bugzie comment with quoted code
> >   snippet),
> > 
> > - handling comment edits and removals,
> > 
> > - some people will get double mail for each comment,
> > 
> > - extra bugs for existing issues (we shouldn't really try to reuse
> >   existing bugs for this).
> > 
> > 
> > 
> > What are your thoughts? Any other proposals?
> 
> Gentoo workflow should not depend on a proprietary tools like
> github issue tracker and github pull requests.

Thank you for your insightful comment. That's very helpful. Really,
thank you a lot. Gentoo would be much worse without such helpful
comments. Why do we need community at all, when one developer with his
helpful comments can provide all there is ever needed by the distro.

-- 
Best regards,
Michał Górny



pgphsP4yFYOUQ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Andrew Savchenko]

On Sun, 13 Sep 2015 20:27:32 +0200 Michał Górny wrote:
> Dnia 2015-09-13, o godz. 20:56:07
> Andrew Savchenko  napisał(a):
> 
> > On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote:
> > > Hello, everyone.
> > > 
> > > The current workflow for handling github pull requests is at least
> > > suboptimal. Handling pull requests takes a fair effort from the few
> > > developers contributing there, and the progress is often stalled by
> > > package maintainers which are either unresponsive or not registered on
> > > github at all. That's why I'd like to get your ideas on how we could
> > > improve the workflow.
> > > 
> > > 
> > > 
> > > Current workflow
> > > 
> > > 
> > > Let's summarize the current workflow first. Right now, there's a few
> > > Gentoo developers who actively monitor pull requests on gentoo/gentoo
> > > repository. Those developers review incoming pull requests and help
> > > submitters get their contributions in shape. Some of those developers
> > > also try to 'CC' (@-mention) package maintainers to get their attention
> > > on the pull request.
> > > 
> > > Sadly, @-mentioning sucks for a few reasons:
> > > 
> > > 1. Many of the Gentoo developers have different nicknames on GitHub.
> > > Some developers don't even set their real names which makes them even
> > > harder to find.
> > > 
> > > 2. Teams can be created only by repository 'owners' (which pretty much
> > > is equivalent of Infra). Which practically means I'm the only person
> > > migrating teams (projects, herds) to GitHub.
> > > 
> > > 3. GitHub notifications are not very reliable. Some developers get only
> > > some of them via mail, some don't. And some simply don't care.
> > > 
> > > 4. Some developers openly refuse to work with contributors via GitHub.
> > > Proxying them manually is not really productive.
> > > 
> > > 
> > > 
> > > Potential solution: bi-dir github <=> bugzilla integration
> > > ==
> > > 
> > > My current idea would be pretty much that:
> > > 
> > > 1. a new dedicated Gentoo bug would be automatically created for every
> > > pull request on github,
> > > 
> > > 2. all comments from github would be automatically copied to bugzie.
> > > All bugzie comments would be automatically copied to github,
> > > 
> > > 3. resolving the bug would automatically close the relevant pull
> > > request.
> > > 
> > > This way, all pull requests can be assigned to package maintainers in
> > > Bugzilla without having to resort to GitHub user or team names. All
> > > involved parties would get more reliable Bugzilla notification mails.
> > > They could choose to either use the provided URLs to discuss the pull
> > > request on GitHub, or discuss it directly on Bugzilla, whichever is
> > > more convenient to them.
> > > 
> > > The additional Bugzilla load should be manageable, though we may want
> > > to employ some kind of rate limiting in case someone though it'd funny
> > > to spam our bugzilla via spamming github.
> > > 
> > > Problems:
> > > 
> > > - handling line comments (probably a Bugzie comment with quoted code
> > >   snippet),
> > > 
> > > - handling comment edits and removals,
> > > 
> > > - some people will get double mail for each comment,
> > > 
> > > - extra bugs for existing issues (we shouldn't really try to reuse
> > >   existing bugs for this).
> > > 
> > > 
> > > 
> > > What are your thoughts? Any other proposals?
> > 
> > Gentoo workflow should not depend on a proprietary tools like
> > github issue tracker and github pull requests.
> 
> Thank you for your insightful comment. That's very helpful. Really,
> thank you a lot. Gentoo would be much worse without such helpful
> comments. Why do we need community at all, when one developer with his
> helpful comments can provide all there is ever needed by the distro.
 
Please don't mix need in the community with tight integration with
proprietary solutions leading to a hard dependency, loss of freedom
and independence.

Best regards,
Andrew Savchenko


pgpMqjDpIvn1P.pgp
Description: PGP signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Andrew Savchenko]

On Sun, 13 Sep 2015 20:21:02 +0200 hasufell wrote:
> On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> > 
> > Gentoo workflow should not depend on a proprietary tools like
> > github issue tracker and github pull requests.
> > 
> 
> It doesn't. That's what this thread is about, so people who refuse to
> collaborate on github PRs can still collaborate on bugzilla.
> 
> Also, in case you don't know, the github issue tracker is _deactivated_.
 
I'm aware of that, but from this thread I see that some people are
trying to activate it. I hope this will never happen.

Best regards,
Andrew Savchenko


pgp7scHR8LbAx.pgp
Description: PGP signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Ciaran McCreesh]

On Mon, 14 Sep 2015 00:07:26 +0300
Andrew Savchenko  wrote:
> On Sun, 13 Sep 2015 20:21:02 +0200 hasufell wrote:
> > On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> > > Gentoo workflow should not depend on a proprietary tools like
> > > github issue tracker and github pull requests.
> > 
> > It doesn't. That's what this thread is about, so people who refuse
> > to collaborate on github PRs can still collaborate on bugzilla.
> > 
> > Also, in case you don't know, the github issue tracker is
> > _deactivated_.
>  
> I'm aware of that, but from this thread I see that some people are
> trying to activate it. I hope this will never happen.

But Gentoo is about choice!

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Andrew Savchenko]

On Sun, 13 Sep 2015 22:13:30 +0100 Ciaran McCreesh wrote:
> On Mon, 14 Sep 2015 00:07:26 +0300
> Andrew Savchenko  wrote:
> > On Sun, 13 Sep 2015 20:21:02 +0200 hasufell wrote:
> > > On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> > > > Gentoo workflow should not depend on a proprietary tools like
> > > > github issue tracker and github pull requests.
> > > 
> > > It doesn't. That's what this thread is about, so people who refuse
> > > to collaborate on github PRs can still collaborate on bugzilla.
> > > 
> > > Also, in case you don't know, the github issue tracker is
> > > _deactivated_.
> >  
> > I'm aware of that, but from this thread I see that some people are
> > trying to activate it. I hope this will never happen.
> 
> But Gentoo is about choice!
 
Yes, but as long as choice of core components and infrastructure is
free one. Read Gentoo Social Contract:

https://www.gentoo.org/get-started/philosophy/social-contract.html

"However, Gentoo will never depend upon a piece of software or
metadata unless it conforms to the GNU General Public License, the
GNU Lesser General Public License, the Creative Commons -
Attribution/Share Alike or some other license approved by the Open
Source Initiative (OSI)."

What actually happens now is that several individual are trying to
undermine this concept and to tie Gentoo to the proprietary
metadata. And some point this dependence will become irreversible.
It is a pain for me to see that several developers under disguise of
"community" and "integration" are trying hard to make that happen,
step by step.

Best regards,
Andrew Savchenko


pgpYdJu0RsTFM.pgp
Description: PGP signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Andrew Savchenko]

On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote:
> Hello, everyone.
> 
> The current workflow for handling github pull requests is at least
> suboptimal. Handling pull requests takes a fair effort from the few
> developers contributing there, and the progress is often stalled by
> package maintainers which are either unresponsive or not registered on
> github at all. That's why I'd like to get your ideas on how we could
> improve the workflow.
> 
> 
> 
> Current workflow
> 
> 
> Let's summarize the current workflow first. Right now, there's a few
> Gentoo developers who actively monitor pull requests on gentoo/gentoo
> repository. Those developers review incoming pull requests and help
> submitters get their contributions in shape. Some of those developers
> also try to 'CC' (@-mention) package maintainers to get their attention
> on the pull request.
> 
> Sadly, @-mentioning sucks for a few reasons:
> 
> 1. Many of the Gentoo developers have different nicknames on GitHub.
> Some developers don't even set their real names which makes them even
> harder to find.
> 
> 2. Teams can be created only by repository 'owners' (which pretty much
> is equivalent of Infra). Which practically means I'm the only person
> migrating teams (projects, herds) to GitHub.
> 
> 3. GitHub notifications are not very reliable. Some developers get only
> some of them via mail, some don't. And some simply don't care.
> 
> 4. Some developers openly refuse to work with contributors via GitHub.
> Proxying them manually is not really productive.
> 
> 
> 
> Potential solution: bi-dir github <=> bugzilla integration
> ==
> 
> My current idea would be pretty much that:
> 
> 1. a new dedicated Gentoo bug would be automatically created for every
> pull request on github,
> 
> 2. all comments from github would be automatically copied to bugzie.
> All bugzie comments would be automatically copied to github,
> 
> 3. resolving the bug would automatically close the relevant pull
> request.
> 
> This way, all pull requests can be assigned to package maintainers in
> Bugzilla without having to resort to GitHub user or team names. All
> involved parties would get more reliable Bugzilla notification mails.
> They could choose to either use the provided URLs to discuss the pull
> request on GitHub, or discuss it directly on Bugzilla, whichever is
> more convenient to them.
> 
> The additional Bugzilla load should be manageable, though we may want
> to employ some kind of rate limiting in case someone though it'd funny
> to spam our bugzilla via spamming github.
> 
> Problems:
> 
> - handling line comments (probably a Bugzie comment with quoted code
>   snippet),
> 
> - handling comment edits and removals,
> 
> - some people will get double mail for each comment,
> 
> - extra bugs for existing issues (we shouldn't really try to reuse
>   existing bugs for this).
> 
> 
> 
> What are your thoughts? Any other proposals?

Gentoo workflow should not depend on a proprietary tools like
github issue tracker and github pull requests.

Best regards,
Andrew Savchenko


pgpuRGI1XO4is.pgp
Description: PGP signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Michał Górny]

Dnia 2015-09-13, o godz. 19:27:17
Jason Zaman  napisał(a):

> On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> > Potential solution: bi-dir github <=> bugzilla integration
> > ==
> 
> I just noticed this:
> 
> https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1308105
> it appears to mirror the xfce bugtracker too.
> 
> Comment 31 in the launchpad link is the same as comment 1 in the xfce
> bug. Is this kind of mirroring common other places? I have never noticed
> it till now but was wondering if there is something pre-existing that we
> can use.

Launchpad is generally special in many ways, and AFAIK it attempts to
provide good linking between downstreams and upstreams. Sadly, we can't
expect any similar efforts around here since we're stuck with Bugzilla
which is very limited, metadata-wise.

-- 
Best regards,
Michał Górny



pgp9Zlnsu57c0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[hasufell]

On 09/13/2015 11:19 PM, Andrew Savchenko wrote:
>  
> Yes, but as long as choice of core components and infrastructure is
> free one. Read Gentoo Social Contract:
> 
> https://www.gentoo.org/get-started/philosophy/social-contract.html
> 
> "However, Gentoo will never depend upon a piece of software or
> metadata unless it conforms to the GNU General Public License, the
> GNU Lesser General Public License, the Creative Commons -
> Attribution/Share Alike or some other license approved by the Open
> Source Initiative (OSI)."
> 
> What actually happens now is that several individual are trying to
> undermine this concept and to tie Gentoo to the proprietary
> metadata. And some point this dependence will become irreversible.
> It is a pain for me to see that several developers under disguise of
> "community" and "integration" are trying hard to make that happen,
> step by step.
> 

You are demotivating and offending a lot of people who have worked hard
on improving collaboration in gentoo.

Github usage is totally optional. Most of what you say makes really zero
sense. Please stop and try to actually read the thread.

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Chí-Thanh Christopher Nguyễn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michał Górny schrieb:
> I don't know if you didn't read the proposal, or if you are unable to 
> understand it. You are seriously *offending* me and the few other 
> developers who are trying *really hard*.
> 
> So let me make this clear: I am trying to make it possible for the 
> community to contribute in any way it finds *convenient* while not 
> forcing anyone to use any external (proprietary or non-proprietary) 
> platform.

TBH I don't see any reason to be offended here.
What Andrew is pointing out is that this path can be a slippery slope into
dependency on GitHub infrastructure.

>> It is a pain for me to see that several developers under disguise of 
>> "community" and "integration" are trying hard to make that happen, 
>> step by step.
> 
> And it is a pain for us to read such unfounded accusations. This is 
> incorrect, and very offensive. If this is really your belief, please 
> keep it to yourself. By writing this you are only causing unnecessary 
> anger and frustration which are not helping anyone.

That remark may have been unwarranted. FWIW I don't agree with it.
But I don't think it lowers the anger-and-frustration standards of this
discussion following:
"Thank you for your insightful comment. That's very helpful. Really,
thank you a lot. Gentoo would be much worse without such helpful
comments. Why do we need community at all, when one developer with his
helpful comments can provide all there is ever needed by the distro."


Best regards,
Chí-Thanh Christopher Nguyễn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlX2B1MACgkQ+gvH2voEPRBP/QCaA3LtZHHhk7qjeUIXHIRm6eD1
90MAn3mmeFk1RmlqNbuSSflyMvx19c9x
=6kAH
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Raymond Jennings]

I agree.  I think that any "master" version of whatever repo we use should
be hosted on gentoo owned infrastructure.

Github might be allowed to take pull requests but I think it should be a
slave to whatever's hosted on gentoo.

That way if anything gets screwed up on github gentoo could always hit the
big fat reset button on gitub


On Sun, Sep 13, 2015 at 10:56 AM, Andrew Savchenko 
wrote:

> On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote:
> > Hello, everyone.
> >
> > The current workflow for handling github pull requests is at least
> > suboptimal. Handling pull requests takes a fair effort from the few
> > developers contributing there, and the progress is often stalled by
> > package maintainers which are either unresponsive or not registered on
> > github at all. That's why I'd like to get your ideas on how we could
> > improve the workflow.
> >
> >
> >
> > Current workflow
> > 
> >
> > Let's summarize the current workflow first. Right now, there's a few
> > Gentoo developers who actively monitor pull requests on gentoo/gentoo
> > repository. Those developers review incoming pull requests and help
> > submitters get their contributions in shape. Some of those developers
> > also try to 'CC' (@-mention) package maintainers to get their attention
> > on the pull request.
> >
> > Sadly, @-mentioning sucks for a few reasons:
> >
> > 1. Many of the Gentoo developers have different nicknames on GitHub.
> > Some developers don't even set their real names which makes them even
> > harder to find.
> >
> > 2. Teams can be created only by repository 'owners' (which pretty much
> > is equivalent of Infra). Which practically means I'm the only person
> > migrating teams (projects, herds) to GitHub.
> >
> > 3. GitHub notifications are not very reliable. Some developers get only
> > some of them via mail, some don't. And some simply don't care.
> >
> > 4. Some developers openly refuse to work with contributors via GitHub.
> > Proxying them manually is not really productive.
> >
> >
> >
> > Potential solution: bi-dir github <=> bugzilla integration
> > ==
> >
> > My current idea would be pretty much that:
> >
> > 1. a new dedicated Gentoo bug would be automatically created for every
> > pull request on github,
> >
> > 2. all comments from github would be automatically copied to bugzie.
> > All bugzie comments would be automatically copied to github,
> >
> > 3. resolving the bug would automatically close the relevant pull
> > request.
> >
> > This way, all pull requests can be assigned to package maintainers in
> > Bugzilla without having to resort to GitHub user or team names. All
> > involved parties would get more reliable Bugzilla notification mails.
> > They could choose to either use the provided URLs to discuss the pull
> > request on GitHub, or discuss it directly on Bugzilla, whichever is
> > more convenient to them.
> >
> > The additional Bugzilla load should be manageable, though we may want
> > to employ some kind of rate limiting in case someone though it'd funny
> > to spam our bugzilla via spamming github.
> >
> > Problems:
> >
> > - handling line comments (probably a Bugzie comment with quoted code
> >   snippet),
> >
> > - handling comment edits and removals,
> >
> > - some people will get double mail for each comment,
> >
> > - extra bugs for existing issues (we shouldn't really try to reuse
> >   existing bugs for this).
> >
> >
> >
> > What are your thoughts? Any other proposals?
>
> Gentoo workflow should not depend on a proprietary tools like
> github issue tracker and github pull requests.
>
> Best regards,
> Andrew Savchenko
>

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Michał Górny]

Dnia 2015-09-14, o godz. 00:19:38
Andrew Savchenko  napisał(a):

> On Sun, 13 Sep 2015 22:13:30 +0100 Ciaran McCreesh wrote:
> > On Mon, 14 Sep 2015 00:07:26 +0300
> > Andrew Savchenko  wrote:
> > > On Sun, 13 Sep 2015 20:21:02 +0200 hasufell wrote:
> > > > On 09/13/2015 07:56 PM, Andrew Savchenko wrote:
> > > > > Gentoo workflow should not depend on a proprietary tools like
> > > > > github issue tracker and github pull requests.
> > > > 
> > > > It doesn't. That's what this thread is about, so people who refuse
> > > > to collaborate on github PRs can still collaborate on bugzilla.
> > > > 
> > > > Also, in case you don't know, the github issue tracker is
> > > > _deactivated_.
> > >  
> > > I'm aware of that, but from this thread I see that some people are
> > > trying to activate it. I hope this will never happen.
> > 
> > But Gentoo is about choice!
>  
> Yes, but as long as choice of core components and infrastructure is
> free one. Read Gentoo Social Contract:
> 
> https://www.gentoo.org/get-started/philosophy/social-contract.html
> 
> "However, Gentoo will never depend upon a piece of software or
> metadata unless it conforms to the GNU General Public License, the
> GNU Lesser General Public License, the Creative Commons -
> Attribution/Share Alike or some other license approved by the Open
> Source Initiative (OSI)."
> 
> What actually happens now is that several individual are trying to
> undermine this concept and to tie Gentoo to the proprietary
> metadata. And some point this dependence will become irreversible.

I don't know if you didn't read the proposal, or if you are unable to
understand it. You are seriously *offending* me and the few other
developers who are trying *really hard*.

So let me make this clear: I am trying to make it possible for the
community to contribute in any way it finds *convenient* while not
forcing anyone to use any external (proprietary or non-proprietary)
platform.

If you want to know my personal opinion: I hate GitHub. But I don't let
my personal feelings harm the community which is willing to contribute
in this particular way. I believe we should be thankful to people who
would like to help making Gentoo better, not reject their work because
it uses a platform I don't like.

> It is a pain for me to see that several developers under disguise of
> "community" and "integration" are trying hard to make that happen,
> step by step.

And it is a pain for us to read such unfounded accusations. This is
incorrect, and very offensive. If this is really your belief, please
keep it to yourself. By writing this you are only causing unnecessary
anger and frustration which are not helping anyone.

-- 
Best regards,
Michał Górny



pgpyvY81iqGfz.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Rich Freeman]

On Sun, Sep 13, 2015 at 9:02 PM, Raymond Jennings  wrote:
> I agree.  I think that any "master" version of whatever repo we use should
> be hosted on gentoo owned infrastructure.
>
> Github might be allowed to take pull requests but I think it should be a
> slave to whatever's hosted on gentoo.
>
> That way if anything gets screwed up on github gentoo could always hit the
> big fat reset button on gitub

That is essentially all that is being proposed.  The pull request
system already exists on github.  Really all the proposal is about is
better integrating it with bugzilla, which if anything makes the
content more accessible via FOSS tools.

Counter-intuitively, the repo itself is actually the part that
concerns me the least.  With git the local clone you keep on your
desktop is just as suitable as any other copy of the repo should we
ever have to hit the reset button.  The part that isn't distributed is
all the comments, discussion, issues, review, etc which generally goes
into bugzilla.  If that were also a distributed database I'd have few
concerns about where that was hosted, since we're essentially talking
about the hosting only.

-- 
Rich

[gentoo-dev] RFI: A better workflow for github pull requests

[Michał Górny]

Hello, everyone.

The current workflow for handling github pull requests is at least
suboptimal. Handling pull requests takes a fair effort from the few
developers contributing there, and the progress is often stalled by
package maintainers which are either unresponsive or not registered on
github at all. That's why I'd like to get your ideas on how we could
improve the workflow.



Current workflow


Let's summarize the current workflow first. Right now, there's a few
Gentoo developers who actively monitor pull requests on gentoo/gentoo
repository. Those developers review incoming pull requests and help
submitters get their contributions in shape. Some of those developers
also try to 'CC' (@-mention) package maintainers to get their attention
on the pull request.

Sadly, @-mentioning sucks for a few reasons:

1. Many of the Gentoo developers have different nicknames on GitHub.
Some developers don't even set their real names which makes them even
harder to find.

2. Teams can be created only by repository 'owners' (which pretty much
is equivalent of Infra). Which practically means I'm the only person
migrating teams (projects, herds) to GitHub.

3. GitHub notifications are not very reliable. Some developers get only
some of them via mail, some don't. And some simply don't care.

4. Some developers openly refuse to work with contributors via GitHub.
Proxying them manually is not really productive.



Potential solution: bi-dir github <=> bugzilla integration
==

My current idea would be pretty much that:

1. a new dedicated Gentoo bug would be automatically created for every
pull request on github,

2. all comments from github would be automatically copied to bugzie.
All bugzie comments would be automatically copied to github,

3. resolving the bug would automatically close the relevant pull
request.

This way, all pull requests can be assigned to package maintainers in
Bugzilla without having to resort to GitHub user or team names. All
involved parties would get more reliable Bugzilla notification mails.
They could choose to either use the provided URLs to discuss the pull
request on GitHub, or discuss it directly on Bugzilla, whichever is
more convenient to them.

The additional Bugzilla load should be manageable, though we may want
to employ some kind of rate limiting in case someone though it'd funny
to spam our bugzilla via spamming github.

Problems:

- handling line comments (probably a Bugzie comment with quoted code
  snippet),

- handling comment edits and removals,

- some people will get double mail for each comment,

- extra bugs for existing issues (we shouldn't really try to reuse
  existing bugs for this).



What are your thoughts? Any other proposals?


-- 
Best regards,
Michał Górny



pgpQinyBTVInU.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Samstag, 12. September 2015, 21:12:25 schrieb Michał Górny:

> Potential solution: bi-dir github <=> bugzilla integration
> ==

The general idea is nice and neat.

> - handling comment edits and removals,

Just discourage it. Strongly discourage it. We should treat PRs like bugs 
anyway, with a permanent history.

> - extra bugs for existing issues (we shouldn't really try to reuse
>   existing bugs for this).

Why not provide a way to hook a PR into an existing bug? After all this sounds 
like normal procedure (bug exists, fix is prepared, ...)

- - How should assignment / wrangling be handled in case a bug is newly 
generated from Github?

- - Who's going to do the integration work? :P

- - What do our BZ admins say about it?

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV9KF+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5EKgP/0VwMcmIP9usi+T3Q2/790np
zpB9JTCJN3N47+wQPpooK5yAA9eXA2+tzykzv13cAQr216/c2k6cNAqy+I/P2/Ap
QY8xiA0XGSXZmm/zHlYyn9BVzwtbbg9f3dJvWNYbwuZ1YfvqBmjSbu9cP7aU7EnZ
sfkQdxO9cfieU5omnDIstky4TVA8qhys3Z43iTA+qnnR5IWnBgF21uSPjr7CQJUI
KHCfdkR6rSrlZBvjjdW06WnwW6skR6F5iXlEWRHH1uViXVt+Oz8h0rhtk9GJR2k8
ePyQDQWADTON4HBPhRzKuaj7bHBDoVKXqJ/sHPQnIHhz1bxf12RJqzp7HJM20F8I
PPQaYMmgBqE94P2GEY7nXVjV6RdL1NKw2BmR9qqaip6WjpRQITuD7HnQScTjRW9+
yphGxlgD0f7bysAz86NnW9eYpekR0WF3uwamBOTx7jaPH4ZWdJcE/w8qPmfJEXnS
5RDAlWUC4Imwc9LuMcbAtUapg0XZodFtCdDJEyTynsJKNOAoIMGIwbVROzYZJ1o/
0w+S7zAhzFmhHCoX3fLwf24vTWhcOKh432P2r8cd/mDrqdEK9S5T1uJWMRZQ46fY
d6eBzJinMtELokeaHDop4knsaCtJEVvETfshCySlvJjK3lbVJB5KgRaZI/5tS1V/
wWreJGHxZCqoiHLb5Zwi
=RvsI
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Hanno Böck]

On Sat, 12 Sep 2015 21:12:25 +0200
Michał Górny  wrote:

> 1. Many of the Gentoo developers have different nicknames on GitHub.
> Some developers don't even set their real names which makes them even
> harder to find.

This isn't directly related to your proposal, but may I jump in here:
Wouldn't it be in general valuable to track the connection gentoo dev
handle <-> github handle in a machine readable and generic way?

Should / could we add that as an ldap attribute or something?

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpoomRUUh5oh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[W. Trevor King]

On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote:
> We should probably auto-attach the patch from the pull request. This
> can easily be done with link-rewriting, e.g.:
> https://github.com/gentoo/gentoo/pull/83 to
> https://github.com/gentoo/gentoo/pull/83.patch
> yields a nice downloadable patch.

Why not [1]:

  $ GITHUB_REMOTE=origin  # adjust this to match whatever you call GitHub's 
gentoo/gentoo
  $ git config --add remote.$GITHUB_REMOTE.fetch 
+refs/pull/*/head:refs/remotes/$GITHUB_REMOTE/pr/*

That will let you fetch the remote branch (e.g. origin/pr/83 assuming
‘origin’ is your GitHub remote).  That seems easier than copy/pasting
around commits and messing with ‘git am’ and other things that will
change the committer, which will in turn invalidate any commit
signatures (the patch seems to drop those anyway).

Cheers,
Trevor

[1]: https://gist.github.com/piscisaureus/3342247

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[hasufell]

On 09/12/2015 09:12 PM, Michał Górny wrote:
> 
> Potential solution: bi-dir github <=> bugzilla integration
> ==
> 
> My current idea would be pretty much that:
> 
> 1. a new dedicated Gentoo bug would be automatically created for every
> pull request on github,
> 
> 2. all comments from github would be automatically copied to bugzie.
> All bugzie comments would be automatically copied to github,
> 
> 3. resolving the bug would automatically close the relevant pull
> request.
> 
> This way, all pull requests can be assigned to package maintainers in
> Bugzilla without having to resort to GitHub user or team names. All
> involved parties would get more reliable Bugzilla notification mails.
> They could choose to either use the provided URLs to discuss the pull
> request on GitHub, or discuss it directly on Bugzilla, whichever is
> more convenient to them.
> 
> The additional Bugzilla load should be manageable, though we may want
> to employ some kind of rate limiting in case someone though it'd funny
> to spam our bugzilla via spamming github.
> 
> Problems:
> 
> - handling line comments (probably a Bugzie comment with quoted code
>   snippet),
> 
> - handling comment edits and removals,
> 
> - some people will get double mail for each comment,
> 
> - extra bugs for existing issues (we shouldn't really try to reuse
>   existing bugs for this).
> 
> 
> 
> What are your thoughts? Any other proposals?
> 
> 

We should probably auto-attach the patch from the pull request. This can
easily be done with link-rewriting, e.g.:
https://github.com/gentoo/gentoo/pull/83 to
https://github.com/gentoo/gentoo/pull/83.patch
yields a nice downloadable patch.

Or was that already part of your plan?

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Samstag, 12. September 2015, 23:31:11 schrieb W. Trevor King:

> Right, thanks.  In that case, I think you'll need a hook to push a new
> patch whenever the GitHub branch is updated, rebased, etc.  That could
> make for a lot of Bugzilla spam, because folks tend to cycle less
> formally in GitHub branches than they do with list-based (and similar)
> workflows.

Possible, but so far the number of github pull request events hasn't exploded 
yet. (The new Git repo has already 5200 commits, but the pull request counter 
is only at 86 so far.) 

Of the currently open 18 PR's most have 1-2 comments, only two more than 10 
comments.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV9KBkXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5op4P/0aFwahQE//PqWK54JXToLld
ro3k9sW7WJ0WO06S7PGceelIgKCeMwtqn8ajLvRfw8Ahbwqk6b4LSRFr1dtOoKaF
sNsnl4mecdazvQcXA03YHELL2R+Iso8tewWm3JexrhjCZ54mg3vJw+QearU91z3Y
1EfVD/jEBnpnTKropdV2G4c5Z5D9zEzwv/NaAeNF6S3FGXd57xsf4WyX2zRJWYib
a2GHAXsmHSj3W8S1FJ8VvtzpqEIH66XMnKRGc17YbqUxAhVoLc134zPigp6s70pQ
srEO3kvG/LrRTOULzZwZ2cC3Df0g750CFPn+8x05d7ec6qo/XgTtT4u3LiVJYmkl
sRg88J2dENEPxjrx8COfL1CaE3sZI/3KywNhabRMw3G8qQYq8WrA5OIypM/FLS7o
Ie30aUx9FYz8GLR0P+31uFrS1S07kA2LKiL7uCXsdcsVcwFtiO2Q+kEci6Yxq89h
UFo9IPjpemFS2Omd32YAN09eRDwjdWZF0J/S8kUJfNjLeM+pT2myU90jPJ9hRuXD
YRoI3TLF7CIqOnuBZoYrFQUA8trnno36JdSTLzR/7N/ZzEDLuoN/nhR95wVqH4p7
rW8sQT+PgG/aMESfL8ZROpzTj2EGrtzfiNay+HYBv4Lf5dFTwaGg8mXjGgrbzDsX
nOg+rrjo9H2xUG4xp5A1
=JSlT
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[hasufell]

On 09/12/2015 11:07 PM, W. Trevor King wrote:
> On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote:
>> We should probably auto-attach the patch from the pull request. This
>> can easily be done with link-rewriting, e.g.:
>> https://github.com/gentoo/gentoo/pull/83 to
>> https://github.com/gentoo/gentoo/pull/83.patch
>> yields a nice downloadable patch.
> 
> Why not [1]:
> 
>   $ GITHUB_REMOTE=origin  # adjust this to match whatever you call GitHub's 
> gentoo/gentoo
>   $ git config --add remote.$GITHUB_REMOTE.fetch 
> +refs/pull/*/head:refs/remotes/$GITHUB_REMOTE/pr/*
> 
> That will let you fetch the remote branch (e.g. origin/pr/83 assuming
> ‘origin’ is your GitHub remote).  That seems easier than copy/pasting
> around commits and messing with ‘git am’ and other things that will
> change the committer, which will in turn invalidate any commit
> signatures (the patch seems to drop those anyway).
> 

Because that is not a valid bug report. Patches must be attached to
bugzilla.

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[W. Trevor King]

On Sat, Sep 12, 2015 at 11:15:14PM +0200, hasufell wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.

Right, thanks.  In that case, I think you'll need a hook to push a new
patch whenever the GitHub branch is updated, rebased, etc.  That could
make for a lot of Bugzilla spam, because folks tend to cycle less
formally in GitHub branches than they do with list-based (and similar)
workflows.  For example, if I submit a patch series to a mailing list,
I'll wait a week before pushing v2 with a bunch of typo fixes, etc.
But if I submit a patch series via a GitHub PR, I'll push fixes for
those sort of things immediately.  I'm skeptical that you'll be able
to retrain frequent GitHub users to pace their pushes, so hopefully
this has a technical solution.  Maybe iterate over open PRs every week
and push changed patches to Bugzilla?  That avoids too much spam, but
it means that comments via GitHub and Bugzilla may be talking about
different versions of the branch (which seems like it would cause
trouble ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[W. Trevor King]

On Sun, Sep 13, 2015 at 01:30:44PM +1200, Kent Fredric wrote:
> If the patch is automatedly filed against bugzilla, people will
> assume viewing that patch tells them all they need to know.
> 
> But the reality is somebody may rebase/amend/repush to the
> publicised branch location before any developer reviews the patch in
> bugzilla, and so by the time somebody reviews the patch, it is
> already wrong.

This is what I was trying to get at [1].  And I still think some sort
of rate-limited posting of updated patches is the best way to handle
it.  Git remotes are more complete (signatures and committer info) and
as current as you like while you're actively reviewing [2], and I
expect the point of the attached patch is to provide an archival
reference that folks can refer to after GitHub (or whoever's hosting
the remote) closes down.  In that case, having the attached patch
occasionally lag by a week (or whatever) is not going to be a big
deal.

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.linux.gentoo.devel/97329/focus=97333
 Message-ID: <20150912213111.gb14...@odin.tremily.us>
[2]: http://thread.gmane.org/gmane.linux.gentoo.devel/97329/focus=97333
 Message-ID: <20150912210734.ga14...@odin.tremily.us>

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Kent Fredric]

On 13 September 2015 at 09:15, hasufell  wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.


I would recommend against attaching the pull in patch form against
bugzilla. It might lead to unintentionally misleading consequences.

If the patch is automatedly filed against bugzilla, people will assume
viewing that patch tells them all they need to know.

But the reality is somebody may rebase/amend/repush to the publicised
branch location before any developer reviews the patch in bugzilla,
and so by the time somebody reviews the patch, it is already wrong.

And as it is common for there to be a "get feedback, amend the pull,
get feedback, amend the pull" loop in existing real-world git
workflows, it should be assumed that is going to happen frequently.

It would also be better for there to be some way to specify a
repository remote and a ref-spec, not having github-intrinsic
behaviours. ( Because people may have personally hosted git repos they
want feedback on  if they have a github aversion, and we must not
*require* github to interact with the development workflow )

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL