Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/20/2015 01:31 PM, Anne Wilson wrote:
> Hehe! Only on a KDE list could an exhortion to stop bikeshedding become
> the latest bikeshed!

The Debian community is currently having a bikeshed over
whether to call a new community tool Bikeshed. We can't
hope to compete.


> Anne

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Anne Wilson]

On 19/09/2015 15:24, Eike Hein wrote:
> 
> 
> On 09/19/2015 02:12 PM, Myriam Schweingruber wrote:
>> Some of you wanted the mirror on Github because apparently there
>> are developers out there who are too lazy (or too dumb) to learn to
>> use new tools. Are those developers we want?
> 
> Developer recruitment should be our #1 problem for the next two
> years, and along those lines "GitHub might get us contributors" is by
> far the strongest argument that side's come up with.
> 
Hehe! Only on a KDE list could an exhortion to stop bikeshedding become
the latest bikeshed!

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Jaroslaw Staniek]

On 19 September 2015 at 21:08, Eike Hein  wrote:
>
>
> On 09/19/2015 08:58 PM, Kevin Krammer wrote:
>> Even using a review tool in the first place is something that the maintainer
>> asks people to do.
>
> No. We advertise ReviewBoard (and later Phab) as a general
> interface to throw code at our maintainers. "I don't look
> at ReviewBoard" is not a socially tenable position in our
> community in practice, just like "I don't look at GitHub"
> won't be*. The pressure will be to cover all places. Some
> people will say they don't want to or can't and abandon
> one for the other, and we'll have conflict over it and it
> will affect who develops for KDE and who maintains our
> products.
>
> If your (generic you) position is that people should be
> comfortable with GitHub and a KDE with only people who
> are comfortable with GitHub would be a better KDE, then
> you don't feel that is much of an issue, and that's more
> or less what some of the people in the discussion propose,
> unless they trick themselves into ideas like opt-in
> or two-stage review actually being viable in a general
> fashion.
>
> * = I've explained elsewhere why making GitHub opt-in
>   won't work, but in a nutshell: Repositories don't map
>   to projects; GitHub will spread over time across repo-
>   sitories because it's hard to opt out again; common
>   ownership implicitly means there are no "project X"
>   devs but only KDE devs, or rather that's what we would
>   like to see and optimize for, so GitHub for any repo
>   affects all devs.

Could you mention at least one KDE git repo that belongs to multiple
projects? And thus maybe multiple even multiple groups of maintainers?

-- 
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] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 08:58 PM, Kevin Krammer wrote:
> Even using a review tool in the first place is something that the maintainer 
> asks people to do.

No. We advertise ReviewBoard (and later Phab) as a general
interface to throw code at our maintainers. "I don't look
at ReviewBoard" is not a socially tenable position in our
community in practice, just like "I don't look at GitHub"
won't be*. The pressure will be to cover all places. Some
people will say they don't want to or can't and abandon
one for the other, and we'll have conflict over it and it
will affect who develops for KDE and who maintains our
products.

If your (generic you) position is that people should be
comfortable with GitHub and a KDE with only people who
are comfortable with GitHub would be a better KDE, then
you don't feel that is much of an issue, and that's more
or less what some of the people in the discussion propose,
unless they trick themselves into ideas like opt-in
or two-stage review actually being viable in a general
fashion.

* = I've explained elsewhere why making GitHub opt-in
  won't work, but in a nutshell: Repositories don't map
  to projects; GitHub will spread over time across repo-
  sitories because it's hard to opt out again; common
  ownership implicitly means there are no "project X"
  devs but only KDE devs, or rather that's what we would
  like to see and optimize for, so GitHub for any repo
  affects all devs.


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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Jaroslaw Staniek]

On 19 September 2015 at 21:24, Ivan Čukić  wrote:
>> Could you mention at least one KDE git repo that belongs to multiple
>
> Eike already mentioned that Plasma has a single repo in which
> different parts are maintained by different people.

But is Plasma a single project or not?
That's the case for the big calligra.git; Calligra is a single project
of somewhat related apps where people trust each other. Here I'd say
every maintainer has the right to veto and the decission about github
can be also delayed until there are any externally incoming patches.

Realistically I don't see anyone who can offer to be a proxy for
entire big repo. Maybe a  bot can be.
(For rather different reasons some calligra code splits out to smaller
repos that if really needed, can have separate policies)

Note: coincidentally just 10 minutes ago early question about code
issue arrived to a mailing list I maintain. I am in process of asking
the person if he can show me the code he tries to develop so we can
focus on the matter. Without forcing any git hosting solution. Maybe
that will be github which is mid road between, say, KDE and
LibreOffice. Who knows.
I'd just cherry-pick that to my scratch repo or to a feature branch in
official repo. Done.

The review would continue here within KDE. Then the code can fly, this
is git. But the records of the review belongs to KDE.
That's why I am safe talking about attracting users of GitHub.

But this shows that people need a place to upload the forked repos. We
as KDE do not give them write access until they are contributors. So
no access to scratch repos (I shouldn't even mention if these are
harder to use than the non-free competition, they are clearly too hard
for for a newbie who so far made a single commit and decides what
next).

-- 
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] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 09:13 PM, Jaroslaw Staniek wrote:
> Could you mention at least one KDE git repo that belongs to multiple
> projects? And thus maybe multiple even multiple groups of maintainers?

I have previously in the thread: Different subfolders in
plasma-desktop.git have different maintainers, and it's
not possible to toggle GitHub based on the preferences of
each individual maintainer or group of maintainers.

Which pushes this discussion simply one level down into
the 'plasma-desktop.git community', which just like the
git.kde.org community is comprised of separate projects
and stakeholders.

To wit:

* The social topology of our community doesn't match our
  repository structure, and I don't think we should tie
  one to the other because they stem from different
  needs.

* The idea of "common ownership" means we try to optimize
  kde.org specifically toward individual contributors not
  being silo'd into particular subcommunities but moving
  freely about, and trying not to insert barriers that
  make this harder or less likely. It's true that we want
  to allow subcommunities freedom over their ways of work-
  ing, and I'm not suggesting we don't. I am however
  suggesting that doing code review on GitHub for some
  projects and not others will in practice constitute such
  a barrier.


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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Kevin Krammer]

On Saturday, 2015-09-19, 20:32:43, Eike Hein wrote:
> On 09/19/2015 08:25 PM, Kevin Krammer wrote:
> > Saying "I don't look at the KDE review tool" would be like saying "I am
> > not
> > interested in your patch".
> 
> Saying "My personal productivity and efficiency matters more
> to me in the long-run than your patch, so please use the tool
> I prefer to reach me" happens all the time, and is a respect-
> able stance.
> 
> In fact, it's come up in this thread because that's what "I
> don't want to use two review sites even if having two means
> more patches than I would get otherwise" means.
> 
> It also comes up when someone says "please put this in BKO
> instead of telling me on IRC because not having all my data
> in one central location is a problem for me".
> 
> Simplicity and centralization matter. If there are two code
> review sites, some people will be willing to work with both
> of them, others will prefer one over the other. Some of the
> latter may pick GitHub.

Right. If a maintainer wants all patches via email, that is how they work.

Even using a review tool in the first place is something that the maintainer 
asks people to do. If you don't want to you don't override the maintainer's 
decision and push directly, do you?

So the hypothetical situation is that there is a KDE project who's maintainer 
does not want the contribution of any other KDE developer.

Their loss, no?

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] Bikeshedding - our strength apparently *sigh*

[Kevin Krammer]

On Saturday, 2015-09-19, 21:08:27, Eike Hein wrote:
> On 09/19/2015 08:58 PM, Kevin Krammer wrote:
> > Even using a review tool in the first place is something that the
> > maintainer asks people to do.
> 
> No. We advertise ReviewBoard (and later Phab) as a general
> interface to throw code at our maintainers. "I don't look
> at ReviewBoard" is not a socially tenable position in our
> community in practice, just like "I don't look at GitHub"
> won't be*. The pressure will be to cover all places. Some
> people will say they don't want to or can't and abandon
> one for the other, and we'll have conflict over it and it
> will affect who develops for KDE and who maintains our
> products.

So, right now, a maintainer is expected to check reviewboard even if they are 
content with all holders of commit accounts to push directly.
But that as soon as there is a second option, then not checking reviewboard 
becomes acceptable?

That would then be a bonus for all maintainers who don't want to use pre-push 
reviews. They no longer have any pressure to check any review tool.

So bascially a win-win-win situation.
Maintainers who do not care about review are free to not use any, maintainers 
who want contributions from other KDE developers use Phab and maintainers who 
do not want contributions from KDE developers use whatever they feel like 
using.

If we assume that the third group even exists.
Otherwise it is a plain win-win situation, still an improvement over the the 
lose-win situation we apparently have (maintainers being socially pressured 
into using reviewboard).

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] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 09:36 PM, Kevin Krammer wrote:
> So, right now, a maintainer is expected to check reviewboard even if they are 
> content with all holders of commit accounts to push directly.
> But that as soon as there is a second option, then not checking reviewboard 
> becomes acceptable?

That's in direct contradiction to what I wrote.

I found the rest of your mail hard to follow, sorry.


> Cheers,
> Kevin

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Sune Vuorela]

On 2015-09-19, Kevin Krammer  wrote:
>> No, I'm afraid of code review slowly moving from KDE to github up to =
> the
>> final point where I need to get a github account because otherwise I =
> cannot
>> contribute code.
>
> You mean that a KDE project would ignore your review request it it come=
> s from=20
> reviewboard/phabricator?

Or projects that I care about let's code in that way using that review
mechanism.

/Sune

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Kevin Krammer]

On Saturday, 2015-09-19, 19:58:26, Eike Hein wrote:
> On 09/19/2015 07:52 PM, Kevin Krammer wrote:
> > You mean that a KDE project would ignore your review request it it comes
> > from reviewboard/phabricator?
> 
> I think that's a realistic, even likely concern. We already
> know that some devs don't like using multiple code review
> sites concurrently from the gerrit and Phab trial runs, and
> it's conceivable that some developers might prefer GitHub to
> Phabricator. "Please file this on GitHub because I don't look
> at Phab" would be a matter of time.

I don't find that likely.
The trial runs were a different thing, equally valid alternatives.

Saying "I don't look at the KDE review tool" would be like saying "I am not 
interested in your patch".

A maintainer can always not accept a patch.

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] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 08:25 PM, Kevin Krammer wrote:
> Saying "I don't look at the KDE review tool" would be like saying "I am not 
> interested in your patch".

Saying "My personal productivity and efficiency matters more
to me in the long-run than your patch, so please use the tool
I prefer to reach me" happens all the time, and is a respect-
able stance.

In fact, it's come up in this thread because that's what "I
don't want to use two review sites even if having two means
more patches than I would get otherwise" means.

It also comes up when someone says "please put this in BKO
instead of telling me on IRC because not having all my data
in one central location is a problem for me".

Simplicity and centralization matter. If there are two code
review sites, some people will be willing to work with both
of them, others will prefer one over the other. Some of the
latter may pick GitHub.


> Cheers,
> Kevin

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 2:12 PM, Myriam Schweingruber  wrote:
> Wow, over 150 mails over that whole Github stuff, I am amazed.
>
> Let me chime in to give you a non-developer perspective: Caveat: some
> strong language ahead, but please take all this with a grain of salt
> :)
>
> Some of you wanted the mirror on Github because apparently there are
> developers out there who are too lazy (or too dumb) to learn to use
> new tools. Are those developers we want?
>

It's not about them being lazy or too dumb. It's about motivation.

If I see a typo or minor problem in Gnome, and I can easily just fix
it with the tools I know, it's a 1 minute detour. If I need to create
a new account, and learn a new set of tools, I won't bother. The end
result is that the contribution gets lost.

> Some now start arguing (despite the clear statement from the start
> that we will NOT accept pull-requests) to have an opt-in possibility
> for some, because those people on Github are too lazy (and maybe
> dumb!) to learn to use Reviewboard or Differential. Do we really want
> people like those?
>

I most certainly want all users who are willing to contribute.

> I heard people complaining about how reviewboard is difficult to use,
> then why can I, as a non-developer use it within minutes, just by
> reading instructions and thinking logically? Shouldn't all software
> developers be capable of that?
>

Again, capability has nothing to do with.

> I hear now the same messages from some: "Oh no, we are so used to
> reviewboard, why do we have to learn something new and apparently
> complicated to use!" what I read again here between the lines is "I am
> too lazy to learn to use Differential!", which is a matter of 2
> minutes apparently, I just tried it, it's really easy and I am NOT a
> developer. So why can I, a dumb translator who is an extremely crappy
> coder, do this and not you smart developers?
>

Again, not a question of intelligence.

> I remember people who were (and still are) core developers complaining
> they were too old to learn to use git which is so complicated. Guess
> what? I use git, and it really is easy, as there is a ton of
> documentation out there and one doesn't use a bazillion of commands in
> everyday use, maybe 10 at most. If somebody now would tell you they
> can't learn git because it is too complicated, what would you answer?
> Would you really want to collaborate with such a person?
>

Not as a rule, but yes I still would like to collaborate.

> In essence: we should stop that whole discussion which is simply the
> result of laziness on our behalf, because:
>
> You are developers, you learn new things every day (if not, I am
> worried), you are able to read documentation, you are able to find it
> without having to "ask for guidance" like a lazy student who has not a
> clue about coding, you are capable of using free tools for Free
> Software, because that is why we are all here: because we make Free
> Software!
>

Exactly we're here to make free software. Not to make others to agree
with all our ideals, and force them to change.

>
> Giving in to commodity and laziness in Free Software development is a
> bad thing, because it dilutes the idea of what Free Software is. So
> please everybody, rethink about our values and stop that silly thread
> about why or why not or how we should use a proprietary tool, because
> that is what Github is: proprietary, and we don't want that in Free
> Software!
>

I most certainly do want to use some parts of GitHub. Just as I want
windows, osx, coverity, intel's proprietary tools and opendesktop
(gasp!).

>
> Regards, Myriam
>
> PS. Don't get me started about my use of gmail, please, I am deeply
> ashamed about it and apparently too lazy to change... but I will reuse
> Kmail again as soon as it stops eating my mail every time I filter
> something and when Akonadi stops filling up my hard disk and memory
> and... etc. etc. Promised!)
>

There are other alternatives - Trojita, Thunderbird, Evolution, Kolab, etc.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 02:12 PM, Myriam Schweingruber wrote:
> Some of you wanted the mirror on Github because apparently there are
> developers out there who are too lazy (or too dumb) to learn to use
> new tools. Are those developers we want?

Developer recruitment should be our #1 problem for the
next two years, and along those lines "GitHub might get
us contributors" is by far the strongest argument that
side's come up with.


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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Michael Pyne]

On Sat, September 19, 2015 16:24:13 Eike Hein wrote:
> On 09/19/2015 02:12 PM, Myriam Schweingruber wrote:
> > Some of you wanted the mirror on Github because apparently there are
> > developers out there who are too lazy (or too dumb) to learn to use
> > new tools. Are those developers we want?
> 
> Developer recruitment should be our #1 problem for the
> next two years, and along those lines "GitHub might get
> us contributors" is by far the strongest argument that
> side's come up with.

Agreed, but yet, I'm not sure that it's really that strong. KDE is far too 
large (effectively its own ecosystem now) to rely on increased 'foot traffic' 
from new developers alone for recruiting. We would need a recruiting and 
*incubation* program of some sort, in my opinion... but we'll never get that 
without a good deal of investment of time and energy from our existing devs, 
and that is something we are perennially short of.

Even the relatively-successful GSoC program, which is subsidized in great part 
by Google Inc., requires substantial (and unseen) effort behind the scenes by 
kde.org administrators and student mentors.

With an improvement to recruiting/incubation then *maybe* increased attention 
by more active participation on Github would start to help... but on the other 
hand it could just as likely simply result in specific applications getting a 
recruiting boost from developers who'll never intend to help with KDE as a 
whole.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Riccardo Iaconelli]

On Saturday, September 19, 2015 04:24:13 PM Eike Hein wrote:
> Developer recruitment should be our #1 problem for the
> next two years, and along those lines "GitHub might get
> us contributors" is by far the strongest argument that
> side's come up with.

Somebody once defined Github as the "social network of hackers". I don't see 
then why we should have a Facebook page and not one on Github. ;-)

If somebody happened to send me some material for WikiToLearn through the 
Facebook page (it has happened), I don't reject it asking him/her to resend it 
to the mailing list, because that would never work. I accept the material, 
thank the person, and point out they can also subscribe to the mailing list, 
if they are interested to keep an eye on it.

And this is exactly how we got one of our now most important contributors. Did 
I loose my soul or my values? The project just grew stronger.

Bye,
-Riccardo

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Boudhayan Gupta]

On 19 September 2015 at 20:28, Michael Pyne  wrote:
> My personal feeling is that opting to go the actual-development-on-Github
> route would simply introduce a schism in development workflow, despite the
> best intentions of any party. And if you think *these* threads are filled with
> bikeshedding, just wait until that break occurs...

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Kevin Krammer]

On Saturday, 2015-09-19, 17:19:16, Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 10:58:09 AM Michael Pyne wrote:
> > Is anyone actually arguing this point in the way you ask? No one's asking
> > to  prevent "one offs" entirely, the core of the issue is that KDE
> > development should happen *within* KDE-the-whole-community, not *apart
> > from* KDE.
> 
> Nobody is proposing to move there the development! And pull requests are
> really "one offs", no stable contributor would sensibly use them as a
> regular basis, just like no stable contributor doesn't get an account and
> develops only through mailing patches...
> 
> This whole thread started with one sentence which started like "if somebody
> sends me a patch, it doesn't matter if she/he sends it to me via mail,
> github, or by post... if it's good work, I am going to integrate it". I
> think we should keep to that and not escalate it to "some KDE projects move
> to github for development".
> 
> I think there was some confusion on that point, so let me state this again:
> the agreement is that github mirrors ARE going to be kept read-only, so
> someone with a KDE account and the developer karma still has to push the
> patch to git.kde.org (or reviewboard or so on...), if he wants to see it
> integrated. I don't see how that destroys our values. I just see it as a
> way through which potential newcomers can submit their first contribution,
> instead of mailing a patch.
> 
> At least, in my view, the mirrors will STILL be *READ-ONLY*.

Exactly!

How would a mirror even be read/write?
We are not going to upload a private key to github to allow some script there 
to push and we are not going to automatically and blindly pull and merge from 
github either, no?

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] Bikeshedding - our strength apparently *sigh*

[Michael Pyne]

On Sat, September 19, 2015 16:42:54 Riccardo Iaconelli wrote:
> If somebody happened to send me some material for WikiToLearn through the
> Facebook page (it has happened), I don't reject it asking him/her to resend
> it to the mailing list, because that would never work. I accept the
> material, thank the person, and point out they can also subscribe to the
> mailing list, if they are interested to keep an eye on it.
> 
> And this is exactly how we got one of our now most important contributors.
> Did I loose my soul or my values? The project just grew stronger.

Is anyone actually arguing this point in the way you ask? No one's asking to 
prevent "one offs" entirely, the core of the issue is that KDE development 
should happen *within* KDE-the-whole-community, not *apart from* KDE.

The way we know best to do this is to prefer the use of the infrastructure we 
as a community have setup for that purpose, and to avoid diluting that 
infrastructure (which has its own positive network effects). If you've ever 
licensed software under a GPL instead of BSD license then you agree with the 
logic, even if you don't realize it's the same here. ;)

Maybe there's a way to integrate pull requests into a KDE community workflow 
that meets the intent of what we're trying to do without subsuming the 
existing workflow completely (Github can't be allowed to subsume the whole 
deal because it's proprietary). But IMHO we're not at a stage where that's 
been clearly described how that could work.

My personal feeling is that opting to go the actual-development-on-Github 
route would simply introduce a schism in development workflow, despite the 
best intentions of any party. And if you think *these* threads are filled with 
bikeshedding, just wait until that break occurs...
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Riccardo Iaconelli]

On Saturday, September 19, 2015 10:58:09 AM Michael Pyne wrote:
> Is anyone actually arguing this point in the way you ask? No one's asking
> to  prevent "one offs" entirely, the core of the issue is that KDE
> development should happen *within* KDE-the-whole-community, not *apart
> from* KDE.

Nobody is proposing to move there the development! And pull requests are 
really "one offs", no stable contributor would sensibly use them as a regular 
basis, just like no stable contributor doesn't get an account and develops 
only through mailing patches...

This whole thread started with one sentence which started like "if somebody 
sends me a patch, it doesn't matter if she/he sends it to me via mail, github, 
or by post... if it's good work, I am going to integrate it". I think we 
should keep to that and not escalate it to "some KDE projects move to github 
for development".

I think there was some confusion on that point, so let me state this again: 
the agreement is that github mirrors ARE going to be kept read-only, so 
someone with a KDE account and the developer karma still has to push the patch 
to git.kde.org (or reviewboard or so on...), if he wants to see it integrated. 
I don't see how that destroys our values. I just see it as a way through which 
potential newcomers can submit their first contribution, instead of mailing a 
patch.

At least, in my view, the mirrors will STILL be *READ-ONLY*.

Bye,
-Riccardo

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Martin Graesslin]

On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 10:58:09 AM Michael Pyne wrote:
> > Is anyone actually arguing this point in the way you ask? No one's asking
> > to  prevent "one offs" entirely, the core of the issue is that KDE
> > development should happen *within* KDE-the-whole-community, not *apart
> > from* KDE.
> 
> Nobody is proposing to move there the development! And pull requests are
> really "one offs", no stable contributor would sensibly use them as a
> regular basis, just like no stable contributor doesn't get an account and
> develops only through mailing patches...
> 
> This whole thread started with one sentence which started like "if somebody
> sends me a patch, it doesn't matter if she/he sends it to me via mail,
> github, or by post... if it's good work, I am going to integrate it". I
> think we should keep to that and not escalate it to "some KDE projects move
> to github for development".
> 
> I think there was some confusion on that point, so let me state this again:
> the agreement is that github mirrors ARE going to be kept read-only, so
> someone with a KDE account and the developer karma still has to push the
> patch to git.kde.org (or reviewboard or so on...), if he wants to see it
> integrated. I don't see how that destroys our values. I just see it as a
> way through which potential newcomers can submit their first contribution,
> instead of mailing a patch.
> 
> At least, in my view, the mirrors will STILL be *READ-ONLY*.

I disagree. What I write now I mean for anything hosted under KDE/* and not 
e.g. mgraesslin/*

If we have some projects accepting pull requests it creates pressure for other 
projects to also accept pull requests. This means my identity.kde.org account 
is no longer enough to maintain a KDE project.

Pullrequests in the github are more than a way to submit a patch. It's also 
code review. At the point where this would happen, part of the community is 
excluded from participating in the code review process. Even more part of our 
code actually moves to github. Previous versions of the patch are then only 
available through github infrastructure.

Thus I see the requests of allowing github pull requests as a way to move 
development to github.

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] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 07:52 PM, Kevin Krammer wrote:
> You mean that a KDE project would ignore your review request it it comes from 
> reviewboard/phabricator?

I think that's a realistic, even likely concern. We already
know that some devs don't like using multiple code review
sites concurrently from the gerrit and Phab trial runs, and
it's conceivable that some developers might prefer GitHub to
Phabricator. "Please file this on GitHub because I don't look
at Phab" would be a matter of time.


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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 5:53 PM, Martin Graesslin  wrote:
> My fear here is that if we allow pull request, people will also start to use
> them for code review at which point we have split the development team in
> those doing code review through reviewboard and those through github.


We already use some other forms of code review -

* IRC
* Email
* IM
* Google+ Hangouts (Just discussed some things related to the Baloo
KCM a week ago)
* Knocking on David's door and screaming "I need you to look at some code"

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Martin Graesslin]

On Saturday, September 19, 2015 5:57:09 PM CEST Eike Hein wrote:
> On 09/19/2015 05:54 PM, Riccardo Iaconelli wrote:
> > while rejecting them autmatically isjust a great way to drive potential
> > contributors away...
> 
> Which is a good reason why the mirror shouldn't have happened
> - regret being on vacation during that time.

If I had known this would happen I would not have proposed it. I'm deeply 
sorry that I initiated this project.

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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:04 PM, Martin Graesslin  wrote:
>> * Google+ Hangouts (Just discussed some things related to the Baloo
>> KCM a week ago)
> closed

Martin. There are weekly Plasma meetings on Google+! Those are as
essential as code review. They control the direction of the project
and issues are discussed over there.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Kevin Krammer]

On Saturday, 2015-09-19, 17:53:17, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote:

> > The patch would still go through review at KDE. Even with no github at all
> > a patch could have been through several revisions before being submitted.
> > The review always deals with the "final" submission (obviously not final
> > if things need to be changed).
> 
> KDE does not have mandatory code review. I have to admit that I as a
> maintainer have quite often pushed commits directly which went to me by mail
> because I then reviewed them before pushing. Why uploading just to press
> shipit?

Right.
I was just saying that the workflow would be the same.
Patches of new contributors would go through review, either formal or by an 
established contributor, just like they would now.

> My fear here is that if we allow pull request, people will also start to use
> them for code review at which point we have split the development team in
> those doing code review through reviewboard and those through github.

You mean that if a project currently doesn't to reviews, it would start doing 
so due to accepting github contributions and then doing those on github 
instead of the KDE tool?

Hmm, haven't though of that.

But wouldn't that, from the point of view of anyone else (existing 
contributors, other KDE contributors) just be like the status before? I.e. no 
code review?
Just that the patches that get pushed are potentially of higher quality 
because they had actually been reviewed?

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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:24 PM, Eike Hein  wrote:
>
> I expect you'll ignore this as much as my other mail, but
> all of these are ephemeral in nature instead of offering
> a persistent record -- that's why we submit minutes of the
> Hangouts to the plasma-devel mailing list, for example.
>

I assure you it isn't on purpose. There are quite a lot of emails flying around.

> A code review website maintains a persistent record and is
> therefore used differently, and should be subject to
> different requirements.
>
> For that reason code review discussions on IRC often lead
> to "please put this on ReviewBoard".

"often" but not always.

We have to be able to use our best judgement. If I get a patch on
gtihub and I think that should be discussed more, I'll probably send
them to reviewboard, in other cases, I won't.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Martin Graesslin]

On Saturday, September 19, 2015 6:38:26 PM CEST Kevin Krammer wrote:
> On Saturday, 2015-09-19, 17:53:17, Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote:
> > > The patch would still go through review at KDE. Even with no github at
> > > all
> > > a patch could have been through several revisions before being
> > > submitted.
> > > The review always deals with the "final" submission (obviously not final
> > > if things need to be changed).
> > 
> > KDE does not have mandatory code review. I have to admit that I as a
> > maintainer have quite often pushed commits directly which went to me by
> > mail because I then reviewed them before pushing. Why uploading just to
> > press shipit?
> 
> Right.
> I was just saying that the workflow would be the same.
> Patches of new contributors would go through review, either formal or by an
> established contributor, just like they would now.
> 
> > My fear here is that if we allow pull request, people will also start to
> > use them for code review at which point we have split the development
> > team in those doing code review through reviewboard and those through
> > github.
> You mean that if a project currently doesn't to reviews, it would start
> doing so due to accepting github contributions and then doing those on
> github instead of the KDE tool?
> 
> Hmm, haven't though of that.
> 
> But wouldn't that, from the point of view of anyone else (existing
> contributors, other KDE contributors) just be like the status before? I.e.
> no code review?
> Just that the patches that get pushed are potentially of higher quality
> because they had actually been reviewed?

No, I'm afraid of code review slowly moving from KDE to github up to the final 
point where I need to get a github account because otherwise I cannot 
contribute code.

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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:46 PM, Martin Graesslin  wrote:
> No, I'm afraid of code review slowly moving from KDE to github up to the final
> point where I need to get a github account because otherwise I cannot
> contribute code.

When/If that actually happens, you can bring it up and then we can
deal with it. Dealing in extreme What-Ifs does not help this
discussion.

I can argue that KDE should not be hosting Windows binaries of
applications because that promotes Windows, and slowly it will be
impossible to contribute without Windows.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Martin Graesslin]

On Saturday, September 19, 2015 6:49:48 PM CEST Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 6:46 PM, Martin Graesslin  
wrote:
> > No, I'm afraid of code review slowly moving from KDE to github up to the
> > final point where I need to get a github account because otherwise I
> > cannot contribute code.
> 
> When/If that actually happens, you can bring it up and then we can
> deal with it. Dealing in extreme What-Ifs does not help this
> discussion.

yeah well, we also said github is only a mirror and pull requests are a non-
issue. Sorry but I at the moment have lost all trust.

Apart from that: then it's too late. Those who argue now for the pull requests 
will argue for it. If I want to keep the development on free infrastructure I 
must oppose before we start using non-free infrastructure - and please don't 
come now with Google+.

> 
> I can argue that KDE should not be hosting Windows binaries of
> applications because that promotes Windows, and slowly it will be
> impossible to contribute without Windows.
> 
> --
> Vishesh Handa
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community


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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 7:03 PM, Luca Beltrame  wrote:
> Il Sat, 19 Sep 2015 18:49:48 +0200, Vishesh Handa ha scritto:
>
>> When/If that actually happens, you can bring it up and then we can deal
>> with it. Dealing in extreme What-Ifs does not help this discussion.
>
> To be honest I don't want the "if" to happen, ever.

Neither do I, but no-one has any evidence to claim that it will. Going
to extremes and assuming the worst does not help. Now I need to defend
the extreme I'm not even advocating.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Kevin Krammer]

On Saturday, 2015-09-19, 17:36:09, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote:

> > I think there was some confusion on that point, so let me state this
> > again:
> > the agreement is that github mirrors ARE going to be kept read-only, so
> > someone with a KDE account and the developer karma still has to push the
> > patch to git.kde.org (or reviewboard or so on...), if he wants to see it
> > integrated. I don't see how that destroys our values. I just see it as a
> > way through which potential newcomers can submit their first contribution,
> > instead of mailing a patch.
> > 
> > At least, in my view, the mirrors will STILL be *READ-ONLY*.
> 
> I disagree. What I write now I mean for anything hosted under KDE/* and not
> e.g. mgraesslin/*
> 
> If we have some projects accepting pull requests it creates pressure for
> other projects to also accept pull requests. This means my identity.kde.org
> account is no longer enough to maintain a KDE project.

This is the concern I understand.
Some projects accepting such requests (whatever that means, still unclear on 
that) could easily create the expectation that all projects do.

> Pullrequests in the github are more than a way to submit a patch. It's also
> code review. At the point where this would happen, part of the community is
> excluded from participating in the code review process. Even more part of
> our code actually moves to github. Previous versions of the patch are then
> only available through github infrastructure.

I am not quite sure I understand this concern.
The patch would still go through review at KDE. Even with no github at all a 
patch could have been through several revisions before being submitted.
The review always deals with the "final" submission (obviously not final if 
things need to be changed).

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] Bikeshedding - our strength apparently *sigh*

[Martin Graesslin]

On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote:
> On Saturday, 2015-09-19, 17:36:09, Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote:
> > > I think there was some confusion on that point, so let me state this
> > > again:
> > > the agreement is that github mirrors ARE going to be kept read-only, so
> > > someone with a KDE account and the developer karma still has to push the
> > > patch to git.kde.org (or reviewboard or so on...), if he wants to see it
> > > integrated. I don't see how that destroys our values. I just see it as a
> > > way through which potential newcomers can submit their first
> > > contribution,
> > > instead of mailing a patch.
> > > 
> > > At least, in my view, the mirrors will STILL be *READ-ONLY*.
> > 
> > I disagree. What I write now I mean for anything hosted under KDE/* and
> > not
> > e.g. mgraesslin/*
> > 
> > If we have some projects accepting pull requests it creates pressure for
> > other projects to also accept pull requests. This means my
> > identity.kde.org
> > account is no longer enough to maintain a KDE project.
> 
> This is the concern I understand.
> Some projects accepting such requests (whatever that means, still unclear on
> that) could easily create the expectation that all projects do.
> 
> > Pullrequests in the github are more than a way to submit a patch. It's
> > also
> > code review. At the point where this would happen, part of the community
> > is
> > excluded from participating in the code review process. Even more part of
> > our code actually moves to github. Previous versions of the patch are then
> > only available through github infrastructure.
> 
> I am not quite sure I understand this concern.
> The patch would still go through review at KDE. Even with no github at all a
> patch could have been through several revisions before being submitted. The
> review always deals with the "final" submission (obviously not final if
> things need to be changed).

KDE does not have mandatory code review. I have to admit that I as a 
maintainer have quite often pushed commits directly which went to me by mail 
because I then reviewed them before pushing. Why uploading just to press 
shipit?

My fear here is that if we allow pull request, people will also start to use 
them for code review at which point we have split the development team in 
those doing code review through reviewboard and those through github.

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] Bikeshedding - our strength apparently *sigh*

[Riccardo Iaconelli]

I understand the takeover concern, it is a valid point. If I become the 
maintainer of application X, which was accepting pull requests, and I don't 
want to have a github account, I either have to create an account, find 
somebody on the team who wants to monitor pull requests, or change the 
project's policy.
I still think that in this case the benefits on the advertisement outweight 
the problems (a change of policy due change of maintainership and nobody in 
the team wanting a github account).

On Saturday, September 19, 2015 05:36:09 PM Martin Graesslin wrote:
> Pullrequests in the github are more than a way to submit a patch. It's also 
> code review. At the point where this would happen, part of the community is
> excluded from participating in the code review process. Even more part of
> our code actually moves to github. Previous versions of the patch are then
> only available through github infrastructure.

Any patch which needs any kind of serious reviewing will still have to go 
through reviewboard, nobody would use github's interface for that. How many 
these patches are clearly depends on the type of the project.

For me a pull request is just a great opportunity to say:
"hey, thanks a lot for your patch, I just pushed it to the main repository and 
it works great! If you want to continue submitting patches, I would suggest 
you get a KDE account by registering here , so you have proper access to 
all KDE tools that help us in our development"

while rejecting them autmatically isjust a great way to drive potential 
contributors away...

Bye,
-Riccardo

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 05:54 PM, Riccardo Iaconelli wrote:
> while rejecting them autmatically isjust a great way to drive potential 
> contributors away...

Which is a good reason why the mirror shouldn't have happened
- regret being on vacation during that time.


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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Eike Hein]

On 09/19/2015 05:58 PM, Vishesh Handa wrote:
> We already use some other forms of code review -
> 
> * IRC
> * Email
> * IM
> * Google+ Hangouts (Just discussed some things related to the Baloo
> KCM a week ago)
> * Knocking on David's door and screaming "I need you to look at some code"

I expect you'll ignore this as much as my other mail, but
all of these are ephemeral in nature instead of offering
a persistent record -- that's why we submit minutes of the
Hangouts to the plasma-devel mailing list, for example.

A code review website maintains a persistent record and is
therefore used differently, and should be subject to
different requirements.

For that reason code review discussions on IRC often lead
to "please put this on ReviewBoard".


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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:58 PM, Martin Graesslin  wrote:
>> When/If that actually happens, you can bring it up and then we can
>> deal with it. Dealing in extreme What-Ifs does not help this
>> discussion.
>
> yeah well, we also said github is only a mirror and pull requests are a non-
> issue. Sorry but I at the moment have lost all trust.

Just because some people agreed to a read-only mirror that does not
mean everyone did.

>
> Apart from that: then it's too late. Those who argue now for the pull requests
> will argue for it.

Please don't act as though you know what is going to happen. You don't
and you have no evidence to claim anything like this.

> If I want to keep the development on free infrastructure I
> must oppose before we start using non-free infrastructure - and please don't
> come now with Google+.

Alright. Lets talk about Windows and Android then? You haven't
answered that part of my email.

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

Re: [kde-community] Bikeshedding - our strength apparently *sigh*

[Martin Graesslin]

On Saturday, September 19, 2015 7:04:46 PM CEST Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 6:58 PM, Martin Graesslin  
wrote:
> >> When/If that actually happens, you can bring it up and then we can
> >> deal with it. Dealing in extreme What-Ifs does not help this
> >> discussion.
> > 
> > yeah well, we also said github is only a mirror and pull requests are a
> > non- issue. Sorry but I at the moment have lost all trust.
> 
> Just because some people agreed to a read-only mirror that does not
> mean everyone did.

Well we agreed on something. As I have already said: I feel quite fooled by 
some members of the KDE community.

> 
> > Apart from that: then it's too late. Those who argue now for the pull
> > requests will argue for it.
> 
> Please don't act as though you know what is going to happen. You don't
> and you have no evidence to claim anything like this.

Should we bet?

> 
> > If I want to keep the development on free infrastructure I
> > must oppose before we start using non-free infrastructure - and please
> > don't come now with Google+.
> 
> Alright. Lets talk about Windows and Android then? You haven't
> answered that part of my email.

Because I honestly think that the comparison with Windows and Android matters. 
It's a completely different topic, and I don't want to derail into that 
discussion.

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