Re: [kde-community] Renaming KScreenGenie

[Rajeev Bhatta]

Selfie is better than Kapture for sure.. :)

On Saturday, September 19, 2015 08:38:41 PM Eike Hein wrote:
> On 09/19/2015 08:32 PM, Rajeev Bhatta wrote:
> > If we can choose the name Selfie and then it is important to have the
> > users
> > relate to it as a product too then it works, if we cannot target that then
> > we should not name it such...
> 
> I feel like Selfie is more likely to create an emotional
> bond than Kapture. That's a gut feeling; it's hard to
> substantiate.
> 
> 
> 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: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] Help for sprint guidance/organization

[Martin Klapetek]

Hey,

so I haven't really organized any sprints myself but have participated
in many, some good, some less good. So here's my personal take
on this speaking from experience:

* always make everyone feel like they belong to the group and to the sprint

* if it's a random group that have never met before, sometimes a short
introductory
round might be nice, also kind of an icebreaker

* have a list of tasks for grabs and have everyone report on their progress,
at least once a day, perhaps before the end of the day as well as state
what their plans are, ask questions (even obvious ones, they will feel more
included)

* that lists of tasks can be created at the beginning with a brainstorming
of "what I want to do and what I would like to see done"

* coordinate often. The worst part on a sprint is if you're sitting there,
unsure
what to do so you just do your own thing about which nobody cares/asks

* have smaller breakout sessions (when a smaller group separates and
discusses some particular issues) from time to time, make other people
lead those breakouts

* have fun as a group - restaurants in the evening serve well, especially
if you get different table setup each time (so different people talk to
different
people every night). This one should be treated carefully though because
restaurants are not sponsored, so beware of picking an expensive restaurant
and then people ending up with appetizers only cause they can't afford food.
Related to that is a quick poll of "where should we eat tonight?" so that
people
also have a say (and again feel included in the sprint)

* it's nice to have at least one night of beers and pizza out of
restaurant, imho
it's better socializing (and a well socialized group means better working
group)

* sometimes a sprint competition of some kind can be nice too, can serve
as a motivation. For example who will have most closed bugs at the end of
the
sprint (have an up-to-date progress somewhere big and visible), just make
sure
that competition is not the center of the sprint, it needs to be just an
additional
fun (so that those not winning won't feel like failures)

That's all I can think of right now, I'll add more if something comes to
mind :)

Cheers
-- 
Martin Klapetek | KDE Developer
___
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] 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] Renaming KScreenGenie

[Myriam Schweingruber]

You made me giggle with that :

On Sat, Sep 19, 2015 at 3:16 PM, Eike Hein  wrote:
>
>
> On 09/19/2015 11:36 AM, rajeev bhatta wrote:
>> Like the name selfie..but it will be nightmare finding the app in google
>> if looking for selfie
>
> No it won't. People aren't too dumb to add an extra
> keyword. Internet search is a well-developed skill
> for anyone under 30 at this point.

Erm, sorry, no. I have had enough interaction with wannabe GSoC
students to know this is in no way true, many are not even able to
perform the most basic search involving 2 keywords, let alone more
complex searches. Implying that under 30 means tech savvy is a very
big leap you take, there :) So no, people are indeed too dumb to use 2
keywords, in very many cases. And if they don't find something in the
first 3 lines they give up and ask instead, so others do it for them
(something they don't even think of, duh!).

> Plus, why would internet searches be common in the
> first place? I've never searched for KSnapshot. Have
> you?

Well, I have in the past, and I do a lot of searches on a daily basis.
I am almost double the 30 threshold you use and another example on why
your assumption is wrong ;-)

SCNR

Regards, Myriam


-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)
___
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] 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] 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] 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] 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] 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] Write our own pull request bot?

[Laszlo Papp]

Hi Martin,

On Sat, Sep 19, 2015 at 6:49 PM, Martin Klapetek
 wrote:
> On Sat, Sep 19, 2015 at 1:42 PM, Laszlo Papp  wrote:
>>
>>
>> Sure, but why would increase this situation further on?
>
>
> Sorry, I don't understand this question.

I missed the subject "we" in that sentence, apparently; I apologise.

What I was trying to say is the fact that you mentioned an existing
unfortunate situation and instead of reducing that as muc as possible,
you seem to put it as an excuse for potentially increasing that
further on. In other words, I would go the other way around: how can
we reduce the personal emails? Perhaps, we need to be more explicit? I
understand and appreciate that it cannot be entirely eliminated, but I
do not think it is wise to argue with them for a suboptimal case.

>> I agree with everything that Sune wrote. Reaching them might be
>> particularly important when changing license just for one of those.
>> There could be numerous other valid examples.
>>
>> Why put energy into making sure that they can diverge from the normal
>> workflow rather than putting energy on making sure that the workflow
>> is known and easy to get?
>
>
> To get the best of both worlds.

It is not all sweetie and cookie, I believe. It is not a win/win as
the long and many emails show. :)

There are drawbacks coming with that, so you will not necessarily get
the best of both words in my personal opinion, but we may respectfully
agree to disagree in there. That is fine.

>> There used to be life before github, too. This is exactly the vendor
>> lock-in, when some people can no longer breat without it for such
>> simple things.
>
>
> We wouldn't get no lock-in though. Not even remotely. It will simply
> be another path for an incoming patch. If the patch in question ends
> up on Phabricator and gets reviewed on Phabricator and merged from
> Phabricator, it is no different than the patch initially arriving by email,
> irc/paste etc. Just a different input route.

Yeah, I apologise; I did not mean a lock-in for KDE, but for the
mindset of those "newbie contributors". I will reiterate it once again
in the same email not to skip my point when considering my email: we
ought to put more focus on how to propagate the right infrastructure
rather than putting energy into circumventing that. We do not have
unlimited resources. As some other people already wrote it, I would
hate to explain it all the time, why I do not support the opt-in
feature in my own project. It would get tedious, if not demotivating,
over time.

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

Re: [kde-community] Write our own pull request bot?

[Martin Klapetek]

On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein  wrote:

> On 09/19/2015 07:49 PM, Martin Klapetek wrote:
> > We wouldn't get no lock-in though. Not even remotely. It will simply
> > be another path for an incoming patch. If the patch in question ends
> > up on Phabricator and gets reviewed on Phabricator and merged from
> > Phabricator, it is no different than the patch initially arriving by
> email,
> > irc/paste etc. Just a different input route.
>
> That doesn't address Sune's concern though. If you
> get a patch by email you can reply by email; the
> comm channel stays the same. Ditto IRC. If you file
> a pull req on GitHub and it gets imported into Phab
> which you don't have an account for yet and can't
> interact with using the same client (git, or the
> website you were using) you were already using, you
> are inserting a hump in that. The requestee wouldn't
> even get emails about review comments unless the bot
> does complicated steps like trying to use the GitHub
> API to read out an account email (if it even can).
>

You'd have the email from the commit already though.

The bot could be extended (over time, even) to be capable of posting
comments back, even a simple "there's a new comment on your patch
at ". If the user will care, s/he will care. If not, then it ends up
as hundreds of already unattended patches on reviewboard, where the
original submitter didn't respond to questions and/or didn't update the
patch.

A concrete example: https://git.reviewboard.kde.org/r/105932/

Patch from 2012 with open questions/issues from a newcomer(?), left
unattended. Having the same on Phabricator with the source being github
would be no different, would it? And there _will_ be patches left to rot
on Phabricator anyway, just like hundreds of them right now on Reviewboard.

Auto-import is a slight improvement over auto-reject
> on the "it snubs people" front, but it's not a big
> one and it creates a lot of practical concerns. Some
> of those could be addressed with more code, if some-
> one writes it - but then it should be written and
> tested and evluated before we enable that channel.
>

Sure. It's _a_ solution. I don't claim it's a perfect one, but it is one.

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?

[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

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] Official KDE mirror on github

[Shantanu Tushar Jha]

On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin 
wrote:

> On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote:
> > From my experience, I was already mirroring KDE Connect in Github and
> I've
> > received valuable patches there. That's a big enough reason for me to
> want
> > Github's pull requests (and to spend 15 minutes learning how to use
> them),
> > but I understand not everybody wants to learn a new and non-free tool.
>
> I'm subscribed to kde-connects review requests for reviewboard. How am I
> as an
> interested developer able to follow the code review for github pull
> requests
> if I don't want to use them?
>
> Basically by the decision to opt-in for pull requests you force the
> complete
> team to follow them. Otherwise not-reviewed code gets in.
>
> We really need to think in the big picture of what means this to KDE. We
> shouldn't go the "selfish" road and think of your own project. By allowing
> github pull-requests we are pushing out the contributors who don't want to
> use
> it. You make it impossible for those contributors to comment on review
> requests, thus you have split the development.
>
> This is scary. Please don't think "selfish". Let people create the pull
> request and answer it with:
> "Sorry we do not support git hub pull request. To submit code please use
> reviewboard.kde.org. Here's how you do it..."
>
> The point is we want to get to the people on github. That's why we mirror.
> It's not about getting pull requests. We want the people! They already
> spent
> the effort to create the patch, they will spent the additional time to get
> to
> reviewboard of phabricator in future. I have so often got patches on
> bugzilla
> and it never was a problem to tell them "please use reviewboard for the
> patch
> submission as the UI is more streamlined for code review". We always got
> the
> patch into reviewboard. The aim of the people is not to use pull requests,
> the
> aim is to submit their patch!
>

+1 to that. And adding to it, IMO the most important thing here is
consistency. The last thing we want to have is newcomers getting confused
"erm, so for this KDE project do I use reviewboard? or do I create a pull
request?".


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

Cheers,

-- 
Shantanu Tushar(UTC +0530)
shantanu.io
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

[Jaroslaw Staniek]

On Saturday, 19 September 2015, Albert Astals Cid  wrote:
> El Divendres, 18 de setembre de 2015, a les 23:42:02, Jaroslaw Staniek va
> escriure:
>>
>> Your experience may differ and I value that. Opt-in - nobody forces you.
>
> It does, once person X submits a patch using github to KDERepoY he'll
complain
> if he can't for KDERepoZ.
>


Sounds like a bit superficial premature complain. If only we had a flood of
pull requests...

Arguing about ease of use is out of topic.

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

-- 
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] Official KDE mirror on github

[Jaroslaw Staniek]

On Saturday, 19 September 2015, Martin Graesslin  wrote:
> On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote:
>> From my experience, I was already mirroring KDE Connect in Github and
I've
>> received valuable patches there. That's a big enough reason for me to
want
>> Github's pull requests (and to spend 15 minutes learning how to use
them),
>> but I understand not everybody wants to learn a new and non-free tool.
>
> I'm subscribed to kde-connects review requests for reviewboard. How am I
as an
> interested developer able to follow the code review for github pull
requests
> if I don't want to use them?
>
> Basically by the decision to opt-in for pull requests you force the
complete
> team to follow them. Otherwise not-reviewed code gets in.

What I meant is that review is handled in a free tool. See I asked about
deprecating review board not once to have on tool for the task -phab, for a
reason.
Github is just like Gmail in this workflow, even less because in my book
you can't keep using it for regular contributions -this is a knowledge you
get after the first *motivating* success of approved patches.
Even at single subproject level fellow contributors don't see a downside,
only a chance for more patches.


>
> We really need to think in the big picture of what means this to KDE. We
> shouldn't go the "selfish" road and think of your own project. By allowing
> github pull-requests we are pushing out the contributors who don't want
to use
> it. You make it impossible for those contributors to comment on review
> requests, thus you have split the development.
>

See above, these are not the discussed bits.

> This is scary. Please don't think "selfish". Let people create the pull
> request and answer it with:
> "Sorry we do not support git hub pull request. To submit code please use
> reviewboard.kde.org. Here's how you do it..."


And can I do better than that 'slap in the face', I am free to do that.




>
> The point is we want to get to the people on github. That's why we mirror.
> It's not about getting pull requests. We want the people! They already
spent
> the effort to create the patch, they will spent the additional time to
get to
> reviewboard of phabricator in future. I have so often got patches on
bugzilla
> and it never was a problem to tell them "please use reviewboard for the
patch
> submission as the UI is more streamlined for code review". We always got
the
> patch into reviewboard. The aim of the people is not to use pull
requests, the
> aim is to submit their patch!
>

This is you talking to them in person. Quite better thing than automatic
closing.

> Cheers
> Martin
>

-- 
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] Official KDE mirror on github

[Martin Graesslin]

On Saturday, September 19, 2015 10:25:05 AM CEST Jaroslaw Staniek wrote:
> On Saturday, 19 September 2015, Shantanu Tushar Jha 
> 
> wrote:
> > On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin 
> 
> wrote:
> >> On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote:
> >> > From my experience, I was already mirroring KDE Connect in Github and
> 
> I've
> 
> >> > received valuable patches there. That's a big enough reason for me to
> 
> want
> 
> >> > Github's pull requests (and to spend 15 minutes learning how to use
> 
> them),
> 
> >> > but I understand not everybody wants to learn a new and non-free tool.
> >> 
> >> I'm subscribed to kde-connects review requests for reviewboard. How am I
> 
> as an
> 
> >> interested developer able to follow the code review for github pull
> 
> requests
> 
> >> if I don't want to use them?
> >> 
> >> Basically by the decision to opt-in for pull requests you force the
> 
> complete
> 
> >> team to follow them. Otherwise not-reviewed code gets in.
> >> 
> >> We really need to think in the big picture of what means this to KDE. We
> >> shouldn't go the "selfish" road and think of your own project. By
> 
> allowing
> 
> >> github pull-requests we are pushing out the contributors who don't want
> 
> to use
> 
> >> it. You make it impossible for those contributors to comment on review
> >> requests, thus you have split the development.
> >> 
> >> This is scary. Please don't think "selfish". Let people create the pull
> >> request and answer it with:
> >> "Sorry we do not support git hub pull request. To submit code please use
> >> reviewboard.kde.org. Here's how you do it..."
> >> 
> >> The point is we want to get to the people on github. That's why we
> 
> mirror.
> 
> >> It's not about getting pull requests. We want the people! They already
> 
> spent
> 
> >> the effort to create the patch, they will spent the additional time to
> 
> get to
> 
> >> reviewboard of phabricator in future. I have so often got patches on
> 
> bugzilla
> 
> >> and it never was a problem to tell them "please use reviewboard for the
> 
> patch
> 
> >> submission as the UI is more streamlined for code review". We always got
> 
> the
> 
> >> patch into reviewboard. The aim of the people is not to use pull
> 
> requests, the
> 
> >> aim is to submit their patch!
> > 
> > +1 to that. And adding to it, IMO the most important thing here is
> 
> consistency. The last thing we want to have is newcomers getting confused
> "erm, so for this KDE project do I use reviewboard? or do I create a pull
> request?".
> 
> 
> 
> But you just got confused by the claim from Martin, use of github reviews
> isn't proposed also because our repos are readonly there!
> Please read what I propose not strawmans...

I replied to Albert and Albert said he wants to do code-review through github 
(and already does so). So no it's not strawman. If we allow pull requests we 
move part of our code-review infrastructure to github. Period! If we allow 
github we exclude everyone in the sub project from reviewing patches who don't 
want to use 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] Official KDE mirror on github

[Sune Vuorela]

On 2015-09-19, Jaroslaw Staniek  wrote:
>
> Sounds like a bit superficial premature complain. If only we had a flood of
> pull requests...

It is not premature to complain!

I personally feel a bit fucked over right now. All this started with a
KDE github mirror and *just a mirror*. No pull requests. No bugtracker.
No nothing else. Just a mirror. And it was repeatedly said in the thread
that it would be just a mirror. Just a mirror.

The initial mirror sync isn't even done before people come out and say
"Can we enable this". "Can we enable that". Srsly.

I was fearing a slippery slope towards github development model, but we
are sliding faster than my nightmares.

When one is on a slippery slope, it is time to take a firm stand.

/Sune

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

Re: [kde-community] Official KDE mirror on github

[Boudewijn Rempt]

On Sat, 19 Sep 2015, Sune Vuorela wrote:


On 2015-09-19, Jaroslaw Staniek  wrote:


Sounds like a bit superficial premature complain. If only we had a flood of
pull requests...


It is not premature to complain!

I personally feel a bit fucked over right now. All this started with a
KDE github mirror and *just a mirror*. No pull requests. No bugtracker.
No nothing else. Just a mirror. And it was repeatedly said in the thread
that it would be just a mirror. Just a mirror.

The initial mirror sync isn't even done before people come out and say
"Can we enable this". "Can we enable that". Srsly.

I was fearing a slippery slope towards github development model, but we
are sliding faster than my nightmares.

When one is on a slippery slope, it is time to take a firm stand.


Amen to that.

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

Re: [kde-community] Official KDE mirror on github

[Ivan Čukić]

> All this started with a KDE github mirror and *just a mirror*.
> No pull requests. No bugtracker.

+100


Although I don't like the idea of what I'm about to say, here it goes.

If you want to have a project that has issue tracking and pull
requests on github - just create personal clone (just like a few
projects did before we created the kde mirror).

Officially (what we agreed on) is that github is just a mirror, not
another valid workflow for kde development.

Those personal repositories will not be considered a part of KDE
infrastructure, and nobody will complain that KFoo has github pull
support, and KBar does not.

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić  wrote:
> alternatives. Just as they do not have access to my personal inbox
>> where much corresponse often happens, and patches are discussed.
>
> Not sure that this is a statement you want to advertise, since it
> implies that the development happens behind the closed doors. (yes, we
> all do that sometimes, but is should not be a part of our workflow,
> and not something we should be proud of)
>
> Now, with GitHub, it would not be exactly 'development behind the
> closed doors' but for a lot of us it would be basically the same. As
> Martin mentioned, this would be hidden from his eyes since he has no
> intention to follow development on GitHub.

Some development does happen behind closed doors. Someone sends me a
patch, I commit it, and then point them towards reviewboard for the
next time. Ditto with bugs actually. I get reports via IRC, emails,
Google+ and even FB (once). If it is minor I act on it, if it isn't I
point the user towards bugzilla or just file a bug myself so that I
don't forget.

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

Re: [kde-community] Official KDE mirror on github

[Martin Steigerwald]

Am Samstag, 19. September 2015, 11:53:22 CEST schrieb Vishesh Handa:
> > So, if _you_ accept pull requests to a repo in the KDE official mirror,
> > you
> > are making decisions for others, and are making other people do things.
> 
> No I'm not.
> 
> Boud, you're shipping Krita on Windows. You're uploading them on the
> KDE official website, you're thereby making me pay for Windows if I
> want to test it and contribute to the project, you are making
> decisions for others.
> 
> Does this argument really hold?

I was not aware that I am forced to use the windows version of Krita. I just 
apt installed it and its just working fine.

Also it doesn´t lock in any development resources to a specific proprietary 
platform. At least I don´t see how it can do so.

So you can argue for github.com: But its opt-in and only for some repos? How 
do you make sure it doesn´t create pressure and expectancy that this will be 
switched on for all the other repos if pull requests are enabled in parts of 
the *official* KDE github.com mirror?

I do not see the Windows version of Krita creating any pressure for people to 
switch to Windows. I certainly do not feel any pressure to do so.

Thus I think its important to compare apples to apples and pears to pears.

Pull requests and probably bug reports on github.com affect the development 
process. Providing a Windows version of Krita does not, despite adding some 
portability to the codebase.

Thanks,
-- 
Martin
___
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] Official KDE mirror on github

[Boudewijn Rempt]

On Sat, 19 Sep 2015, Vishesh Handa wrote:


On Sat, Sep 19, 2015 at 11:13 AM, Boudewijn Rempt  wrote:

On Sat, 19 Sep 2015, Vishesh Handa wrote:


So if project X which is part of KDE also relies on GitHub, but in no
way recommends it, that will alienate people?



That's not the issue: the issue is having our official Github mirror
allowing a git-hub based workflow. That should not be possible.


Why?


In the very first place because that is what we agreed upon when setting
up this mirror. In the second place, because we need to show a consistent
face, as a community. In the third place, because by accepting pull requests,
you're putting a load on other people in the KDE community to do so as
well, whether or not they want to.




As
Ivan said, if a project maintainer is really set on selling their
soul, then by all means use a private, personal, not-officially-KDE
github thing.


* There is nothing to do with selling your soul.


If _you_ want to use an official KDE thing to promote the use of non-free
software, you're not just "selling your own soul", you're compromising
KDE's message. And so handling github pull requests to KDE's official
mirror's repos instead of telling people to use the proper channels is
breaking up the consistent message we want to convey, and it puts a load
on other people, who don't want to handle those pull requests: they now
have to explain why they are grumpy bastarts who don't do what nice-guy-you
does do.

So, if _you_ accept pull requests to a repo in the KDE official mirror, 
you are making decisions for others, and are making other people do things.



Each of us has
different goals, and we lie on different edges of the spectrum w.r.t
Free software. We need all kinds of people.


That's fine, but don't use KDE's external interface to confuse the issue.
We tell the world, this our workflow, this is what we support, this is
why. Don't compromise that message because you want to be a nice, helpful
fellow.

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

Re: [kde-community] Official KDE mirror on github

[Luigi Toscano]

Il 19 settembre 2015 12:00:11 CEST, Vishesh Handa  ha scritto:
> On Sat, Sep 19, 2015 at 11:44 AM, Luca Beltrame 
> wrote:
> >
> > And besides... hasn't the BitKeeper story taught us *anything*?
> >
> 
> I don't know about you guys, but it has taught me that we can be
> pragmatic and use proprietary software when the need arises.


There is a big FLOSS project I spend my daily work for, called OpenStack. Given 
its target, contributions comre from companies and certainly normal users are 
not too interested about it and even more about how it is developed. Despite 
this, it has a strong manifesto with interesting values:
https://wiki.openstack.org/wiki/Open

and that extends to the infrastructure too. Leaving aside the usage of 
launchpad for bugs (there is a replacement which is advanced state of 
development), guess what? Infra team has an own git, contributions go to the 
internal gerrit. Github is just a mirror and I didn't hear anyone screaming or 
complaining about loss of contributions.

Now, if they can do that, why can't we do it?

Ciao

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 1:04 PM, Martin Steigerwald  wrote:
>> > So, if _you_ accept pull requests to a repo in the KDE official mirror,
>> > you
>> > are making decisions for others, and are making other people do things.
>>
>> No I'm not.
>>
>> Boud, you're shipping Krita on Windows. You're uploading them on the
>> KDE official website, you're thereby making me pay for Windows if I
>> want to test it and contribute to the project, you are making
>> decisions for others.
>>
>> Does this argument really hold?
>
> I was not aware that I am forced to use the windows version of Krita. I just
> apt installed it and its just working fine.
>

I don't follow. In this case of Krita if you wanted to contribute to
the project as a tester or provide some kind of QA, you would need to
use Windows. How does that relate to installing Krita?

> Also it doesn´t lock in any development resources to a specific proprietary
> platform. At least I don´t see how it can do so.

Testing is part of development. If you're offering Krita on Windows,
someone is testing it, creating the binaries, etc.

>
> So you can argue for github.com: But its opt-in and only for some repos? How
> do you make sure it doesn´t create pressure and expectancy that this will be
> switched on for all the other repos if pull requests are enabled in parts of
> the *official* KDE github.com mirror?
>
> I do not see the Windows version of Krita creating any pressure for people to
> switch to Windows. I certainly do not feel any pressure to do so.
>

How do you then feel pressured to use Github if most development happens on kde?

> Thus I think its important to compare apples to apples and pears to pears.
>
> Pull requests and probably bug reports on github.com affect the development
> process. Providing a Windows version of Krita does not, despite adding some
> portability to the codebase.

Testing and QA are important parts of creating a product. They most
certainly are part of the "development process". Providing a Windows
version of Krita does force me to install these tools if I wish to
contribute to that part of Krita.

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

Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)

[David Edmundson]

> >
> > I was under the impression they were disabled by the options we had
> > selected. Unfortunately that is not the case.
>
> Thanks for clarifying on this.
>
> I hope they can still be disabled.
>
> They can't. I had spent some time looking before. Sorry.

However, we have solid hard data that it's a non-issue.

Gnome has been mirrored on github for nearly 2 years, in that time GTK has
had a grand total of 4 pull requests over time.
Most others (gedit, cheese, epiphany) have had 0.

Interestingly they have had literally hundreds of github "forks", which
implies it has led to sustantiable numbers of patches back using the
traditional methods

I've made a wiki page, which says how to turn a pull request into a
reviewboard submission.
https://techbase.kde.org/Development/GithubMirror

If we get any questions we can then just copy and paste that, and don't
need to spend any time explaining. Bam, done.

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

Re: [kde-community] Official KDE mirror on github

[Martin Steigerwald]

Am Samstag, 19. September 2015, 02:22:44 CEST schrieb Riccardo Iaconelli:
> On Friday, September 18, 2015 11:43:34 PM Vishesh Handa wrote:
> > It depends on our end goal: creating free software or creating free
> > software with only free tools? If it is the latter then I fear we have
> > already failed since many of us use additional tools to aid
> > development which are not free.
> 
> I couldn't say it better!
> 
> Bitkeeper was not free, when support ended, git was made! Some video drivers
> were not free, but we continued to use them, until better alternatives
> emerged. Sourceforge was not free, yet many KDE projects used it.
> 
> ...heck, even Qt was not free, back in the days!
> 
> I wouldn't rely entirely on a non-free platform, but I wouldn't miss the
> opportunity to market projects who wish so to a larger developer base. It is
> important for our coummunity to share and communicate our open values, and
> that usually means with people who are not yet convinced. :-)

Right now the larger developer base is just an hypothesis, or are there any 
numbers on that? (I am aware that numbers on that would require that one KDE 
project already uses pull requests github.com.)

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 5:23 AM, Michael Pyne  wrote:
> The end result of that type of thought is something like what happened with
> BitKeeper.
>
> I'm not going to say it's impossible to use proprietary tools without having
> that type of drama occur, but I think it would be better if we just skipped to
> the part where we end up preferring a Free/open alternative to handle our
> critical tasks (as also happened with BitKeeper -> git).

I don't think it is just about the technology. It is also about the
visibility of that platform. GitHub is more visible, is used by more
developers, and its workflows are more well known those developers.
It's simple about harnesses an additional platform to help improve our
software. Please note that I'm not advocating for dropping our own
infrastructure.

>
> Besides which, it actually is *already* a general principle of KDE projects.
> There was no point going through all the work and community debate about what
> it should mean to be a "KDE project" if we were just going to walk away from
> those points when something more attractive came along.
>
> It should not be surprising that KDE developers advocate for something more
> than sheer pragmatism; if we were *only* pragmatic we could just recommend
> that people use Windows or Mac, no?
>

That's a strawman argument. I'm not advocating that we recommend
GitHub or other proprietary platforms.

Also, we do ship Mac and Windows binaries along with Linux binaries.
Also, would you not be willing to receive bug reports from users of
your software on those platforms?

> There is at least value in consistency. It would confuse our users if they
> could report bugs one way with KFoo (utilizing support from Github) but
> couldn't report bugs the same way with KBar. It would impact our developers:
> remember that part of the ethos of being a "KDE project" is that the code is
> notionally open to *all* KDE developers. Are we supposed to canvass for bugs
> on both b.k.o and Github for some (but not all) "official" KDE repositories in
> the future? I agree it could be more convenient for an individual KDE app
> developer to allow this feature, but they are not the only stakeholder when
> discussing applications that form part of a "kde.org" release.

Lets break this down -

* Consistency - It is still maintained, but there can be additional
sources as an exception. Just as some people could just directly email
you a patch. (It has certainly happened to me)

* Reporting Bugs in 2 places - The default place should still
bugs.kde.org for now.

* Code open to all developers - How is this changing?


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

Re: [kde-community] Renaming KScreenGenie

[rajeev bhatta]

I personally agree with Luigi that the name should not be a generic name, 
specifically to not get multiple confusing results in search engines.


Like the name selfie..but it will be nightmare finding the app in google if 
looking for selfie


Thanks

Sent from Yahoo Mail on Android

From:"Luigi Toscano" 
Date:Sat, Sep 19, 2015 at 2:47 AM
Subject:Re: [kde-community] Renaming KScreenGenie

Eike Hein ha scritto:
> 
> 
> On 09/01/2015 10:08 PM, Boudhayan Gupta wrote:
>> Ladies and gentlemen, I'll take a decision on this in the next couple
>> of days. As it stands now, Pixie is a universal favourite but we can't
>> use it for copyright reasons.
>>
>> Kapture seems to have the most number of votes, so if nothing changes
>> I'll go with that.
> 
> 
> I'd like to object to using Kapture for a number of reasons
> ... apologies for getting involved at this late hour, I was
> on vacation for most of this thread :)
> [..]
> 
> 
> Personally I'm a big fan of the "Selfie" suggestion:
> [...]

Can't we really find something that
- doesn't have a "k"
- is not a generic name?

Generic names are bad for many reasons (including, but not only, when you look
for information about the program on any search engine).

That said, I'm not stopping the renaming (even if I dislike Selfie), I'm not
anyone here. I suspect someone else will poke again in two weeks and ask again
why it was renamed this way, though.

Ciao
-- 
Luigi



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

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

Re: [kde-community] Official KDE mirror on github

[Martin Steigerwald]

Am Samstag, 19. September 2015, 11:20:32 CEST schrieb Vishesh Handa:
> * Reporting Bugs in 2 places - The default place should still
> bugs.kde.org for now.

For bug triaging KDEPIM I will ignore anything but the official KDE 
infrastructure.

I know bugzilla is not the most friendly to use bug tracker around, but I 
start getting on terms with it and I certainly to not want to look in more 
than one place for bug reports.

Having a second infrastructure beneath the official one will split energy.

So for the work I currently do I vote for having only *one* officially 
endorsed infrastructure. And for anything that is an exception I suggest to 
treat it as such: Create your personal clone on github.com. So if its, as you 
also wrote is not officially endorsed, I think it any exception shall stay 
outside of the officially endorsed infrastructure and as such the officially 
github.com presence of the KDE project would just be a mirror. Otherwise if 
you allow it for some KDE projects within the official KDE github.com 
presence, how is this different from an official endorsement?

(And I write this even tough at my employer we do use github.com.)

Thank yo,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

[Martin Steigerwald]

Am Samstag, 19. September 2015, 11:53:22 CEST schrieb Vishesh Handa:
> > If _you_ want to use an official KDE thing to promote the use of non-free
> > software, you're not just "selling your own soul", you're compromising
> > KDE's message.
> 
> I'm not promoting its usage. I'm advocating for utilizing its
> resources in addition to our own. Just as we utilize other proprietary
> platforms (windows, and mac) to improve KDE. No one is advocating
> GitHub.

How is "I'm advocating for utilizing its resources in addition to our own" not 
advocating GitHub?

My logical thought process does not get that.

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

Re: [kde-community] Official KDE mirror on github

[Martin Steigerwald]

Am Samstag, 19. September 2015, 13:09:31 CEST schrieb Vishesh Handa:
> On Sat, Sep 19, 2015 at 1:04 PM, Martin Steigerwald  
wrote:
[…]
> > So you can argue for github.com: But its opt-in and only for some repos?
> > How do you make sure it doesn´t create pressure and expectancy that this
> > will be switched on for all the other repos if pull requests are enabled
> > in parts of the *official* KDE github.com mirror?
> > 
> > I do not see the Windows version of Krita creating any pressure for people
> > to switch to Windows. I certainly do not feel any pressure to do so.
> 
> How do you then feel pressured to use Github if most development happens on
> kde?

For bug triaging I answer: People report issues for the project I am helping 
to bug triage in. And while I certainly can ignore those, it creates bad 
reputation for the project, if no one else tends to the bug reports.

I think similar it goes for pull requests.

> > Thus I think its important to compare apples to apples and pears to pears.
> > 
> > Pull requests and probably bug reports on github.com affect the
> > development
> > process. Providing a Windows version of Krita does not, despite adding
> > some
> > portability to the codebase.
> 
> Testing and QA are important parts of creating a product. They most
> certainly are part of the "development process". Providing a Windows
> version of Krita does force me to install these tools if I wish to
> contribute to that part of Krita.

Vishesh, please: If you *wish* to contribute to that part of Krita, how can 
you be *forced* to use Windows?

If you are not interesting in the Windows version, you just ignore it.

I see only one kind of pressure that comes from a Windows version of Krita and 
that is some pressure to provide for portability. From a development point of 
view I see this as an advantage. It can even prevent platform lock-in.

Well okay, I know get your argument: If a user reports a bug on Windows, one 
can feel pressured to do something about it. Similar like with an issue 
provided on github.com. That said, I likely won´t feel pressured. Cause if 
there is a Windows team for Krita, I expect this team to handle Windows 
specific bug reports and likely would ignore them otherwise.

But still… there is *some* comparability. Yet, I still providing a Windows 
version of Krita is not the same as (partly) allowing pull requests on 
Github.com. I do  not have words for it at the moment, but I feel lot more 
reluctance about the latter than the former.

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

Re: [kde-community] Official KDE mirror on github

[Marco Martin]

On Friday 18 September 2015 23:28:37 Vishesh Handa wrote:
> In general, I'm quite alarmed by how people are advocating their
> principles for ALL kde projects without any scope for negotiations for
> different projects. I fear that this will just drive people/projects
> away from KDE.

from this thread, seems to me that strarting to rely on github will drive 
people away from KDE too, for sure several participants of this thread

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 9:46 AM, Shantanu Tushar Jha  wrote:
> +1 to that. And adding to it, IMO the most important thing here is
> consistency. The last thing we want to have is newcomers getting confused
> "erm, so for this KDE project do I use reviewboard? or do I create a pull
> request?".

That clearly isn't what I'm advocating. All guides should point
towards reviewboard. Baloo [1] clearly says all contributions should
go reviewboard. That is the consistency. However, if someone creates a
pull request, I'm willing to take the time to merge it, and not just
tell the person - here use this strange tool where you will need to
spend 10-15 extra minutes.

--
Vishesh Handa

[1] https://github.com/KDE/baloo
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

[Boudewijn Rempt]

On Sat, 19 Sep 2015, Vishesh Handa wrote:


So if project X which is part of KDE also relies on GitHub, but in no
way recommends it, that will alienate people?


That's not the issue: the issue is having our official Github mirror 
allowing a git-hub based workflow. That should not be possible. As

Ivan said, if a project maintainer is really set on selling their
soul, then by all means use a private, personal, not-officially-KDE
github thing.

But the KDE message should be totally clear: this is just a mirror.
It's not the KDE workflow, because KDE is about freedom, not 
convenience.


Just like, for instance, https://github.com/GNOME/gimp/pulls...

Boudewijn


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

Re: [kde-community] Official KDE mirror on github

[Bhushan Shah]

On Sat, Sep 19, 2015 at 2:06 PM, Sune Vuorela  wrote:
> I personally feel a bit fucked over right now. All this started with a
> KDE github mirror and *just a mirror*. No pull requests. No bugtracker.
> No nothing else. Just a mirror. And it was repeatedly said in the thread
> that it would be just a mirror. Just a mirror.

And when we say mirror and if we start to accept pull request there it
will also complicate the sysadmin work if I know correctly

How would git.kde.org will stay up-to-date if you merged pull request
on github? This is one of the reason currently sysadmin allows pushes
on just git.kde.org and not on anongit.kde.org

When we say mirror its just mirror and just supposed to replicate our
git repository.

-- 
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] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 11:44 AM, Luca Beltrame  wrote:
> Il Sat, 19 Sep 2015 11:30:39 +0200, Vishesh Handa ha scritto:
>
>
>> * There is nothing to do with selling your soul. Each of us has
>
> We have a Manifesto, and we should, ideally, strive to respect it.

The manifesto is not set in stone. Everything evolves.

>
>> * We're using Coverify - a non free tool * We're shipping binaries for
>> Windows and Mac - non-free platforms.
>
> We're not *depending on it* nor it is important for contributions. We
> could live without it.
>

Nor would we be depending on GitHub. We would still have our own
infrastructure, which we would be recommending.

>> We have to draw the line somewhere.
>
> Not enough into making our own code, which is the heart of our software,
> dependent on proprietary tools.

Again, not dependent. I'm not advocating throwing away our
infrastructure and moving to GitHub.

>
> Of all your examples, you omitted the only shameful one for KDE;
> opendesktop. And in that case, a lot of people do *not* like it.

Urgh. OpenDesktop is just sad. It's strange we take issues with a
proprietary extension to our infrastructure, which would be used in
limited and case-by-case basis, when we use OpenDesktop so blatantly
and for so many years.

>
> And besides... hasn't the BitKeeper story taught us *anything*?
>

I don't know about you guys, but it has taught me that we can be
pragmatic and use proprietary software when the need arises.

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 12:17 PM, Laszlo Papp  wrote:
>> No I'm not.
>>
>> Boud, you're shipping Krita on Windows. You're uploading them on the
>> KDE official website, you're thereby making me pay for Windows if I
>> want to test it and contribute to the project, you are making
>> decisions for others.
>>
>> Does this argument really hold?
>
> I must admit that you have a valid point in there with Windows being a
> bit different.
>
> On the other hand, Windows plays a significant role in the world for end 
> users.
>

For frameworks, then end users are developers. Github plays a
significant role in that world.

> Is github really comparable to it? My humble guess would be that
> github is less prevalent for our end users. Even for development, it
> does not seem to be crucial at this point in time, at least, I
> believe. I really hope that it will remain this way and KDE can be a
> good factor to challenge things with github with open alternatives.

And we should continue challenging them, however, just like we still
ship binaries on Windows. I would argue that we need a presence on
GitHub as well.

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 12:57 PM, Martin Steigerwald
 wrote:
> How is "I'm advocating for utilizing its resources in addition to our own" not
> advocating GitHub?
>
> My logical thought process does not get that


Sorry. Perhaps the wording was not correct.

I'm not advocating abandoning our own infrastructure or telling
contributors to use GitHub. Our documentation should always point
towards our own tools.

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

Re: [kde-community] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 3:33 PM, Boudhayan Gupta  wrote:
> Hi all,
>
> This discussion is becoming nothing but a royal waste of time.
>
> Let me summarise:
>
> 1. We generally agreed before starting that this was going to be a
> read-only mirror.
>
> 2. For consistency's sake, we cannot enable issues/pull requests for
> only some repos and disable for others.
>

We can. We might choose not to do so, but it is possible.

Please note that consistency isn't a requirement to be part of KDE. If
I decide to write an application in Rust, which is only for Windows,
and uses a completely different build system, that is allowed.

> Now here's what I think from a common sense perspective:
>
> 1. Due to point 3, we cannot in any way rely on GitHub being up or
> available at all.
>
> 2. Due to points 1 and 2, we cannot in any way enable pull requests on
> the GitHub mirrors.

Again we can. Since (2) does not hold true, this point is invalid.

>
> 3. Regarding point 4, if developers already have personal GitHub
> clones that they use for their own purposes, nothing is stopping them
> from continuing to use them. Those clones are not endorsed by KDE,
> they are under complete control of the individual
> developers/maintainers, they are entirely the responsibility of the
> developers/maintainers, and the developers/maintainers are free to do
> with them as they see fit.
>

Because maintainers are not responsible for their own projects anyway?
If I'm taking responsibility for a project, I'm also taking
responsibility for other parts of it. In this case Github. No one is
forcing anyone.

>
> 4. As for 5 & 6, "better" is a matter of personal taste. We *are*
> moving to Phabricator eventually, which should make things better and
> more GitHub-like for others (although you will need a KDE Identity).
>
> Here's what developers and maintainers should really do: forget that
> github.com/kde exists.

They can do that if they are comfortable with the status-quo. Some
people are clearly not. Your email disregards the points raised and
implies that the github readonly mirror is only what is acceptable.
That result is clearly not shared by everyone.


> For all practical purposes, it does not exist.
> It isn't there. It should never be a part of your workflow. You should
> never ever look at it. It is simply an additional clone source, just
> like KDE's anongit servers. That's it.

This is the part of your email I really like. Though this is not what
you meant: If projectX choose to also use Github, it is not affecting
your project in anyway. Just ignore it and move on.

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

Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)

[Teo Mrnjavac]

On Saturday, September 19, 2015 13:04:55 David Edmundson wrote:
> > > I was under the impression they were disabled by the options we had
> > > selected. Unfortunately that is not the case.
> > 
> > Thanks for clarifying on this.
> > 
> > I hope they can still be disabled.
> > 
> > They can't. I had spent some time looking before. Sorry.
> 
> However, we have solid hard data that it's a non-issue.
> 
> Gnome has been mirrored on github for nearly 2 years, in that time GTK has
> had a grand total of 4 pull requests over time.
> Most others (gedit, cheese, epiphany) have had 0.
> 
> Interestingly they have had literally hundreds of github "forks", which
> implies it has led to sustantiable numbers of patches back using the
> traditional methods
> 
> I've made a wiki page, which says how to turn a pull request into a
> reviewboard submission.
> https://techbase.kde.org/Development/GithubMirror
> 
> If we get any questions we can then just copy and paste that, and don't
> need to spend any time explaining. Bam, done.
> 

Thank you David, for your get-things-done approach in this controversial and 
tense situation. It is really much easier to solve than it seems from all 
these threads.

I'm personally in favor of letting projects decide whether to allow GitHub 
pull requests or not, but regardless of the final decision it is good to 
already have practical solutions like this techbase entry.

I find it unfortunate that some long time KDE contributors feel that KDE goals 
are threatened by all this. I understand their concerns, but I assign those 
concerns a different priority score. In fact, the inflexible policy towards 
3rd party (including proprietary) infrastructure and processes we have in KDE 
deters me from bringing some of my own (currently GitHub-hosted) work under 
the KDE umbrella, as this would hinder some very productive working 
relationships with our downstreams and potentially result in *less* free open 
source software being produced, deployed and used.

It is also a fact that KDE is an aging community, and in its future I expect a 
slow decline unless we find a way to bring in a steady influx of new 
contributors. Recruiting a new generation of hackers is something that's just 
not happening fast enough at this point (our yearly GSoC stats are an 
indication of that). GitHub could be a very powerful instrument in turning 
this trend around by tapping into a huge talent pool and pushing people 
towards our own infrastructure while still allowing them to get started 
through an environment they already know.

Cheers,
-- 
Teo Mrnjavac
http://teom.org | t...@kde.org
___
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] Official KDE mirror on github

[Kevin Krammer]

On Saturday, 2015-09-19, 16:26:04, Luigi Toscano wrote:
> Kevin Krammer ha scritto:
> > On Saturday, 2015-09-19, 12:29:31, Vishesh Handa wrote:
> >> On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić  wrote:
> >>> alternatives. Just as they do not have access to my personal inbox
> >>> 
>  where much corresponse often happens, and patches are discussed.
> >>> 
> >>> Not sure that this is a statement you want to advertise, since it
> >>> implies that the development happens behind the closed doors. (yes, we
> >>> all do that sometimes, but is should not be a part of our workflow,
> >>> and not something we should be proud of)
> >>> 
> >>> Now, with GitHub, it would not be exactly 'development behind the
> >>> closed doors' but for a lot of us it would be basically the same. As
> >>> Martin mentioned, this would be hidden from his eyes since he has no
> >>> intention to follow development on GitHub.
> >> 
> >> Some development does happen behind closed doors. Someone sends me a
> >> patch, I commit it, and then point them towards reviewboard for the
> >> next time. Ditto with bugs actually. I get reports via IRC, emails,
> >> Google+ and even FB (once). If it is minor I act on it, if it isn't I
> >> point the user towards bugzilla or just file a bug myself so that I
> >> don't forget.
> > 
> > Right, this is also my understanding of what is proposed.
> > 
> > If you work on a project where you can push without review, it really
> > doesn't matter how you arrived at the commit, you would have pushed your
> > own version without review as well.
> > 
> > If you work on a project where you have to go through review, then again,
> > it really doesn't matter how the commit has been created, it is still
> > being reviewed.
> > The only difference is that the submitter of the review request is not the
> > author of the commit.
> 
> But that's not using the pull request. Such workflow would mean that the
> pull request is not accepted anyway, but the code is pushed through the
> infrastructure and not trough Github interface.

I though that a pull request was a way for one clone's owner to notify the 
main repo owner that the clone had a change they would like to propose for 
upstream.

The repo owner could then pull the clone at the given revision and then follow 
whatever workflow they would like to follow.

In a KDE project with mandatory review that would be uploading the change to 
reviewboard/gerrit/phabricator.

In a KDE project without mandatory review that could be uploading to KDE's 
review or pushing to the KDE git server.

> Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please
> explain exactly what is the meaning of "use Github"? Do we all agree that in
> any way pull requests will never be merged directly through Github
> interface?

What sense would that even make?
Then the mirror would have a different state than the repo it is mirroring.

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: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] Have repo maintainers opt-in for github mirroring

[Teo Mrnjavac]

On Saturday, September 19, 2015 16:25:13 Luigi Toscano wrote:
> Teo Mrnjavac ha scritto:
> > It is also a fact that KDE is an aging community, and in its future I
> > expect a slow decline unless we find a way to bring in a steady influx of
> > new contributors. Recruiting a new generation of hackers is something
> > that's just not happening fast enough at this point (our yearly GSoC
> > stats are an indication of that). GitHub could be a very powerful
> > instrument in turning this trend around by tapping into a huge talent
> > pool and pushing people towards our own infrastructure while still
> > allowing them to get started through an environment they already know.
> 
> I disagree on this point. Other non-aging projects are staying successfully
> away from Github.
> 

KDE can indeed be a non-aging project without GitHub, I never meant to imply 
otherwise. This is not an all or nothing situation. I'm in favor of improving 
recruiting through other channels as well.

But I believe a GitHub mirror with the option of pull requests can contribute 
to growth, and I'm in favor of using it for this reason.

-- 
Teo Mrnjavac
http://teom.org | t...@kde.org
___
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] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 4:37 PM, Boudhayan Gupta  wrote:
> On 19 September 2015 at 19:34, Vishesh Handa  wrote:
>> Please note that consistency isn't a requirement to be part of KDE. If
>> I decide to write an application in Rust, which is only for Windows,
>> and uses a completely different build system, that is allowed.
>
> How are these two things even remotely similar? Of course you're
> allowed to write a Windows specific app in Rust. Hell, according to
> the manifesto we should be able to write apps for the Commodore64 if
> we want to, provided that the software complies with licensing and
> community engagement requirements of the KDE community. On a more
> realistic note, almost all KDE apps have their own coding style, and
> every maintainer has their own standard on how far to stick to these
> styles.
>
> It is important to note that we're talking about infrastructural
> consistency here, not code consistency. There is a distinction. 
>

My point over here was to illustrate that there are many parts to
building a project, the code, development, handling contributions,
handling bugs, infrastructure, etc. None of these *have* to be
consistent. The manifesto does not actually dictate terms of
"infrastructure".

Relevant part - "Online services associated with the project are
either hosted on KDE infrastructure or have an action plan that
ensures continuity which is approved by the KDE system administration
team"


>>>
>>> 3. Regarding point 4, if developers already have personal GitHub
>>> clones that they use for their own purposes, nothing is stopping them
>>> from continuing to use them. Those clones are not endorsed by KDE,
>>> they are under complete control of the individual
>>> developers/maintainers, they are entirely the responsibility of the
>>> developers/maintainers, and the developers/maintainers are free to do
>>> with them as they see fit.
>>>
>>
>> Because maintainers are not responsible for their own projects anyway?
>> If I'm taking responsibility for a project, I'm also taking
>> responsibility for other parts of it. In this case Github. No one is
>> forcing anyone.
>>
>
> Common ownership. There's a difference between any random open source
> project on GitHub/SF.net/elsewhere and a KDE project. Maintainers are
> responsible for their own projects (that's why they're maintainers).
> They're also responsible for playing nice with the rest of the
> community and abiding by the requirements of the rest of the
> community.

And how does also accepting github requests not play nice with the
rest of the community?

> Also, while the rest of KDE may not have a say in the code
> of the project (the maintainer is the maintainer because he/she
> understands the code to a higher degree than the rest of the people
> here), they do have a say in the project's governance.
>

"governance" is quite a vague word over here.

Release cycles, documentation, QA, online infrastructure? what exactly?

>>> Here's what developers and maintainers should really do: forget that
>>> github.com/kde exists.
>>
>> They can do that if they are comfortable with the status-quo. Some
>> people are clearly not. Your email disregards the points raised and
>> implies that the github readonly mirror is only what is acceptable.
>> That result is clearly not shared by everyone.
>
> This comment disregards the entire e-mail which is about why the
> read-only mirror should be acceptable. Again, why it should be
> acceptable is because it's as important to the KDE infrastructure as
> an anongit server.
>

I think we're talking about different things. The read-only mirror is
done, and shipped. I was talking about projects being able to also use
github, and the rest of the community respecting that decision.
___
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] Official KDE mirror on github

[Eike Hein]

On 09/19/2015 11:35 AM, Vishesh Handa wrote:
> Then we will deal with them on a case-by-case basis. Lets not take
> blanket bans on new ideas just because of their potential destructive
> power. Each action of ours has positive and negative benefits. How
> about we focus on the positive?

You're ignoring the position that says "the long-term
negatives outweigh the short-term positives on this",
though.


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

Re: [kde-community] Official KDE mirror on github

[Boudhayan Gupta]

Hi all,

This discussion is becoming nothing but a royal waste of time.

Let me summarise:

1. We generally agreed before starting that this was going to be a
read-only mirror.

2. For consistency's sake, we cannot enable issues/pull requests for
only some repos and disable for others.

3. Basing our workflow around GitHub is a complete no-no, because
they're a commercial entity who can lock us out of our data at will.

4. Some developers and maintainers have said that they need an
expanded presence on GitHub and have been using personal GitHub clones
of their KDE repos for their own needs (BountySource, etc).

5. Some developers think our existing infrastructure is broken and
that GitHub is better.

6. Some developers think that GitHub is broken and ours is better.

Now here's what I think from a common sense perspective:

1. Due to point 3, we cannot in any way rely on GitHub being up or
available at all.

2. Due to points 1 and 2, we cannot in any way enable pull requests on
the GitHub mirrors.

3. Regarding point 4, if developers already have personal GitHub
clones that they use for their own purposes, nothing is stopping them
from continuing to use them. Those clones are not endorsed by KDE,
they are under complete control of the individual
developers/maintainers, they are entirely the responsibility of the
developers/maintainers, and the developers/maintainers are free to do
with them as they see fit.

4. As for 5 & 6, "better" is a matter of personal taste. We *are*
moving to Phabricator eventually, which should make things better and
more GitHub-like for others (although you will need a KDE Identity).

Here's what developers and maintainers should really do: forget that
github.com/kde exists. For all practical purposes, it does not exist.
It isn't there. It should never be a part of your workflow. You should
never ever look at it. It is simply an additional clone source, just
like KDE's anongit servers. That's it. If you want a presence on
GitHub, use your personal accounts, and don't imply in any way that
your personal clone is "official" and related to KDE's infrastructure
in any way.

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

Re: [kde-community] Official KDE mirror on github

[Luigi Toscano]

Kevin Krammer ha scritto:
> On Saturday, 2015-09-19, 12:29:31, Vishesh Handa wrote:
>> On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić  wrote:
>>> alternatives. Just as they do not have access to my personal inbox
>>>
 where much corresponse often happens, and patches are discussed.
>>>
>>> Not sure that this is a statement you want to advertise, since it
>>> implies that the development happens behind the closed doors. (yes, we
>>> all do that sometimes, but is should not be a part of our workflow,
>>> and not something we should be proud of)
>>>
>>> Now, with GitHub, it would not be exactly 'development behind the
>>> closed doors' but for a lot of us it would be basically the same. As
>>> Martin mentioned, this would be hidden from his eyes since he has no
>>> intention to follow development on GitHub.
>>
>> Some development does happen behind closed doors. Someone sends me a
>> patch, I commit it, and then point them towards reviewboard for the
>> next time. Ditto with bugs actually. I get reports via IRC, emails,
>> Google+ and even FB (once). If it is minor I act on it, if it isn't I
>> point the user towards bugzilla or just file a bug myself so that I
>> don't forget.
> 
> Right, this is also my understanding of what is proposed.
> 
> If you work on a project where you can push without review, it really doesn't 
> matter how you arrived at the commit, you would have pushed your own version 
> without review as well.
> 
> If you work on a project where you have to go through review, then again, it 
> really doesn't matter how the commit has been created, it is still being 
> reviewed.
> The only difference is that the submitter of the review request is not the 
> author of the commit.

But that's not using the pull request. Such workflow would mean that the pull
request is not accepted anyway, but the code is pushed through the
infrastructure and not trough Github interface.

Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please
explain exactly what is the meaning of "use Github"? Do we all agree that in
any way pull requests will never be merged directly through Github interface?

I still think that an automated bot should invite people in pull requests to
submit proper reviews, but it's important to clarify this point.

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

Re: [kde-community] Official KDE mirror on github

[Shantanu Tushar Jha]

Its sad that this got completely ignored by the members of this discussion,
the argument is very valid.

On Sat, Sep 19, 2015 at 3:47 PM, Luigi Toscano 
wrote:

> Il 19 settembre 2015 12:00:11 CEST, Vishesh Handa  ha
> scritto:
> > On Sat, Sep 19, 2015 at 11:44 AM, Luca Beltrame 
> > wrote:
> > >
> > > And besides... hasn't the BitKeeper story taught us *anything*?
> > >
> >
> > I don't know about you guys, but it has taught me that we can be
> > pragmatic and use proprietary software when the need arises.
>
>
> There is a big FLOSS project I spend my daily work for, called OpenStack.
> Given its target, contributions comre from companies and certainly normal
> users are not too interested about it and even more about how it is
> developed. Despite this, it has a strong manifesto with interesting values:
> https://wiki.openstack.org/wiki/Open
>
> and that extends to the infrastructure too. Leaving aside the usage of
> launchpad for bugs (there is a replacement which is advanced state of
> development), guess what? Infra team has an own git, contributions go to
> the internal gerrit. Github is just a mirror and I didn't hear anyone
> screaming or complaining about loss of contributions.
>
> Now, if they can do that, why can't we do it?
>
> Ciao
>
> --
> Luigi
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>



-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
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

[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] Official KDE mirror on github

[Loïc Grobol]

Just leaving that here, though borderline off-topic and I am not
really qualified,

If the issue is the (granted, a bit outdated)
Bugzilla/Reviewboard/Quickgit toolset not being user-friendly enough,
why not have a look at the libre github clone GitLab instead? That
could be hosted on KDE servers and provide the same services as
GitHub.

L

On 19 September 2015 at 13:55, Vishesh Handa  wrote:
> On Sat, Sep 19, 2015 at 1:24 PM, Martin Steigerwald  
> wrote:
>>> Testing and QA are important parts of creating a product. They most
>>> certainly are part of the "development process". Providing a Windows
>>> version of Krita does force me to install these tools if I wish to
>>> contribute to that part of Krita.
>>
>> Vishesh, please: If you *wish* to contribute to that part of Krita, how can
>> you be *forced* to use Windows?
>>
>> If you are not interesting in the Windows version, you just ignore it.
>>
>
> Lets use the analogy of KRita and Windows Binaries being one part of
> it. Your statement implies that if I'm not interested in Windows, I
> can ignore that part of Krita. (Even though statistically Windows has
> a greater market share than Linux + OSX combined)
>
> Similarly, ProjectX in one part of KDE. If you're not interested in
> contributing to a project which also supports a proprietary platform
> (but does not recommend it), then you can ignore it.
>
>> I see only one kind of pressure that comes from a Windows version of Krita 
>> and
>> that is some pressure to provide for portability. From a development point of
>> view I see this as an advantage. It can even prevent platform lock-in.
>>
>> Well okay, I know get your argument: If a user reports a bug on Windows, one
>> can feel pressured to do something about it. Similar like with an issue
>> provided on github.com. That said, I likely won´t feel pressured. Cause if
>> there is a Windows team for Krita, I expect this team to handle Windows
>> specific bug reports and likely would ignore them otherwise.
>>
>
> And the maintainer of ProjectX would be part of this *github* team and
> you can expect them to handle those specific bug reports / pull
> requests.
>
> For Baloo, I've explicitly disabled it for Windows and OSX. I have the
> ability to chose my platforms as a KDE project. Similarly, the
> argument can be made that Github can be just another platform which
> projects can choose to be part of.
>
>> But still… there is *some* comparability. Yet, I still providing a Windows
>> version of Krita is not the same as (partly) allowing pull requests on
>> Github.com. I do  not have words for it at the moment, but I feel lot more
>> reluctance about the latter than the former.
>
>
>
> --
> Vishesh Handa
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community



-- 
Loïc Grobol.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)

[Albert Astals Cid]

El Dissabte, 19 de setembre de 2015, a les 16:23:26, Teo Mrnjavac va escriure:
> On Saturday, September 19, 2015 13:04:55 David Edmundson wrote:
> > > > I was under the impression they were disabled by the options we had
> > > > selected. Unfortunately that is not the case.
> > > 
> > > Thanks for clarifying on this.
> > > 
> > > I hope they can still be disabled.
> > > 
> > > They can't. I had spent some time looking before. Sorry.
> > 
> > However, we have solid hard data that it's a non-issue.
> > 
> > Gnome has been mirrored on github for nearly 2 years, in that time GTK has
> > had a grand total of 4 pull requests over time.
> > Most others (gedit, cheese, epiphany) have had 0.
> > 
> > Interestingly they have had literally hundreds of github "forks", which
> > implies it has led to sustantiable numbers of patches back using the
> > traditional methods
> > 
> > I've made a wiki page, which says how to turn a pull request into a
> > reviewboard submission.
> > https://techbase.kde.org/Development/GithubMirror
> > 
> > If we get any questions we can then just copy and paste that, and don't
> > need to spend any time explaining. Bam, done.
> 
> Thank you David, for your get-things-done approach in this controversial and
> tense situation. It is really much easier to solve than it seems from all
> these threads.
> 
> I'm personally in favor of letting projects decide whether to allow GitHub
> pull requests or not, but regardless of the final decision it is good to
> already have practical solutions like this techbase entry.
> 
> I find it unfortunate that some long time KDE contributors feel that KDE
> goals are threatened by all this. I understand their concerns, but I assign
> those concerns a different priority score. In fact, the inflexible policy
> towards 3rd party (including proprietary) infrastructure and processes we
> have in KDE deters me from bringing some of my own (currently
> GitHub-hosted) work under the KDE umbrella, as this would hinder some very
> productive working relationships with our downstreams and potentially
> result in *less* free open source software being produced, deployed and
> used.

That's something you have convinced yourself about, you don't have proof.

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

Re: [kde-community] Official KDE mirror on github

[Shantanu Tushar]

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

> On 19 September 2015 at 19:34, Vishesh Handa  wrote:
> > Please note that consistency isn't a requirement to be part of KDE. If
> > I decide to write an application in Rust, which is only for Windows,
> > and uses a completely different build system, that is allowed.
>
> How are these two things even remotely similar? Of course you're
> allowed to write a Windows specific app in Rust. Hell, according to
> the manifesto we should be able to write apps for the Commodore64 if
> we want to, provided that the software complies with licensing and
> community engagement requirements of the KDE community. On a more
> realistic note, almost all KDE apps have their own coding style, and
> every maintainer has their own standard on how far to stick to these
> styles.
>
> It is important to note that we're talking about infrastructural
> consistency here, not code consistency. There is a distinction. What
> you're suggesting is akin to GitHub deciding to have a HTML5 text
> console for half their repository pages, and their standard web
> interface for the other half, with glitzy christmas decorations and
> falling snow effects put on a few pages for good measure.
>
>
Adding to this, its not even about just the infrastructure, its about
workflow consistency. Why do we wish to confuse newcomers by giving them
two methods of code contributions when we can live with just one?

(oh and btw, and though its not really relevant to this discussion,
consistency was one of *the* founding principles of KDE, go read the 2nd
sentence at https://www.kde.org/announcements/announcement.php )


> >>
> >> 3. Regarding point 4, if developers already have personal GitHub
> >> clones that they use for their own purposes, nothing is stopping them
> >> from continuing to use them. Those clones are not endorsed by KDE,
> >> they are under complete control of the individual
> >> developers/maintainers, they are entirely the responsibility of the
> >> developers/maintainers, and the developers/maintainers are free to do
> >> with them as they see fit.
> >>
> >
> > Because maintainers are not responsible for their own projects anyway?
> > If I'm taking responsibility for a project, I'm also taking
> > responsibility for other parts of it. In this case Github. No one is
> > forcing anyone.
> >
>
> Common ownership. There's a difference between any random open source
> project on GitHub/SF.net/elsewhere and a KDE project. Maintainers are
> responsible for their own projects (that's why they're maintainers).
> They're also responsible for playing nice with the rest of the
> community and abiding by the requirements of the rest of the
> community. Also, while the rest of KDE may not have a say in the code
> of the project (the maintainer is the maintainer because he/she
> understands the code to a higher degree than the rest of the people
> here), they do have a say in the project's governance.
>
> >> Here's what developers and maintainers should really do: forget that
> >> github.com/kde exists.
> >
> > They can do that if they are comfortable with the status-quo. Some
> > people are clearly not. Your email disregards the points raised and
> > implies that the github readonly mirror is only what is acceptable.
> > That result is clearly not shared by everyone.
>
> This comment disregards the entire e-mail which is about why the
> read-only mirror should be acceptable. Again, why it should be
> acceptable is because it's as important to the KDE infrastructure as
> an anongit server.
>
> >> For all practical purposes, it does not exist.
> >> It isn't there. It should never be a part of your workflow. You should
> >> never ever look at it. It is simply an additional clone source, just
> >> like KDE's anongit servers. That's it.
> >
> > This is the part of your email I really like. Though this is not what
> > you meant: If projectX choose to also use Github, it is not affecting
> > your project in anyway. Just ignore it and move on.
>
> I re-iterate. github.com/kde is a place where people outside the KDE
> ecosystem can come and see the code in all its glory. To a KDE
> developer, it does not exist.
>
> Cheers,
> Boudhayan Gupta
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>



-- 
Shantanu Tushar(UTC +0530)
shantanu.io
___
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] Official KDE mirror on github

[Riccardo Iaconelli]

On Saturday, September 19, 2015 04:26:04 PM Luigi Toscano wrote:
> But that's not using the pull request. Such workflow would mean that the
> pull request is not accepted anyway, but the code is pushed through the
> infrastructure and not trough Github interface.
> 
> Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please
> explain exactly what is the meaning of "use Github"? Do we all agree that in
> any way pull requests will never be merged directly through Github
> interface?

Personally speaking, yes, they will never be merged directly through Github.

Github mirrors should be read-only, accepting pull requests (or maybe we 
should call them "fetch requests") shouldn't make them read-write.

Bye,
-Riccardo

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

Re: [kde-community] Write our own pull request bot?

[Martin Klapetek]

To further expand on the idea, the workflow would be as follows:

* bot looks through our repos
* bot finds a pull request
* bot downloads the diff between requested branch and mirror HEAD
* bot uploads it to phabricator as any other patch
* bot posts message to github "Thanks for your patch, in KDE we use
phabricator for reviewing and merging patches, so your pull request was
posted here . If you want to follow it through, please continue the
discussion at . Thanks a lot for your contribution!"
* contributor follows on phabricator

The problem is the needed identity account to follow it through though.

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

Re: [kde-community] Write our own pull request bot?

[Sune Vuorela]

On 2015-09-19, Martin Klapetek  wrote:
> To further expand on the idea, the workflow would be as follows:
>
> * bot looks through our repos
> * bot finds a pull request
> * bot downloads the diff between requested branch and mirror HEAD
> * bot uploads it to phabricator as any other patch
> * bot posts message to github "Thanks for your patch, in KDE we use
> phabricator for reviewing and merging patches, so your pull request was
> posted here . If you want to follow it through, please continue the
> discussion at . Thanks a lot for your contribution!"
> * contributor follows on phabricator

What happens if contributor doesn't follows? How do I as a reviewer know
why the contributor doesn't follow on? How can I reach them?

No. let's just say no to pull requests.

/Sune

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

Re: [kde-community] Official KDE mirror on github

[Jaroslaw Staniek]

On 19 September 2015 at 17:36, Riccardo Iaconelli  wrote:
> On Saturday, September 19, 2015 04:26:04 PM Luigi Toscano wrote:
>> But that's not using the pull request. Such workflow would mean that the
>> pull request is not accepted anyway, but the code is pushed through the
>> infrastructure and not trough Github interface.
>>
>> Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please
>> explain exactly what is the meaning of "use Github"? Do we all agree that in
>> any way pull requests will never be merged directly through Github
>> interface?
>
> Personally speaking, yes, they will never be merged directly through Github.
>
> Github mirrors should be read-only, accepting pull requests (or maybe we
> should call them "fetch requests") shouldn't make them read-write.

Yes, freedom-wise these are like *.patch attachments in gmail e-mails.
(I repeat this maybe third time?)

@All
Let me show the steps I am taking as a maintainer:

1. I get an email with *.patch attachments, it can be raw email or a
notification from system such as github
2. I am briefly looking at the contents and decide what next
3a. If the patch comes from a first time contributor and it's worth
reviewing I submit it for review in the official infra or asking a
fellow contributor to do that; if not, I am gently replying to the
author about reasoning and further possible steps
3b. If the patch comes from a next time contributor and it's worth
reviewing I am gently asking if she would like to consider a shorter
path, what is close to asking for joining KDE but in a more gentle
manner
4. From now on normal KDE review process happens and if the code is
accepted it lands in the read-write repo, not in the mirror. It's
clear from the first minute because the project description in the
GitHub mirror says so.

Sometimes *popular* projects are silently forked in GitHub. People are
in hurry so this happens and it's still better than keeping the
patches private. In this case if I find usable code this extra step is
needed:
0. Extract the patch(es) on my own from the forked repo and contact
the author to come into agreement about upstream merge.

In *no* step above I am attempting to patronize potential contributors
based on their different tool set, skills, etc. I am also aware that
in general *no bot* can replace me in this duty. I am also assuming
the patches that have been created are frequently *side tasks* for the
authors and not the ultimate goals. These contacts sometimes start
*long-term* contributions and relations.

-- 
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, 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] Write our own pull request bot?

[Riccardo Iaconelli]

On Saturday, September 19, 2015 01:17:18 PM Martin Klapetek wrote:
> To further expand on the idea, the workflow would be as follows:
> 
> * bot looks through our repos
> * bot finds a pull request
> * bot downloads the diff between requested branch and mirror HEAD
> * bot uploads it to phabricator as any other patch
> * bot posts message to github "Thanks for your patch, in KDE we use
> phabricator for reviewing and merging patches, so your pull request was
> posted here . If you want to follow it through, please continue the
> discussion at . Thanks a lot for your contribution!"
> * contributor follows on phabricator

I would say that is amazing!

Trick the user into making a quick fix+pull request (standard workflow for 
him) and we automagically import his work in our infrastructure, ready for 
review. "Woo" from his side and moral obbligation to get a KDE account. :D

I love it.

Bye,
-Riccardo

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

Re: [kde-community] Renaming KScreenGenie

[techie . rajeev]

People are not dumb.. especially those already familiar with KDE and linux... 
however in my opinion we need to think of newbies too. 

I search apps on google all the time, some time in youtube to see a demo of 
it.. Searching for selfie will result in all the smartphones, all the different 
selfie related stuff which is currently viral among the masses. 

with old naming structure with a k the advantage was it was never a actual 
english word and was always unique so never had issues with searching.. 

Just my 2 cents

Thanks

Regards
Rajeev
On Saturday, September 19, 2015 03:16:40 PM Eike Hein wrote:
> On 09/19/2015 11:36 AM, rajeev bhatta wrote:
> > Like the name selfie..but it will be nightmare finding the app in google
> > if looking for selfie
> 
> No it won't. People aren't too dumb to add an extra
> keyword. Internet search is a well-developed skill
> for anyone under 30 at this point.
> 
> Plus, why would internet searches be common in the
> first place? I've never searched for KSnapshot. Have
> you?
> 
> 
> Cheers,
> Eike
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Write our own pull request bot?

[Martin Klapetek]

On Sat, Sep 19, 2015 at 1:28 PM, Sune Vuorela  wrote:

>
> What happens if contributor doesn't follows? How do I as a reviewer know
> why the contributor doesn't follow on? How can I reach them?
>
> No. let's just say no to pull requests.
>

Same thing as when someone emails you a patch and you reply and ask
questions and never hear back. That happens quite often already.

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

Re: [kde-community] Renaming KScreenGenie

[Eike Hein]

On 09/19/2015 07:32 PM, techie.raj...@yahoo.in wrote:
> I search apps on google all the time, some time in youtube to see a demo of 
> it.. Searching for selfie will result in all the smartphones, all the 
> different 
> selfie related stuff which is currently viral among the masses. 

Yeah. And at that point they add "linux" or "kde" to the
search, if they didn't do it already because they realized
that Selfie by itself is too generic.

But honestly the most likely search pattern would be "kubuntu
how to take screenshot" leading to "run Selfie".

Does a non-generic name save typing in corner scenarios?
Yeah. Is that an issue that seriously compromises the
name? I don't think so. I mean, OS X' screenshot util is
called "Grab" ...


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

Re: [kde-community] Write our own pull request bot?

[Laszlo Papp]

On Sat, Sep 19, 2015 at 6:37 PM, Martin Klapetek
 wrote:
> On Sat, Sep 19, 2015 at 1:28 PM, Sune Vuorela  wrote:
>>
>>
>> What happens if contributor doesn't follows? How do I as a reviewer know
>> why the contributor doesn't follow on? How can I reach them?
>>
>> No. let's just say no to pull requests.
>
>
> Same thing as when someone emails you a patch and you reply and ask
> questions and never hear back. That happens quite often already.

Sure, but why would increase this situation further on?

I agree with everything that Sune wrote. Reaching them might be
particularly important when changing license just for one of those.
There could be numerous other valid examples.

Why put energy into making sure that they can diverge from the normal
workflow rather than putting energy on making sure that the workflow
is known and easy to get?

There used to be life before github, too. This is exactly the vendor
lock-in, when some people can no longer breat without it for such
simple things.

>
> Cheers
> --
> Martin Klapetek | KDE Developer
>
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
___
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] 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] 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] 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] Official KDE mirror on github: code searching facility

[Martin Steigerwald]

Am Samstag, 19. September 2015, 21:15:41 CEST schrieb Boudhayan Gupta:
> On 19 September 2015 at 20:52, Vishesh Handa  wrote:
[…]
> > I think we're talking about different things. The read-only mirror is
> > done, and shipped. I was talking about projects being able to also use
> > github, and the rest of the community respecting that decision.
> 
> Precisely. Martin's original suggestion, which we have shipped, was to
> provide a read only mirror on GitHub for the drive-by folks who only
> check GitHub for open source code. It is important to note that the
> developers have no control over this organization on GitHub (only the
> sysadmins do - even I was removed after I finished all my scripting),
> nor should they (just like they don't have write access to the anongit
> servers). I re-iterate - GitHub, at the moment, is nothing more than a
> (smart) anongit server. And we (the sysadmins) are not inclined to
> treat it any better than that because it's not under our control and
> we will not be able to guarantee that it'll work two weeks from now.
> 
> If you want to "use github", whatever that means, by all means
> maintain a repo under your personal account, and continue to use it as
> you were using it. No one's stopping you.

If its mainly about providing search for sourcecode, how about

https://codesearch.debian.net/

https://codesearch.debian.net/about


Ironically Michael Stapelberg hosts the source code with github.com:

https://github.com/Debian/dcs

Thanks,
-- 
Martin
___
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] 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

[kde-community] Help for sprint guidance/organization

[Riccardo Iaconelli]

Hi all,

(hoping to break the thousands of emails currently being written...) we're 
having our first sprint at WikiToLearn!!!
It's an exciting news since most of the participants are absolutely newcomers 
to FOSS development (let alone to KDE), and to various degrees to WikiToLearn 
too. The contribution areas are very diverse (content, code, 
infrastructure...), so there are some discussions which can't be held 
together. To complicate the matter, the sprint is happening this weekend (it 
was organized just two weeks ago), it will have 8 participants, and I will 
have (as WTL maintainer and sprint organizer) to guide it.

It is my greatest objective to make this sprint productive and especially 
community building, to give every participant the sense of how beautiful and 
inclusive our community is.

Since it's been a few years since my last KDE sprint, I am admittedly quite 
rusty on how to make a sprint work best. I have checked online and I found no 
guidance on how to make a good sprint that can perform well.

I want to take the opportunity to ask the help of the community! I need help 
in guidance, tips and tricks to help make the sprint as good as possible (hey, 
why don't we have a KDE knowledge base on these community matters?). Could you 
share some of the things that you found the most helpful in your past sprints? 
What did you like, what did you find productive? Did scrum work for you? How 
would you organize it? How would you structure the day? What infrastructure 
would you bring?

Thanks a lot for your input. :-)

-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] 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] 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] 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