Re: [kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?

[Vishesh Handa]

On Feb 8, 2016 11:51, "Jonathan Riddell"  wrote:
>
> I also heard a suggestion from Vishesh that projects like Amarok
> shouldn't be allowed in GSoC because they are not very active.  It
> seems nonsense to block projects from having activity on grounds that
> they are not very active.

I stand by this.

If a project has no developers who actively contribute to it, putting
students on it with the hope that they will take care of it, is too
optimistic.

>
> Jonathan
> ___
> 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] Forums downtime for reorganization

[Vishesh Handa]

Hey

Do you think the "Semantic Desktop" forum could be removed? Unless,
I'm too late.

--
Vishesh Handa


On Sat, Sep 26, 2015 at 9:03 AM, Luca Beltrame <lbeltr...@kde.org> wrote:
> Hello,
>
> today we will start a forum structure reorganization that will hopefully
> make the hierarchy more logical, and to remove unused and dead forums,
> along with fixing other minor annoyance. When this happens, the forums will
> be closed until the reorganization is complete.
>
> We expect this to occur around 16 UTC.
>
> How long will this take? It depends on how much manual work is required,
> but hopefully not more than a couple of hours.
>
> ___
> 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] Forums downtime for reorganization

[Vishesh Handa]

On Sat, Sep 26, 2015 at 4:01 PM, Luca Beltrame <lbeltr...@kde.org> wrote:
> Currently we're renaming it to "Desktop Search".

Perhaps "File Search"? Though I think I may have replied too late.

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

[Vishesh Handa]

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

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

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

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

[Vishesh Handa]

On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić <ivan.cu...@kde.org> 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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 2:12 PM, Myriam Schweingruber <myr...@kde.org> 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

[Vishesh Handa]

On Sat, Sep 19, 2015 at 1:04 PM, Martin Steigerwald <mar...@lichtvoll.de> 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] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 5:23 AM, Michael Pyne <mp...@kde.org> 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] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 9:46 AM, Shantanu Tushar Jha <shant...@kde.org> 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

[Vishesh Handa]

On Sat, Sep 19, 2015 at 11:44 AM, Luca Beltrame <lbeltr...@kde.org> 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 <lp...@kde.org> 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
<mar...@lichtvoll.de> 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 <bgu...@kde.org> 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] Official KDE mirror on github

[Vishesh Handa]

On Sat, Sep 19, 2015 at 4:37 PM, Boudhayan Gupta <bgu...@kde.org> wrote:
> On 19 September 2015 at 19:34, Vishesh Handa <m...@vhanda.in> 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] What is a GitHub pull request exactly?

[Vishesh Handa]

On Sat, Sep 19, 2015 at 5:32 PM, Kevin Krammer <kram...@kde.org> 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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 5:53 PM, Martin Graesslin <mgraess...@kde.org> 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*

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:04 PM, Martin Graesslin <mgraess...@kde.org> 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?

[Vishesh Handa]

On Sat, Sep 19, 2015 at 6:37 PM, Martin Graesslin <mgraess...@kde.org> 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] Bikeshedding - our strength apparently *sigh*

[Vishesh Handa]

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

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

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

"often" but not always.

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

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

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

[Vishesh Handa]

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

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

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

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

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

[Vishesh Handa]

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

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

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

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

[Vishesh Handa]

On Sat, Sep 19, 2015 at 3:29 PM, Eike Hein <h...@kde.org> wrote:
> You're ignoring the position that says "the long-term
> negatives outweigh the short-term positives on this",
> though.

Well, I clearly think differently. I do not see any long term
negatives which cannot be addressed.

--
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 4:15 PM, Eike Hein <h...@kde.org> wrote:
>
>
> On 09/19/2015 04:04 PM, Vishesh Handa wrote:
>> 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.
>
> You keep reiterating this, but it's simply not true:
>
> * Disagreement on whether to use GitHub or not can extend
>   into the sub-community around a given project and cause
>   strife there.
>

Just as can any other issues such as using any other proprietary service.

> * Some of our project sub-communities have many maintainers
>   for smaller sub-projects that comprise the larger project,
>   and these sub-projects need to collaborate for consistency.
>
>   The topology of 'project' is not a match to our repository
>   topology, which is incidental and an implementation detail.
>   It's not possible to cleanly turn GitHub on or off along
>   the - ever-shifting - social boundaries involved.
>

I don't follow. And reviewboard will still be the primary source.

If we ship a bot we can enable and disable it however we want.

> * Different per-project tooling definitely creates pressures
>   on projects to provide the same tooling as other projects.
>   We've got practical experiences with this from our trial
>   runs with gerrit and Phabricator.
>

And we can be sensible and see what pressures we're going to
accommodate with and which we arent'. Not really an issue.

> * 'Common ownership' in the Manifesto is a core value that
>   e.g. begats shared workflows like our shared developer
>   account application process and our shared repository
>   access model. This stuff is important. It's hard to main-
>   tain the idea of common ownership if we create barriers
>   for people moving within the project by fragmenting our
>   core workflows.

Your core workflow is NOT fragmented if github is an addition which is
not recommended.

>   If someone doesn't want to work with Git-
>   Hub they're barred from stepping up and maintaining
>   project X that's using GitHub by a previous maintainer's
>   decision, unless they do the work to reverse that decision,
>   which can get us back to the first bullet.
>

Just as if someone project is shipping Windows binaries, one cannot
step up and maintain that project. Big deal! There are always
differences.

For maintaining KDE Connect you'll have to start using Google's
services and publish it on Google Play.

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

[Vishesh Handa]

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

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

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

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

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

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

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

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

[Vishesh Handa]

On Sat, Sep 19, 2015 at 2:20 AM, Albert Astals Cid <aa...@kde.org> 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.
>
> You do use non free tools, but KDE doesn't recommend nor bless them in any
> way, this would be quite a departure from that setup.

I don't think anyone is suggesting that KDE recommends using Github or
any other non-free tool. However, certain projects within the KDE
umberella can be willing to occasionally utilize non-free 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 Fri, Sep 18, 2015 at 10:14 PM, Martin Graesslin <mgraess...@kde.org> wrote:
> So I join Sune, Eike and Marco: "Free software needs free tools, no
> proprietary pull requests for KDE development!"

-1

I would prefer us to be more pragmatic. If an adequate free-software
tool exists, lets try to use it. If a proprietary tool provides a
better experience lets use that. For my own projects I will advocate
reviewboard/phabricator, but I'm comfortable excepting a fly-by patch
on github. Specially since they provide a simple web-UI for making
changes.

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.

--
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 Fri, Sep 18, 2015 at 9:05 PM, Jaroslaw Staniek <stan...@kde.org> wrote:
> 2. Regarding the issues/pull requests - nobody agreed/disagreed to my 
> proposal.
> Is anyone against an *opt-in* possibility of enabling Issues and/or
> Pull Requests for a given mirrored repo? Opt-in by maintainer of the
> patches. We can easily draft a policy if someone is afraid.
>

+1 for pull requests on an opt-in basis.

>
> Until we have "free" bountysource-like infra, I do need github Issues.
> I also work with bountysource so they find a way to better support
> bugs.kde.org; for now one can paste the url and it works but issues
> "for adoption" are not listed.

For me this seems reasonable. Since we are lacking support for Bounty
Source and a particular maintainer wants/needs it, they should be able
to use a custom solution until it is provided.

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.

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

Ping?

What's the status of this? I have a copy of Baloo on github, and I
have been thinking of creating a "KDE Baloo" organization (or KDE) so
that it is not under my name. I would obviously prefer an official
mirror instead of me updating it manually.

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

Re: [kde-community] Using Milou

[Vishesh Handa]

Hey Jacky

On Wed, Mar 11, 2015 at 11:23 PM, Jacky Alcine jackyalc...@gmail.com
wrote:

 Hey,

 How does one go about extending Milou? I’m curious about adding Web search
 results from places like DuckDuckGo or Wikipedia to it?


As Albert mentioned, kde-devel is probably the correct place. I've cced
kde-devel, please remove the community mailing list when replying :)

Milou was created for KDE4, and is currently no longer being developed.
With Plasma 5, its codebase has merged with KRunner, and we provide both
KRunner and a Plasmoid called Search, which is effectively Milou, minus
the previews (still not ported to Plasma5)

It might be best for you to just written KRunner plugins, if you're
targeting Plasma 5. If you want to target KDE4, have a look at the milou
source code (milou/lib/sources/) and try copying and modifying any of the
existing sources to meet your needs.

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

Re: [kde-community] retiring unmaintained modules?

[Vishesh Handa]

 I'll be closing all the Nepomuk bugs.

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

[kde-community] Closing the kde-core-devel mailing list

[Vishesh Handa]

Hello people

Random Idea: How about we close the k-c-d mailing list? It's main purpose used 
to be to discuss kdelibs changes, but now since we have kde-frameworks, the 
mailing list seems less useful. We already have kde-devel for other generic 
kde stuff.

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