Re: [kde-community] What is a GitHub pull request exactly?

[Martin Klapetek]

On Wed, Sep 23, 2015 at 10:36 PM, Jonathan Frederickson <
silverskull...@gmail.com> wrote:

>
> Would it be possible to integrate Github pull requests with reviewboard?
> For example, if someone submits a pull request, have a bot automatically
> post it to reviewboard and post a comment on the Github side with the link.
> That way, contributions through Github are accepted (without the initial
> hurdle of signing up for an account), but it guides the contributor to KDE
> infrastructure for discussion and review.
>

Follow the thread at
https://mail.kde.org/pipermail/kde-community/2015q3/001892.html

Cheers
-- 
Martin Klapetek | KDE Developer
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Jonathan Frederickson]

On Wed, Sep 23, 2015 at 2:19 AM, Rajeev Bhatta 
wrote:

> Agree 100%
>
> On Sun, 20 Sep 2015 15:07:29 +0200
> Riccardo Iaconelli  wrote:
>
> > On Sunday, September 20, 2015 03:01:09 PM Luigi Toscano wrote:
> > > Riccardo Iaconelli ha scritto:
> > > > On Sunday, September 20, 2015 12:26:41 PM Sune Vuorela wrote:
> > > >> Free software needs free tools.
> > > >
> > > > I am sorry, but sadly this is not the state of the art. KDE has
> > > > been created  with many non free tools and currently co-exists in
> > > > many non-free environments. We can either decide to live with it
> > > > and improve the situation little by little or put our heads in
> > > > the sand, build walls around us and pretend the rest of the world
> > > > doesn't exist.
> > >
> > > But we replaced them as soon as we could.
> >
> > To follow-up on my other reply (sorry for the double post), this is
> > exactly where the "little by little" part that I was quoting comes
> > into play.
> >
> > KDE should step in a more closed environment, and use its weight to
> > show people there is a better way to develop software. But in order
> > to do that, it must reach out to new channels and new people who are
> > not yet aware.
> >
> > Bye,
> > -Riccardo
> >
> > ___
> > kde-community mailing list
> > kde-community@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-community
>
> --
> Rajeev Bhatta 
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>

Would it be possible to integrate Github pull requests with reviewboard?
For example, if someone submits a pull request, have a bot automatically
post it to reviewboard and post a comment on the Github side with the link.
That way, contributions through Github are accepted (without the initial
hurdle of signing up for an account), but it guides the contributor to KDE
infrastructure for discussion and review.

Jon F.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 23:06:47, Eike Hein wrote:
> On 09/19/2015 10:32 PM, Kevin Krammer wrote:
> > I don't see there this github review is coming from.
> 
> Review is an interactive process where you ask for changes and
> iterate. Once you open the door to doing it on GitHub, you will:
> 
> * Have a hard time making some contributors understand why
>   they should go through the trouble of moving to Phabricator
>   in the midst of the review process, or next time.
> 
> * Have a hard time making some KDE developers understand why
>   they shouldn't just do it on GitHub.

First, I have no idea where this "use github for review" comes from at all.
Who wants to do that in the first place?

> I don't understand why you expect thinks like "if it matters
> people will take it to RB/Phab as second stage" or "after the
> first patch we ask someone to get an account and switch to
> Phab" will happen as a matter of course.

Because that is how it has always worked until now.

I don't believe that people will start ignoring the need for KDE review 
despite a project's policies, or shoulder patch integration work for new 
contributors indefinitely.

Do you find it likely that a KDE developer who asks an email-patch contributor 
to submit further changes via Phab would not ask a github-patch contributor?

Do you find it likely that a KDE developer who follows the projects guidelines 
on putting patches through Phab would suddenly decide to push directly?

KDE developers who have shown for years that their profressionalism and sense 
of community has made it unnecessary to enforce things like review policies by 
technical means. Who have shown that they prefer new contributors to become 
fully integrated team members?

Because I do not.

I find it way more likely that KDE developers who accept patches from new 
contributors will ask these contributors to get their own developer account 
after a while.
I also find it way more likely that they will continue to abide by the rules 
of the projects they are contributing to.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Sune Vuorela]

On 2015-09-20, Jaroslaw Staniek  wrote:
> But effectively it won't be reviews because the KDE reviewers won't use it.
> Or do you think we need some dracon law because our community cannot do
> self-control?

I have just been fooled once regarding github and KDE. That makes me not
currently believe in self-control.

/Sune

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Sune Vuorela]

On 2015-09-20, Kevin Krammer  wrote:
> First, I have no idea where this "use github for review" comes from at =
> all.
> Who wants to do that in the first place?

The github pull requests comes automatically with review abilities, so
once it is there and one already interacts with github, it is the simple
thing to do.

/Sune

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Vishesh Handa]

On Sun, Sep 20, 2015 at 12:35 PM, Sune Vuorela  wrote:
> On 2015-09-20, Jaroslaw Staniek  wrote:
>> But effectively it won't be reviews because the KDE reviewers won't use it.
>> Or do you think we need some dracon law because our community cannot do
>> self-control?
>
> I have just been fooled once regarding github and KDE. That makes me not
> currently believe in self-control.

IMHO these kind of statements are not productive in helping us work
together. People can have different opinions and be part of an
organization. Using word such as "been fooled" seems to indicate some
kind of malice intent. If I didn't think this would help KDE I
certainly would not have sent over 30+ emails over the last 2 days.
How about you assume good intentions until proven otherwise?

--
Vishesh Handa
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Sunday, September 20, 2015 06:39:02 PM Bhushan Shah wrote:
> We don't need to replace Facebook.. tada.
> 
> Facebook is not part of our development nor anything.. So lets not
> compare with facebook.. When we talk about github and do our reviews
> there. It will be recorded there and if github goes down we will loose
> our data. Also in case we need to relicense stuff it would be
> impossible to track down contributor from github.

Facebook *is* part of our development (not code development, promo 
development, but still development it is), and nobody is advocating doing 
reviews on github.

About relicensing, contacting people is really something hard, with or without 
github. With our history of development, we had thousands and thousands of 
contributors of whom we have lost traces, including all the patches via e-mail 
and so on. Our only defense here is having permissive enough licenses (e.g. 
GPLv2+), not counting on our ability to track down developers. Github won't 
make it worse.

Bye,
-Riccardo

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Sune Vuorela]

On 2015-09-20, Riccardo Iaconelli  wrote:
> How exactly have you been fooled?

> Proposal #1 - accepted,

Proposal #1 was a pure mirror. No other services used. Before the
initial mirror was actually completed, the next proposal comes up to
start doing even more github.

> Proposal #2 - up for  discussion.

> "Fooling" would have been Jaroslaw using pull requests (which are 
> open) without asking permission to the whole community first.

Had I imagined that proposal #2 would come immediately, I'd have argued
heavily against proposal #1.

Now I'm heavyl proposing #2, because I expect a proposal #3 to come
after proposal #2 has been accepted but before implemented.


Free software needs free tools.

/Sune

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Sunday, September 20, 2015 12:26:41 PM Sune Vuorela wrote:
> Free software needs free tools.

I am sorry, but sadly this is not the state of the art. KDE has been created 
with many non free tools and currently co-exists in many non-free 
environments. We can either decide to live with it and improve the situation 
little by little or put our heads in the sand, build walls around us and 
pretend the rest of the world doesn't exist.

Bye,
-Riccardo
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Sunday, September 20, 2015 01:51:19 PM Laszlo Papp wrote:
> I just do not happen to see this case strong enough to support,
> personally. We have not even tried to see how the mirror works out,
> and we already think of whether or not it is a big problem not
> allowing pull requests, et al. It is a bit fast pace.

Hi,
thank you for voicing your concerns in such a manner, I do not think it is 
harsh at all. :-)

The reason why I am still answering this thread is simply that I would like to 
address the "But what happens if some people do not like the direction of 
github being more than a mirror?" question.

Everybody here agrees that github is just a mirror, and a promotion channel. 
The other issue is how pull requests (aka patch submissions), which cannot be 
disabled anyways, should be answered. There are people who would automatically 
close them with a big NO, and people like me who think this is a communication 
mistake.
Since github is a promo platform, we should be open to people who reach out to 
us, and say something like "thank you for your patch, I have applied it/I have 
put it to review on phabricator/it was automatically put on review on 
phabricator. For next patches, please consider to submit them directly there 
instead of sending us a pull request".

As a second discussion, there is people who found ways to get additional 
funding through 3rd party tools integrated with github. I think that is also 
reasonable (as we cannot provide any alternative), but it is a different point 
indeed.

Bye,
-Riccardo

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Sunday, September 20, 2015 03:01:09 PM Luigi Toscano wrote:
> Riccardo Iaconelli ha scritto:
> > On Sunday, September 20, 2015 12:26:41 PM Sune Vuorela wrote:
> >> Free software needs free tools.
> >
> > I am sorry, but sadly this is not the state of the art. KDE has been
> > created  with many non free tools and currently co-exists in many
> > non-free environments. We can either decide to live with it and improve
> > the situation little by little or put our heads in the sand, build walls
> > around us and pretend the rest of the world doesn't exist.
> 
> But we replaced them as soon as we could.


exactly, as soon as we could.
But not all tools simply are technical alternatives. Can we replace Facebook? 
Sure, we could join Diaspora. But we would be missing out on the community 
already present on Facebook. Reasons for being on github are not technical, 
they are promotional.

Bye,
-Riccardo

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Sunday, September 20, 2015 03:01:09 PM Luigi Toscano wrote:
> Riccardo Iaconelli ha scritto:
> > On Sunday, September 20, 2015 12:26:41 PM Sune Vuorela wrote:
> >> Free software needs free tools.
> >
> > I am sorry, but sadly this is not the state of the art. KDE has been
> > created  with many non free tools and currently co-exists in many
> > non-free environments. We can either decide to live with it and improve
> > the situation little by little or put our heads in the sand, build walls
> > around us and pretend the rest of the world doesn't exist.
> 
> But we replaced them as soon as we could.

To follow-up on my other reply (sorry for the double post), this is exactly 
where the "little by little" part that I was quoting comes into play.

KDE should step in a more closed environment, and use its weight to show 
people there is a better way to develop software. But in order to do that, it 
must reach out to new channels and new people who are not yet aware.

Bye,
-Riccardo

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Luigi Toscano]

Riccardo Iaconelli ha scritto:
> On Sunday, September 20, 2015 12:26:41 PM Sune Vuorela wrote:
>> Free software needs free tools.
> 
> I am sorry, but sadly this is not the state of the art. KDE has been created 
> with many non free tools and currently co-exists in many non-free 
> environments. We can either decide to live with it and improve the situation 
> little by little or put our heads in the sand, build walls around us and 
> pretend the rest of the world doesn't exist.

But we replaced them as soon as we could.

Ciao
-- 
Luigi
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Bhushan Shah]

On Sun, Sep 20, 2015 at 6:33 PM, Riccardo Iaconelli  wrote:
> exactly, as soon as we could.
> But not all tools simply are technical alternatives. Can we replace Facebook?
> Sure, we could join Diaspora. But we would be missing out on the community
> already present on Facebook. Reasons for being on github are not technical,
> they are promotional.

We don't need to replace Facebook.. tada.

Facebook is not part of our development nor anything.. So lets not
compare with facebook.. When we talk about github and do our reviews
there. It will be recorded there and if github goes down we will loose
our data. Also in case we need to relicense stuff it would be
impossible to track down contributor from github.

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Eike Hein]

On 09/19/2015 08:43 PM, Kevin Krammer wrote:
> Well, the github side review will make the job of the KDE contributor who 
> brings the patch into KDE a lot easier, because when they put the patch up 
> for 
> review as "their" contribution, most of the things that the contributor knew 
> about will already have been fixed.

No, it won't make it easier. It will busy up KDE contributors
with process snags instead of actual work - now they don't
just have to review, they also have to file requests for work
not their own. It makes stepping up to becoming a regular
contributor less desirable, because it means taking on duties
like this.

The purpose of code review tools is to facilitate review by
making the process sufficiently tenable. Chaining two of them
and creating additional work items does not aid in that
purpose.

It'll also create social tensions of various kinds:

* Developers not participating in GitHub review and only
  seeing a patch once it makes it to Phab will feel
  pressured to accept something because part of the
  discussion has already happened elsewhere, vastly in-
  creasing the conviction required to don the cap and
  baton of the Bad Cop at that point.

* Developers will have opinions on whether it's OK for
  other developers to tell requestees to use Phab next
  time. This issue won't die down. (This would go doubly
  so if people keep pretending opt-in is viable; Laszlo
  raised an excellent point by saying he foresees growing
  tired of explaining why he won't opt-in for years to
  come.)

Really, the only way we can enable GitHub for code
review is if we can work up a community consensus
that it will a full alternative to Phan because it's
worth it to us. If we can't achieve that consensus,
we are left with numerous problems both practical and
social that will weigh us down enormously. My own
opinion on this is in fact mostly guided by the per-
ception that this consensus is not achievable; I'm
otherwise even sympathetic to some of the pro-GitHub
thinking.


> Cheers,
> Kevin

Cheers,
Eike
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 20:56:31, Eike Hein wrote:
> On 09/19/2015 08:43 PM, Kevin Krammer wrote:
> > Well, the github side review will make the job of the KDE contributor who
> > brings the patch into KDE a lot easier, because when they put the patch up
> > for review as "their" contribution, most of the things that the
> > contributor knew about will already have been fixed.
> 
> No, it won't make it easier. It will busy up KDE contributors
> with process snags instead of actual work - now they don't
> just have to review, they also have to file requests for work
> not their own. It makes stepping up to becoming a regular
> contributor less desirable, because it means taking on duties
> like this.

I didn't mean easier than when the author of a patch initiated the actual 
review themselves.
Of course doing only the actual review that counts is a lot easier than doing 
a preliminary one and then doing the actual one, but sometimes doing a 
preliminary one is a nice gesture [1].

Since the goal of any established contributor will be to get the new 
contributor to work on their own as soon as possible, they will not likely do 
that proxying for long.

> The purpose of code review tools is to facilitate review by
> making the process sufficiently tenable. Chaining two of them
> and creating additional work items does not aid in that
> purpose.

Exactly.
So why would one continue to do the prelimiary review in addition to the 
required one?
As soon as there is a stream of patches from a new contributor, that 
contributor will be asked to get an account of their own.
Need for preliminary review or patch proxying removed, ideal situation 
established.

> It'll also create social tensions of various kinds:
> 
> * Developers not participating in GitHub review and only
>   seeing a patch once it makes it to Phab will feel
>   pressured to accept something because part of the
>   discussion has already happened elsewhere, vastly in-
>   creasing the conviction required to don the cap and
>   baton of the Bad Cop at that point.

Developers cooperating on a patch or patchset before review submission is 
nothing new.

> * Developers will have opinions on whether it's OK for
>   other developers to tell requestees to use Phab next
>   time.

I am afraid I didn't get that one.

> Really, the only way we can enable GitHub for code
> review is if we can work up a community consensus
> that it will a full alternative to Phan because it's
> worth it to us.

I don't think this would be a good idea.
The only review that counts in the end is the one all KDE developers have 
access to. Which is Phab.

Using any other tool before review submission is a developer's personal 
choice. If it helps them to gather confidence for the review, why not.
See also [1].

Cheers,
Kevin

[1] I've done plenty of these with new contributors, e.g. GSoC students, so 
they can fix "embarrasing" things with only me seeing them and providing an 
already improved version for general review.

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Eike Hein]

On 09/19/2015 09:55 PM, Kevin Krammer wrote:
> Exactly.
> So why would one continue to do the prelimiary review in addition to the 
> required one?
> As soon as there is a stream of patches from a new contributor, that 
> contributor will be asked to get an account of their own.
> Need for preliminary review or patch proxying removed, ideal situation 
> established.

Except the pro-GitHub side specifically argues for
GitHub as increasing the frequency of first patch
submissions, so the total amount of work spent on
dealing with them increases. This is on some level
a "nice problem to have", but creates a pressure to
drop two-stage review and use GitHub as a primary
channel to optimize that channel. I.e. once again
leading me to the conclusion that two-stage review
is simply not viable and runs counter to what the
proposal wants to achieve.


> Developers cooperating on a patch or patchset before review submission is 
> nothing new.

This sort of "we have a precedent for this" argument
comes up a lot, but is often a really poor argument
because it doesn't establish that precedent was
actually a positive experience or a desirable
situation. "We've had this problem before" does not
justify "let's have more of that problem". "We are
already unhappy" doesn't justify "then let's make
decisions that create more unhappyness". It's about
what our decisions shift us toward next; precedents
are mostly about learning from them (e.g. the unhappy-
ness we've seen from having multiple review tools).


> I am afraid I didn't get that one.

There will be strife around both refusing to use GitHub
and wanting to use GitHub exclusively.


> I don't think this would be a good idea.
> The only review that counts in the end is the one all KDE developers have 
> access to. Which is Phab.

I agree that GitHub has an inclusivity problem, and this
subthread has been mostly about why that inclusivity pro-
blem can't really be avoided and the problems that would
arise from having two tools at once without a consensus
addressing inclusivity. For some reason that leads you to
"win-win-win scenario" (unless that was sarcasm ... I
really couldn't tell) and me to "maybe we shouldn't then".

I'm sorry I can't write a more in-depth reply, but I find
several of your thoughts really hard to follow/understand -
we seem to be in very, very different places on how we
perceive the reality of development work or how humans
behave in practice or something. I think we'll have to
leave it at this and perhaps find out how persuasive
either of us appears to the undecided.


Cheers,
Eike
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 22:11:10, Eike Hein wrote:
> On 09/19/2015 09:55 PM, Kevin Krammer wrote:
> > Exactly.
> > So why would one continue to do the prelimiary review in addition to the
> > required one?
> > As soon as there is a stream of patches from a new contributor, that
> > contributor will be asked to get an account of their own.
> > Need for preliminary review or patch proxying removed, ideal situation
> > established.
> 
> Except the pro-GitHub side specifically argues for
> GitHub as increasing the frequency of first patch
> submissions, so the total amount of work spent on
> dealing with them increases.

Yes, but those who argue for that are aware of the extra work that will cost.
Like Jaroslaw explained, he is fully aware of the extra work that this means, 
but he already has this extra work no matter which indirect submission forms 
he supports.

So in his experience it is worth it for him.

> This is on some level
> a "nice problem to have", but creates a pressure to
> drop two-stage review and use GitHub as a primary
> channel to optimize that channel.

I don't see there this github review is coming from.
A preliminary review on github is something the KDE contributor, who will then 
take the patch to KDE review, can do if they think it will make their review 
easier. Or to provide the patch author with confidence to do it themselves 
next time.

I would assume that in most case the patch from the first time contributor is 
just taken to KDE review and the author asked to submit directly next time.

Everything else is not "optimizing the channel", only direct submission to KDE 
review is optimal.

> I.e. once again
> leading me to the conclusion that two-stage review
> is simply not viable and runs counter to what the
> proposal wants to achieve.

Indeed. Somehow people bring up additional github review all the time. I doubt 
anyone would do that in practise.

> > Developers cooperating on a patch or patchset before review submission is
> > nothing new.
> 
> This sort of "we have a precedent for this" argument
> comes up a lot, but is often a really poor argument
> because it doesn't establish that precedent was
> actually a positive experience or a desirable
> situation.

I always found direct collaboration, e.g. at sprints, extremely desirable.
As a GSoC mentor I am also pretty confident that my students found our private 
reviews desirable, based on them asking for them.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Jaroslaw Staniek]

On 19 September 2015 at 23:06, Eike Hein  wrote:
>
>
> On 09/19/2015 10:32 PM, Kevin Krammer wrote:
>> I don't see there this github review is coming from.
>
> Review is an interactive process where you ask for changes and
> iterate. Once you open the door to doing it on GitHub, you will:
>
> * Have a hard time making some contributors understand why
>   they should go through the trouble of moving to Phabricator
>   in the midst of the review process, or next time.
>
> * Have a hard time making some KDE developers understand why
>   they shouldn't just do it on GitHub.
>
> I don't understand why you expect thinks like "if it matters
> people will take it to RB/Phab as second stage" or "after the
> first patch we ask someone to get an account and switch to
> Phab" will happen as a matter of course. It's so much more
> likely that people who are comfortable with GitHub will ask
> those who don't to comply (monitor it for requests, respond
> to requests, participate), or they just won't be able to agree.

There are no such people so far, no people that come and say: change
this and that workflow or I'll destroy your project. I'd say many
projects are rather ignored than attacked even in the very close C++
world and that's the worst thing that can happen IMHO. I wouldn't see
another cases like KHTML->WebKit-type of forks for example.

These two things are different:
- asking people to apply for KDE developer account to just use a git
storage for placing a single initial commits on first contact (the
application shall be rejected anyway since they are not contributors
and have no mentor's recommendation... catch-22)
- asking people that decided to contribute further after first
successes (hey, these KDE folks accepted my fixes, nice, I'll learn
the workflow then, it pays off!)

Cases with SoK and GSoC are different because applicants agree to the
rules the first time they apply, they explicitly join KDE even if for
a few days/weeks. Other 3rd-parties are *not yet* sure it makes sense
for them.

I have enough of these probabilistic analysis of what most likely
happen. Most of us are largely here for fun. I am not a white collar
in this relation to ask people to confront with a wall of text on the
first contact. Your attitude may differ but please give me the freedom
of forming relations in my way.

I am feeling strong enough to trust people and integrate with the
outside world.
With any git storages that count in this world.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 20:20:56, Eike Hein wrote:
> On 09/19/2015 08:13 PM, Kevin Krammer wrote:
> > I am afraid my understanding of the technical background of this is still
> > too hazy.
> > How would review "move" from KDE to github?
> > If review on reviewboard is required (per project's unwritten social
> > contract), it cannot not happen.
> > If it is not required, better have a patch reviewed elsewhere than not at
> > all.
> His argument is that because KDE developer accounts can
> write to repositories directly (which we have discussed
> many times we don't want to change), lazyness will win
> and patches will go into repositories directly after
> GitHub review.

That is a matter of project policy.
It it only uses review as a "can do" thing, then yes, any contributor can push 
any patch at any time. Just like they do today.
If it is "should do", then yes, a contributor could consider pushing directly. 
Just like they do today.
It it is "must do", then no, the maintainer will revert their patch and remind 
them of the policy.

So in the first two cases a patch that would otherwise not have seen any 
review got some review.
In the third case it will get two.

> Personally I agree that is the likely scenario. Two-stage
> review is simply too much work and hassle, and I doubt
> it's desirable to anyone who actually wants to use
> GitHub.

Well, the github side review will make the job of the KDE contributor who 
brings the patch into KDE a lot easier, because when they put the patch up for 
review as "their" contribution, most of the things that the contributor knew 
about will already have been fixed.

If the review and integration work turns out to be too annoying, I would 
expect these KDE developers to ask their source to do it themselves next time 
around.

Having to do the integration work has so far been a great motivator to 
eventually ask a regular new contributor to get an account on their own.

With more and more reviewing becoming "mandatory" I don't see that motivation 
going down. Quite the opposite.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Eike Hein]

On 09/19/2015 08:13 PM, Kevin Krammer wrote:
> I am afraid my understanding of the technical background of this is still too 
> hazy.
> How would review "move" from KDE to github?
> If review on reviewboard is required (per project's unwritten social 
> contract), it cannot not happen.
> If it is not required, better have a patch reviewed elsewhere than not at all.

His argument is that because KDE developer accounts can
write to repositories directly (which we have discussed
many times we don't want to change), lazyness will win
and patches will go into repositories directly after
GitHub review.

Personally I agree that is the likely scenario. Two-stage
review is simply too much work and hassle, and I doubt
it's desirable to anyone who actually wants to use
GitHub.

I think that - just like "let's pretend we can make
GitHub opt-in per-project" - "GitHub would be a step
in the pipeline before Phrabricator" is a discussion
thread that should be abandoned. It's not viable and
not realistic.

It's not about how we can make GitHub a less bitter
pill, it's about whether we want GitHub or not.


Cheers,
Eike
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

I have some difficulty understanding the perceived difference in workflow, so 
I'd like to get some input on where my line of thinking and reality differ :-)

The following example deals with clones of a repository and the revision of 
HEAD in the master branch.

Example: akonadiclient, three developers (Bhaskar, Jonathan, Kevin).

Repo: revision of HEAD@master

1) Initial situation

git.kde.org: acbd

Bhaskar: abcd
Jonathan: abcd
Kevin: abcd

2) Kevin creates a patch

git.kde.org: acbd

Bhaskar: abcd
Jonathan: abcd
Kevin: ghij

3) Patch goes to reviewboard

git.kde.org: acbd

Bhaskar: abcd
Jonathan: abcd
Kevin: ghij

4) Patch is reviewed and gets "Ship it". Kevin pushes to git.kde.org

git.kde.org: ghij

Bhaskar: abcd
Jonathan: abcd
Kevin: ghij

5) The other developers update

git.kde.org: ghij

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij

6) KDE gets a github mirror

git.kde.org: ghij
github: ghij

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij

7) A new developer, Fred, clones on github

git.kde.org: ghij
github: ghij
Fred's clone: ghij

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij

8) Fred creates a patch

git.kde.org: ghij
github: ghij
Fred's clone: ghij

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij
Fred: klmn

9) Fred pushes to his clone

git.kde.org: ghij
github: ghij
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij
Fred: klmn

10) Fred makes a pull request

git.kde.org: ghij
github: ghij
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij
Fred: klmn

Ok, now my understanding is there are two options: (a) someone pulls from 
Fred's clone (b) there is a merge option on GitHub

11a) Kevin pulls from Fred's clone

git.kde.org: ghij
github: ghij
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: klmn
Fred: klmn

12a) Kevin puts Fred's patch up on review, pushes it to git.kde.org once it 
gets "Ship it"
 
git.kde.org: klmn
github: klmn
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: klmn
Fred: klmn

11b) Kevin used the merge option on github

git.kde.org: ghij
github: klmn
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: ghij
Fred: klmn

12b) Kevin pulls from github

git.kde.org: ghij
github: klmn
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: klmn
Fred: klmn

13b) Kevin puts the patch of for review, pushes to git.kde.org when it gets 
"Ship it"

git.kde.org: klmn
github: klmn
Fred's clone: klmn

Bhaskar: ghij
Jonathan: ghij
Kevin: klmn
Fred: klmn

So (a) and (b) workflows differ in that in (a) github mirror and git.kde.org 
have the same state, while in (b) the mirror is for a period of time not 
actually a mirror, but "ahead".

Where "ahead" could also mean wrong if "klmn" needs to be modified or gets 
rejected.

Is (b) the problem people keep discussing about?

Because as far as I can tell it is not really an option given that it can lead 
to an inconsistent state of two clone sources that are considered to be 
mirrored.

If the problem is somewhere in (a), where is it?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 12:06:18, Michael Pyne wrote:
> On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote:
> > So (a) and (b) workflows differ in that in (a) github mirror and
> > git.kde.org have the same state, while in (b) the mirror is for a period
> > of time not actually a mirror, but "ahead".
> > 
> > Where "ahead" could also mean wrong if "klmn" needs to be modified or gets
> > rejected.
> > 
> > Is (b) the problem people keep discussing about?
> 
> Kevin, first off thanks for taking all the time to diagram this in an email!

:-)
Since I haven't had to deal with these pull requests in any form yet, I wasn't 
sure I understood the implications.

Git is already highly distributed, each developer has a full clone of whatever 
repository they work on and already have options of sharing "remotes".

A clone on github is, as far as I understand, just a publically visible 
"remote" of one developer's state of the repository.

And a pull request is just a formal notification that a certain commit, patch 
set or branch could be interesting for upstream.

> I think some of us are seeing this as simply an administrative or technical
> discussion of how we merge changes into git.kde.org in the presence of
> Github. I don't think it's really that at all, but instead a question of
> "where is the development happening" and "how is KDE [the community]
> staying involved/up-to- date with that development"?

Yes, good point. I just wanted to make sure I have the techical aspects sorted 
out correctly before making predictions or assumptions based on 
misunderstanding of how things work.

> So I understand that from the perspective of "I already take patches by
> email, this is just another way of accepting new patches" this whole
> discussion might seem incredibly overdone. But there's another perspective
> of "how do we [KDE] ensure that our community values around common
> development are still maintained?", and that is the perspective from which
> many of us have questions.

For that is mostly an artifact of git, only a non-distributed VCS can 
"enforce" centralized development.

> If the whole question were just a matter of s/emailed patch/pull request/
> and *nothing else* I think I'd agree that there's no problem. The questions
> that are popping up are coming instead from trying to envision the next few
> steps out from "We started accepted pull requests on Github", i.e. the
> developer pressure on the rest of us to conform, "where will we do the code
> reviews", or the fear that development would naturally shift over to
> Github.

I understand and agree with the concern regarding social pressure to allow 
this form of patch submission on a global basis once it is allowed by some 
projects.

But I am still unsure on the "development will happen at github" part.

Development happens on the developers machine which, due to git, can be done 
without any server after the initial clone.

If developers want to cooperate on some work, they have, again due to git, 
several options, where using the original server (either as a branch or a 
personal clone on the server) is only one.

They could allow one to access the other's machine, or use a private server or 
use any of the git hosting providers.

What makes cloning from KDE's github mirror repository so different than 
uploading the code on your own?

> Because after all if you can now contribute to KDE *just* by submitting pull
> requests on your Github fork, then why bother getting a KDE development
> account? This is something we didn't really have to worry about with
> Bugzilla or emailed-patches because no one's masochistic enough to sustain
> extended development that way.

Well, when I started contributing to KDE, mailing patches was the only option.
And I would have easily continued doing that if my counterpart, the already 
accredited KDE developer, wouldn't have told me to basically either get a CVS 
account or get lost ;-)

Sure, the pull request is easier than to write a mail, but not a lot (sending 
a patch via email to the same recipient is easily scriptable).

The burden in either case is on the receiving KDE developers.
They become responsible for the patch, they either need to clean it up before 
pushing (on projects without review) or put it up for review and address all 
comments (for projects with review).

How likely is a developer going to do that longer than accepting patches via 
email.
For them this is almost the same overhead (almost since saving a patch and 
calling git am is slighlty more work than calling git pull on an already 
established remote).

> But on Github that workflow is already the default, it would be more work to
> go further and request a KDE identity.

Sure, for the new person that is true. But the "receivers" have to do more 
work than they would have if the new person would just simply get a KDE 
account.

Why burden yourself with extra work, potentially repeating extra work, if the 
other person only needs to 

Re: [kde-community] What is a GitHub pull request exactly?

[Eike Hein]

On 09/19/2015 10:32 PM, Kevin Krammer wrote:
> I don't see there this github review is coming from.

Review is an interactive process where you ask for changes and
iterate. Once you open the door to doing it on GitHub, you will:

* Have a hard time making some contributors understand why
  they should go through the trouble of moving to Phabricator
  in the midst of the review process, or next time.

* Have a hard time making some KDE developers understand why
  they shouldn't just do it on GitHub.

I don't understand why you expect thinks like "if it matters
people will take it to RB/Phab as second stage" or "after the
first patch we ask someone to get an account and switch to
Phab" will happen as a matter of course. It's so much more
likely that people who are comfortable with GitHub will ask
those who don't to comply (monitor it for requests, respond
to requests, participate), or they just won't be able to agree.

That's why I keep saying ... everything about this converges
on GitHub either being a full second review tool that is 100%
parallel to Phab, or not at all. Any other scenario is just
not viable: per-project opt-in can't work because the problems
just replicate on a smaller scale (see other subthread) and
two-stage review has way too much resistance and creating a
bot bridge between the two apps is too lossy.

So IMHO the debate should be entirely about whether we want
GitHub as a full second review tool or not. Some of the costs
to doing that are:

* We will lose some developers who don't agree with this.
* We will lose the benefits of having a single review tool
  (simplicity, efficiency, ...).
* We risk shrinking our infrastructure competence by making
  people less motivated to work on our own infrastructure.
* In turn we risk hurting the free infrastructure ecosystem
  which KDE has historically been a contributor to (e.g.
  we contributed to gitolite and other packages when we
  created git.kde.org).
* This arguably risks running counter to our mission of pro-
  liferating free software.
* It might hurt our integrity in the eyes of some people.
* It might hurt our viability as an independent project host
  community in the eyes of some people.
* Some people will enjoy working on KDE less.


Some of the potential gains are:
* Some people might enjoy working on KDE more because they
  really like GitHub.
* Some people might see it as a positive going-with-the-
  times step.
* We will possibly gain an additional contribution channel
  that has been suggested we can't really tap otherwise
  and could really use.


So this debate is about:

* Which of these do you feel more strongly about.

* Which of these do you think is easier to build a consensus
  around.


Cheers,
Eike
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Vishesh Handa]

On Sat, Sep 19, 2015 at 5:32 PM, Kevin Krammer  wrote:
> Where "ahead" could also mean wrong if "klmn" needs to be modified or gets
> rejected.
>
> Is (b) the problem people keep discussing about?
>
> Because as far as I can tell it is not really an option given that it can lead
> to an inconsistent state of two clone sources that are considered to be
> mirrored.
>

Yup (b) can be problematic. I think read-only means read-only and the
developer has to push the patch manually in kde's git repo, which is
then mirrors onto github.

> If the problem is somewhere in (a), where is it?
>

From what I understand, people are against some discussion or pull
requests being allowed at all. They should always be closed with a big
NO sign. I don't understand this or see the distinction between
github, email, and some other website.

--
Vishesh Handa
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Martin Graesslin]

On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> If the problem is somewhere in (a), where is it?

I'm afraid of code review happening through the pull request instead of our 
infrastructure. To me github pull requests are not just the "here's the 
patch", but also the code review.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Michael Pyne]

On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote:
> So (a) and (b) workflows differ in that in (a) github mirror and git.kde.org
> have the same state, while in (b) the mirror is for a period of time not
> actually a mirror, but "ahead".
> 
> Where "ahead" could also mean wrong if "klmn" needs to be modified or gets
> rejected.
> 
> Is (b) the problem people keep discussing about?

Kevin, first off thanks for taking all the time to diagram this in an email!

I think some of us are seeing this as simply an administrative or technical 
discussion of how we merge changes into git.kde.org in the presence of Github. 
I don't think it's really that at all, but instead a question of "where is the 
development happening" and "how is KDE [the community] staying involved/up-to-
date with that development"?

So I understand that from the perspective of "I already take patches by email, 
this is just another way of accepting new patches" this whole discussion might 
seem incredibly overdone. But there's another perspective of "how do we [KDE] 
ensure that our community values around common development are still 
maintained?", and that is the perspective from which many of us have 
questions.

If the whole question were just a matter of s/emailed patch/pull request/ and 
*nothing else* I think I'd agree that there's no problem. The questions that 
are popping up are coming instead from trying to envision the next few steps 
out from "We started accepted pull requests on Github", i.e. the developer 
pressure on the rest of us to conform, "where will we do the code reviews", or 
the fear that development would naturally shift over to Github.

Because after all if you can now contribute to KDE *just* by submitting pull 
requests on your Github fork, then why bother getting a KDE development 
account? This is something we didn't really have to worry about with Bugzilla 
or emailed-patches because no one's masochistic enough to sustain extended 
development that way.

But on Github that workflow is already the default, it would be more work to 
go further and request a KDE identity.

That wouldn't be a big problem for developers who were only going to toss us a 
patch or two anyways--no big loss in that department. But what about the 
developers might have joined but now see no need to?

That would lead us, eventually, into one of two situations:

a) Having to post developers to watch all of our Github mirrors and bring back 
pull requests, and eat the loss in possible KDE community contributors, and 
run the risk of increased reliance on Github infra for meaningful development.
b) Having to move official development closer to Github itself to be closer to 
where the new developers are (with the same risk of reliance).

There are ways around this, we could run concerted recruiting efforts to 
remind those submitting pull requests that there's a wider community behind 
the mirror and try to recruit that way, but that would have to be done *in 
concert* (and therefore, be discussed beforehand).

And none of that addresses things like ensuring that review happens in spots 
available to the KDE community (are you **really** going to re-review a pull 
request that had been reviewed on Github over on reviewboard.kde.org? Every 
time? Same for every developer?).

So when I say I'm opposed to this kind of thing it's not because I think the 
idea is completely stupid or that it's so off base, but rather that there 
*are* implications to this which we'd need to think through, especially in 
relation to the expected positive gain. It's not simply a flip the switch, 
allow pull requests, and it acts just like emailed patches...

Regards,
 - Michael Pyne
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Saturday, September 19, 2015 05:47:38 PM Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > If the problem is somewhere in (a), where is it?
> 
> I'm afraid of code review happening through the pull request instead of our 
> infrastructure. To me github pull requests are not just the "here's the
> patch", but also the code review.

Can we agree to have pull requests enabled in case the code review keeps 
happening on reviewboard? I think everybody could agree on that point...

Bye,
-Riccardo
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Martin Graesslin]

On Saturday, September 19, 2015 6:11:21 PM CEST you wrote:
> On Saturday, September 19, 2015 05:47:38 PM Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > > If the problem is somewhere in (a), where is it?
> > 
> > I'm afraid of code review happening through the pull request instead of
> > our
> > infrastructure. To me github pull requests are not just the "here's the
> > patch", but also the code review.
> 
> Can we agree to have pull requests enabled in case the code review keeps
> happening on reviewboard? I think everybody could agree on that point...

And how do we do that? Can we enforce this technically or will that be 
weakened over the time the same way as we just turned the mirror into "let's 
accept pull requests"?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Martin Klapetek]

On Sat, Sep 19, 2015 at 12:07 PM, Boudhayan Gupta  wrote:

> On 19 September 2015 at 21:17, Martin Graesslin 
> wrote:
> > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> >> If the problem is somewhere in (a), where is it?
> >
> > I'm afraid of code review happening through the pull request instead of
> our
> > infrastructure. To me github pull requests are not just the "here's the
> > patch", but also the code review.
>
> This.
>
> The other problem is that the PR submitter may not have a KDE
> identity, in which case we have no way of representing the fellow and
> properly crediting the commit to him/her. We have to explicitly
> redirect him to KDE's infrastructure for this.
>

That is not true. You can credit any commit to anyone

git commit --author "My Name "

which is a standard practice around KDE, when committing patches
on behalf of newcomers who don't have write access.

Cheers
-- 
Martin Klapetek | KDE Developer
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Martin Graesslin]

On Saturday, September 19, 2015 12:26:34 PM CEST Martin Klapetek wrote:
> On Sat, Sep 19, 2015 at 12:07 PM, Boudhayan Gupta  wrote:
> > On 19 September 2015 at 21:17, Martin Graesslin 
> > 
> > wrote:
> > > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > >> If the problem is somewhere in (a), where is it?
> > > 
> > > I'm afraid of code review happening through the pull request instead of
> > 
> > our
> > 
> > > infrastructure. To me github pull requests are not just the "here's the
> > > patch", but also the code review.
> > 
> > This.
> > 
> > The other problem is that the PR submitter may not have a KDE
> > identity, in which case we have no way of representing the fellow and
> > properly crediting the commit to him/her. We have to explicitly
> > redirect him to KDE's infrastructure for this.
> 
> That is not true. You can credit any commit to anyone
> 
> git commit --author "My Name "
> 
> which is a standard practice around KDE, when committing patches
> on behalf of newcomers who don't have write access.

In addition a nicely put commit through git format-patch and be applied 
through git am and then pushed with correct authorship.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Eike Hein]

On 09/19/2015 06:22 PM, Martin Graesslin wrote:
> And how do we do that? Can we enforce this technically or will that be 
> weakened over the time the same way as we just turned the mirror into "let's 
> accept pull requests"?

This wishy-washy stuff is nonsense. The sole argument for enabling
GitHub pull requests essentially boils down to "we have things
to gain from pandering to GitHub's audience that offset all
other costs", so when you limit the experience for that audience
anyway, the argument largely loses its merit. Doing GitHub badly
is worse than not doing GitHub at all.

It's either all-in or all-out. I'd like the pro side to be honest
about that, instead of doing this inching-toward-their-goal stuff.

Ultimately, this is about two conflicts:

* Ideological: Do you believe KDE can maintain its core free
  software philosophy while subjecting itself to the general
  tooling fashion cycle or not?

* Workflow: Do you think the day-to-day work experience will
  be better or worse?


Cheers,
Eike


___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Kevin Krammer]

On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > If the problem is somewhere in (a), where is it?
> 
> I'm afraid of code review happening through the pull request instead of our
> infrastructure. To me github pull requests are not just the "here's the
> patch", but also the code review.

But wouldn't that be just additional code review?

Either on top of no code review or on before actual code review for projects 
that require it?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:37 PM, Martin Graesslin  wrote:
> What's important to realize: the people have already written the patch at the
> point. Some time ago I wrote a patch for a software I hadn't contributed for
> before: figuring out how to submit the patch was more way than writing the
> patch. I did it because I wanted the patch in and didn't abandon because that
> project didn't use reviewboard which I know.


You're clearly better.

I have abandoned patches, and even failed to file bugs because it
required me to register and learn how to use a new service.

--
Vishesh Handa
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Martin Graesslin]

On Saturday, September 19, 2015 6:40:47 PM CEST Kevin Krammer wrote:
> On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > > If the problem is somewhere in (a), where is it?
> > 
> > I'm afraid of code review happening through the pull request instead of
> > our
> > infrastructure. To me github pull requests are not just the "here's the
> > patch", but also the code review.
> 
> But wouldn't that be just additional code review?
> 
> Either on top of no code review or on before actual code review for projects
> that require it?

do you really think that it would be reviewed again on KDE code review after 
it has gone through github review?

How would that process look like? Maintainer playing proxy by passing back the 
requested changes to the github developer?

No reality would be that it slowly moves code review from KDE to github. And I 
think we have here quite some people in the discussion who would love to see 
that :-(

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Eike Hein]

On 09/19/2015 06:53 PM, Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 06:44:24 PM Martin Graesslin wrote:
>> No reality would be that it slowly moves code review from KDE to github. And
>> I  think we have here quite some people in the discussion who would love to
>> see that
> 
> I don't think anyone ever thought that... o.o

No, I think the stance is more 'I wouldn't mind that if it
gets us more hands and I don't think it will make our soft-
ware less free or less useful'.

The people on the other side of the argument either don't
want to work with proprietary tools period, or think two
review sites are too many and we obviously can't give up
the free one, or think the long-term cost to KDE's credi-
bility is too high, or think it would alter the developer
community's demographics over time to where some of the
core values get lost, or have concerns about tooling
availability and data lock-in, or have concerns about
shrinking KDE's scope by outsourcing infrastructure
competence over time.

Both positions are non-trivial and difficult to bridge.


Cheers,
Eike
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Boudhayan Gupta]

On 19 September 2015 at 21:17, Martin Graesslin  wrote:
> On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
>> If the problem is somewhere in (a), where is it?
>
> I'm afraid of code review happening through the pull request instead of our
> infrastructure. To me github pull requests are not just the "here's the
> patch", but also the code review.

This.

The other problem is that the PR submitter may not have a KDE
identity, in which case we have no way of representing the fellow and
properly crediting the commit to him/her. We have to explicitly
redirect him to KDE's infrastructure for this.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

[Riccardo Iaconelli]

On Saturday, September 19, 2015 06:44:24 PM Martin Graesslin wrote:
> No reality would be that it slowly moves code review from KDE to github. And
> I  think we have here quite some people in the discussion who would love to
> see that

I don't think anyone ever thought that... o.o

-Riccardo

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community