Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Ivan Čukić]

>> > work! With our developer weight visibility is guaranteed! United we
>> > stand...
>> e.g. Gitlab?
> Or Phabricator, since we as a community have choosen it?

+1


Cheerio,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Matthew Dawson]

On September 25, 2015 01:16:46 PM Jaroslaw Staniek wrote:
> On 25 September 2015 at 13:15, Riccardo Iaconelli  wrote:
> > On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote:
> >> I really do not want the excellent parts of this impassioned
> >> discussion to get lost! We've wondered about it before, and perhaps it
> >> is time to look at this issue again.
> > 
> > A web ui?
> > I think that more and more github should be our real competitor, we should
> > strive for the same user-friendliness... :-)
> > 
> > A crazy idea: why don't we unite our weight with the one of sister free
> > software projects (GNOME, Wikimedia, ...)  to create a free ecosystem
> > (with
> > personal repos and organization, exactly like github) where free projects
> > can be hosted, develop and flourish?
> > 
> > If we all decide to host our code on the same resources, we can make this
> > work! With our developer weight visibility is guaranteed! United we
> > stand...
> e.g. Gitlab?
Or Phabricator, since we as a community have choosen it?  Whatever we choose, 
we can always improve to make it better anyways.

Though I think if we are going to move in this direction, the CI behind it 
needs to be more flexible, like Travis CI I'm thinking (used by many Github 
projects, but is Github specific).  Our current CI is wonderful for our uses, 
just thinking for this grand unified plan.
-- 
Matthew

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 in the light of the KDE manifesto

[Kevin Ottens]

On Sunday 27 September 2015 08:25:49 Ben Cooksley wrote:
> On Sat, Sep 26, 2015 at 9:33 AM, Albert Astals Cid  wrote:
> > El Divendres, 25 de setembre de 2015, a les 13:16:46, Jaroslaw Staniek va
> > > e.g. Gitlab?
> > 
> > AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so
> > unless it has improved it would not work with KDE + more stuff.
> 
> Gitlab itself crawled due to the way it handled groups - it simply
> wasn't designed to handle a single group containing KDE's ~2000
> developers. It also had some fundamental issues with how repositories
> got moved around - so if a repository was moved from a user's personal
> namespace to the shared KDE namespace, every single KDE developer
> would get spammed about this.
> 
> Sysadmin also had some concerns regarding the integrity of the
> codebase (which was what really killed it).

And that's not even considering that the review tools of GitLab are really not 
great. They might have improved the last time I tried, but other options did a 
much better job.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



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 in the light of the KDE manifesto

[Riccardo Iaconelli]

On 25 September 2015 at 23:33, Albert Astals Cid  wrote:
> AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so
> unless it has improved it would not work with KDE + more stuff.

should we try to get more powerful machines...? ;-)

-Riccardo
-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Ben Cooksley]

On Sat, Sep 26, 2015 at 9:33 AM, Albert Astals Cid  wrote:
> El Divendres, 25 de setembre de 2015, a les 13:16:46, Jaroslaw Staniek va
> escriure:
>> On 25 September 2015 at 13:15, Riccardo Iaconelli  wrote:
>> > On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote:
>> >> I really do not want the excellent parts of this impassioned
>> >> discussion to get lost! We've wondered about it before, and perhaps it
>> >> is time to look at this issue again.
>> >
>> > A web ui?
>> > I think that more and more github should be our real competitor, we should
>> > strive for the same user-friendliness... :-)
>> >
>> > A crazy idea: why don't we unite our weight with the one of sister free
>> > software projects (GNOME, Wikimedia, ...)  to create a free ecosystem
>> > (with
>> > personal repos and organization, exactly like github) where free projects
>> > can be hosted, develop and flourish?
>> >
>> > If we all decide to host our code on the same resources, we can make this
>> > work! With our developer weight visibility is guaranteed! United we
>> > stand...
>> e.g. Gitlab?
>
> AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so
> unless it has improved it would not work with KDE + more stuff.

Gitlab itself crawled due to the way it handled groups - it simply
wasn't designed to handle a single group containing KDE's ~2000
developers. It also had some fundamental issues with how repositories
got moved around - so if a repository was moved from a user's personal
namespace to the shared KDE namespace, every single KDE developer
would get spammed about this.

Sysadmin also had some concerns regarding the integrity of the
codebase (which was what really killed it).

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > Bye,
>> > -Riccardo
>> >
>> > ___
>> > 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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Ben Cooksley]

On Sun, Sep 27, 2015 at 5:30 AM, Riccardo Iaconelli  wrote:
> On 25 September 2015 at 23:33, Albert Astals Cid  wrote:
>> AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so
>> unless it has improved it would not work with KDE + more stuff.
>
> should we try to get more powerful machines...? ;-)

Throwing hardware at the issue wouldn't have solved the issue from
what I believe - we only threw a handful of our larger repositories at
it.

>
> -Riccardo

Cheers,
Ben

> --
> Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
> Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
> Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
> ___
> 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 in the light of the KDE manifesto

[Riccardo Iaconelli]

On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote:
> I really do not want the excellent parts of this impassioned
> discussion to get lost! We've wondered about it before, and perhaps it
> is time to look at this issue again.

A web ui?
I think that more and more github should be our real competitor, we should 
strive for the same user-friendliness... :-)

A crazy idea: why don't we unite our weight with the one of sister free 
software projects (GNOME, Wikimedia, ...)  to create a free ecosystem (with 
personal repos and organization, exactly like github) where free projects can 
be hosted, develop and flourish?

If we all decide to host our code on the same resources, we can make this 
work! With our developer weight visibility is guaranteed! United we stand...

Bye,
-Riccardo

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

Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Jaroslaw Staniek]

On 25 September 2015 at 13:15, Riccardo Iaconelli  wrote:
> On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote:
>> I really do not want the excellent parts of this impassioned
>> discussion to get lost! We've wondered about it before, and perhaps it
>> is time to look at this issue again.
>
> A web ui?
> I think that more and more github should be our real competitor, we should
> strive for the same user-friendliness... :-)
>
> A crazy idea: why don't we unite our weight with the one of sister free
> software projects (GNOME, Wikimedia, ...)  to create a free ecosystem (with
> personal repos and organization, exactly like github) where free projects can
> be hosted, develop and flourish?
>
> If we all decide to host our code on the same resources, we can make this
> work! With our developer weight visibility is guaranteed! United we stand...
>

e.g. Gitlab?

> Bye,
> -Riccardo
>
> ___
> 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 in the light of the KDE manifesto

[Riccardo Iaconelli]

On Friday, September 25, 2015 01:16:46 PM Jaroslaw Staniek wrote:
> e.g. Gitlab?

It is more freedesktop.org... The software is not a problem (gitlab for that 
works amazing), but I was more looking to two points:

* a real a community hosting (not https://about.gitlab.com/terms/ )

* more importantly: code development of FOSS projects *moves* there (not just 
a mirror), under a shared, unique home. This is the strenght of github now, we 
should do the right thing and put our weight supporting a shared free 
alternative instead.

Bye,
-Riccardo

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

Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto

[Albert Astals Cid]

El Divendres, 25 de setembre de 2015, a les 13:16:46, Jaroslaw Staniek va 
escriure:
> On 25 September 2015 at 13:15, Riccardo Iaconelli  wrote:
> > On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote:
> >> I really do not want the excellent parts of this impassioned
> >> discussion to get lost! We've wondered about it before, and perhaps it
> >> is time to look at this issue again.
> > 
> > A web ui?
> > I think that more and more github should be our real competitor, we should
> > strive for the same user-friendliness... :-)
> > 
> > A crazy idea: why don't we unite our weight with the one of sister free
> > software projects (GNOME, Wikimedia, ...)  to create a free ecosystem
> > (with
> > personal repos and organization, exactly like github) where free projects
> > can be hosted, develop and flourish?
> > 
> > If we all decide to host our code on the same resources, we can make this
> > work! With our developer weight visibility is guaranteed! United we
> > stand...
> e.g. Gitlab?

AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so 
unless it has improved it would not work with KDE + more stuff.

Cheers,
  Albert

> 
> > Bye,
> > -Riccardo
> > 
> > ___
> > 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 in the light of the KDE manifesto

[Jaroslaw Staniek]

On 25 September 2015 at 23:33, Albert Astals Cid  wrote:
> El Divendres, 25 de setembre de 2015, a les 13:16:46, Jaroslaw Staniek va
> escriure:
>> On 25 September 2015 at 13:15, Riccardo Iaconelli  wrote:
>> > On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote:
>> >> I really do not want the excellent parts of this impassioned
>> >> discussion to get lost! We've wondered about it before, and perhaps it
>> >> is time to look at this issue again.
>> >
>> > A web ui?
>> > I think that more and more github should be our real competitor, we should
>> > strive for the same user-friendliness... :-)
>> >
>> > A crazy idea: why don't we unite our weight with the one of sister free
>> > software projects (GNOME, Wikimedia, ...)  to create a free ecosystem
>> > (with
>> > personal repos and organization, exactly like github) where free projects
>> > can be hosted, develop and flourish?
>> >
>> > If we all decide to host our code on the same resources, we can make this
>> > work! With our developer weight visibility is guaranteed! United we
>> > stand...
>> e.g. Gitlab?
>
> AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so
> unless it has improved it would not work with KDE + more stuff.
>

Yes. Maybe it's time to for KDE to co-develop more server software? :)
Sounds like something more feasible than co-developing specs around
potential common development workflow.

-- 
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 in the light of the KDE manifesto

[Valorie Zimmerman]

Thank you, Martin. Snipping all but your final, awesome, question:

On Sat, Sep 19, 2015 at 5:05 AM, Martin Steigerwald  wrote:

::snip good post::

> Another approach would be: How can KDE infrastructure evolve into something
> that makes contributing as easy or even easier than github.com? What needs to
> be improved in order to invite github.com users onto KDE´s own infrastructure?
>
> Ciao,
> --
> Martin

I really do not want the excellent parts of this impassioned
discussion to get lost! We've wondered about it before, and perhaps it
is time to look at this issue again.

Valorie

-- 
http://about.me/valoriez
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Valorie Zimmerman]

I went back to the beginning of this discussion, and think a few
issues have been passed over. For instance, this one which has nothing
to do with the Github mirror, and everything to do with improving our
own software / discoverability:

On Mon, Aug 17, 2015 at 1:10 AM, Jos van den Oever  
wrote:
> On Monday 17 August 2015 09:16:02 Martin Sandsmark wrote:
>> On Mon, Aug 17, 2015 at 12:35:09PM +0530, Bhushan Shah wrote:
>> > In my opinion first two are too wrong arguments to begin with.. If our
>> > repositories can not be found from outside then it requires
>> > improvement from our side. Putting source code on Github is not going
>> > to solve this problem.
>>
>> I don't think improving discoverability of our own infrastructure and
>> putting mirrors of our code on Github are mutually exclusive. I think both
>> will improve our "visibility" so to speak.
>>
>> > Even if people will use github to search projects eventually they will
>> > have
>> > to use our infrastructure to contribute.
>>
>> In my opinion all of our projects should have a short description about how
>> and where to send us their patches, even if we don't push things to Github.
>> If we ensure that our git repositories can be found via search engines
>> people still need to know how to contribute.
>
> Agree. This is a good idea regardless of mirroring on GitHub.
>
> A mandatory preamble in the README.md for each KDE project could go something
> like this:
>
> ==
> $name is a [KDE](https://www.kde.org/) project. The source code for $name can
> be found at [$git.kde.org/$name](https://$git.kde.org/$name). KDE welcomes you
> to [join KDE](https://community.kde.org/Get_Involved) and contribute to $name.
> You can report [issues and wishes]($git.kde.org/$name]
> (https://$git.kde.org/$name).
> 
> ==
>
> In this way, even if our repos are not completely indexed, the pagerank will
> increase a lot.
>
>> And I think lowering the threshold for people to contribute in general is
>> also something that should be done (and is being worked on already), and is
>> a bit separate from this thing about mirroring stuff on Github.
>>
>> > And about people being surprised that our code is not on Github, it is
>> > really clear that Github is _not_ standard place to get open source
>> > software.
>>
>> We might think so, but I don't think the rest of the world agrees.
>>
>> > So, In short IMO there is nothing wrong with having Github mirror but
>> > that should be read-only and we should have real reason to do it.
>> > Currently sysadmins are reworking our git infrastructure. So lets wait
>> > little bit and see how it goes and then think of this.
>>
>> Yeah, I agree that the reworking of our own infrastructure should be
>> prioritized, and we should disable the pull requests, bug reporting, etc.
>> for everything we put on github.

Are we doing something like this, now? Can it be done automatically on
*all* our mirrors?

Valorie

-- 
http://about.me/valoriez
___
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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Official KDE mirror on github

[Eike Hein]

On 09/19/2015 06:57 PM, Vishesh Handa wrote:
>>   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.

Some of the pro-arguments have been "it's opt-in" and
"you can ignore it if you want" in the context of
"projects". But in reality the toggle is per-repository,
and project != repository. Plasma is comprised of many
repositories. I maintain subfolders in plasma-desktop.git
but not the whole of it. I can't opt out of GitHub for,
say, the Task Manager if it's enabled for plasma-desktop.

There's no way to ignore GitHub and maintain common owner-
ship, really - for that reason and for the reason that a
gimped GitHub presence is arguable worse than no presence
(because it snubs rather than ignores an audience) the
decision is IMHO between 'allow GitHub code review in
general or don't'.


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

I'm saying that past experience has shown us that many devs
are frustrated about having to use multiple code review sites
and want back to one. This directly reads on the GitHub dis-
cussion, what's sensible about ignoring that ...?


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

Of course it's fragmented if code review happens on GitHub
for code I co-own by way of common ownership. There is no
way around that. The common owners of our code have to deal
with two code review sites starting from the first pull req.

I'd like us to simply not pretend otherwise. Allowing GitHub
affects everyone. Allowing GitHub in addition to our own
infrastructure is fragmentation. Those are simply facts. The
debate should be entirely about whether we want to live with
that or not.

Your "But we also use Google Hangouts" argument is much more
relevant. In fact, as someone who doesn't use Google Hangouts
and has repeatedly been pressured into using it or missed out
on opportunities to participate in decisions because of it,
I can tell you exactly what the downsides are to trying to
ignore the fragmentation that it constitutes.


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

Can we retire the Windows argument though? Project input !=
project output.


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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 16:44:54 CEST schrieb Martin Graesslin:
> On Saturday, September 19, 2015 3:28:56 PM CEST Luigi Toscano wrote:
> > Kevin Krammer ha scritto:
> > > On Saturday, 2015-09-19, 14:43:37, Bhushan Shah wrote:
> > >> 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
> > > 
> > > I have to say I don't have any experience with pull requests, whatever
> > > those are, but since Jaroslaw put the into the context of patches by
> > > email I would assume that the workflow still has all patches go through
> > > proper review, these pull request would just be a form of patch
> > > submission.
> > > 
> > > Lets consider an example, say Okular.
> > > 
> > > If Okular has the policy that nothing is merged without review, then all
> > > patches for Okular need to go through KDE's review tool
> > > (reviewboard/gerrit/phabricator/whatever).
> > > 
> > > If contributors to Okular feel they want to accept submission per email,
> > > bugzilla attachment or github pull request, then they will still have to
> > > submit these patches for review, no?
> > 
> > About this specific example, the normal answer to Okular patches on
> > bugzilla is "please send it through reviewboard".
> > 
> > Isn't it possible to automated this step on github? A bot/jenkins job that
> > checks for pull requests and writes this message whenever a pull request
> > is
> > opened on github, if it's not possible to disable them?
> 
> yes it is and David already pointed to it quite in the beginning of the
> discussion: http://nopullrequests.com/

Just to clarify:

I think if this way is chosen, the bot should be hosted by and be in control 
of KDE infrastructure. Which appears to be possible, as the source is provided 
under the Apache license:

https://github.com/imjasonh/nopullrequests

Otherwise it would be using one cloud service to fix a (intended?) flaw in 
other one.

Don´t know whether it works without a Google account tough as the "Let´s get 
started" link redirects to Google account login page.

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 17:22:03 CEST schrieb Vishesh Handa:
> > 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"

There is no guaranteed continuity with anything that is *written* to the 
github.com presence. Unless the KDE system admin team provides one by backup 
up the github.com presence and be prepared to host it in case of service 
outage or termination.

-- 
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 3:29 PM, Eike Hein  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  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] Official KDE mirror on github

[Albert Astals Cid]

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.

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

[Albert Astals Cid]

El Divendres, 18 de setembre de 2015, a les 23:28:37, Vishesh Handa va 
escriure:
> On Fri, Sep 18, 2015 at 10:14 PM, Martin Graesslin  
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.

Bollocks, github is awful to use, it took me like 15 minutes to learn how to 
submit a patch, just because you're used to it doesn't mean it's easier.

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

KDE is *one* project and we have one set of principles coded in the manifesto.

Cheers,
  Albert

> 
> --
> Vishesh Handa
> ___
> 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

[Riccardo Iaconelli]

On Saturday, September 19, 2015 02:12:13 AM Albert Astals Cid wrote:
> > 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.
> 
> Bollocks, github is awful to use, it took me like 15 minutes to learn how
> to  submit a patch, just because you're used to it doesn't mean it's
> easier.

It depends where other people are!

If a developer has a small fix to propose, and can just hack it through and 
use a known account and a familiar interface, so be it... github's interface 
is not magical just like KDE's one is not. ;-)

A big +1 with letting KDE projects free to experiment whatever (complimentary) 
tools they like best.

Bye,
-Riccardo


___
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 18 September 2015 at 14:17, Ben Cooksley  wrote:
> On Sat, Sep 19, 2015 at 12:14 AM, Jaroslaw Staniek  wrote:
>> On 18 September 2015 at 14:00, Ben Cooksley  wrote:
>>> On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek  wrote:
 On 18 September 2015 at 13:42, Boudhayan Gupta  wrote:
> Ladies and gentlemen, as you read this mail github.com/kde is being
> populated by the initial sync of all repositories.
>
> Maybe someone should make a public announcement?
>
> Shout out to Ben, he truly is a superhero.

 Thanks a lot!
 Is it possible to enable Issues support for a given project? (as I
 said needed by the bountysource infra at least)
>>>
>>> From what I saw of the above consensus, issues and pull requests would
>>> be disabled as those should go through our usual infrastructure
>>> (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
>>> post otherwise i'd be happy to be pointed to it though?
>>
>> I see what you mean but there was no discussion about this matter in
>> this thread at least.
>>
>> For code I maintain I welcome:
>> - any form of patches even if they come via pull requests, just like
>> for me emailed patches are also better than no patches
>> - any form of donations for features -> for that Issues are needed
>>
>> It's possible to fork these mirrors to get this support and I am doing
>> this now for a test in case of kreport.git.
>> https://github.com/staniek/kreport-1
>>
>> But again, please consider this as less controlled/predictable
>> activity - that forking will happen anyway, as this is the value of
>> github-based collaboration, and (IMHO) sense of our existence on
>> github.
>
> The decision isn't mine, it's the community's decision.

I know :)

> I've already
> added a note suggesting people submit patches on Reviewboard.
>

Don't we slowly drop support for Reviewboard?
(even I am still not sure how to correctly update phabricator diff
from command line)

> For a decision on those two points, i'd welcome pointers to where that
> was made in the above thread - or the opening of a new thread on those
> topics.

@all

I think this is still the very same thread "KDE mirrored on github".

1. A friendly bot is a good idea. Friendly i.e. not saying that
"you're doing bad thing using github".
But if I was external contributor I'd find rejecting my carefully
crafted patch rather offensive. Couldn't the link to the patch be sent
by email to a right mailing list?

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.

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.

Thanks again!

PS: Also I think that I don't spend time on projects to educate people
that they shouldn't use github. I am not competing in github's
businesses.

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

[Luca Beltrame]

Il Fri, 18 Sep 2015 22:14:04 +0200, Martin Graesslin ha scritto:

> So I join Sune, Eike and Marco: "Free software needs free tools, no
> proprietary pull requests for KDE development!"

I'm not such a big contributor, but I agree with the above people. We 
already have a big issue with "open" desktop, I really DON'T want to push 
more proprietary platforms.

The day KDE does this is the day I stop contributing. Entirely.

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

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

[Albert Astals Cid]

El Divendres, 18 de setembre de 2015, a les 23:43:34, Vishesh Handa va 
escriure:
> On Fri, Sep 18, 2015 at 9:05 PM, Jaroslaw Staniek  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.

I don't think the fact that exactly one developer wants to use a non free 
service should influence our common mirroring setup, yes remember this is a 
mirror.

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

Cheers,
  Albert

> 
> --
> Vishesh Handa
> ___
> 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

[Albert Vaca]

On Fri, Sep 18, 2015 at 5:17 PM, Riccardo Iaconelli 
wrote:

> On Saturday, September 19, 2015 02:12:13 AM Albert Astals Cid wrote:
> > > 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.
> >
> > Bollocks, github is awful to use, it took me like 15 minutes to learn how
> > to  submit a patch, just because you're used to it doesn't mean it's
> > easier.
>
> It depends where other people are!
>
> If a developer has a small fix to propose, and can just hack it through and
> use a known account and a familiar interface, so be it... github's
> interface
> is not magical just like KDE's one is not. ;-)
>
> +1

Albert, I think you are just used to reviewboard, it took me weeks to get
used to review board ;)

>From what I've read in this thread, nobody is against having Github solely
as a mirror. I propose we do that, mirror, and we leave pull requests and
issues as an opt-in feature.

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

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

[Vishesh Handa]

On Sat, Sep 19, 2015 at 2:20 AM, Albert Astals Cid  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

[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. :-)

Bye,
-Riccardo

___
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 Fri, Sep 18, 2015 at 2:53 PM, David Edmundson
 wrote:
>> > But again, please consider this as less controlled/predictable
>> > activity - that forking will happen anyway, as this is the value of
>> > github-based collaboration, and (IMHO) sense of our existence on
>> > github.
>>
> Issues can are disabled
>
> Pull requests we can't disable.
> However I've found this bot: http://nopullrequests.com/
>
> that gets pull requests then automatically repsonds closing it.
> Might be worth us doing, saying "go to reviewboard.kde.org"
>
> Just as a reminder


+1 for using this bot

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

[Andre Heinecke]

On Friday 18 September 2015 22:14:04 Martin Graesslin wrote:
> I must say I'm uneasy with the thought of allowing pull requests - even as
> an exception. Seeing this raised on the day the mirroring started makes me
> sad that I initiated the whole thing.

Yes I'm uneasy about that too. I thought "Well mirrors and copies of code are 
good so let them get on with that" but github is tantalizingly convenient and 
I fear we've started to open Pandora's Box here.

Github is convenient so if we offer that I'm scared that we will be pulled in 
there because it is more convenient to use then our infrastructure.

> So I join Sune, Eike and Marco: "Free software needs free tools, no
> proprietary pull requests for KDE development!"

+1

I also agree with Friedrich W. H. Kossebau's points in the other branch of 
this thread.

Regards,
Andre
-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
___
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 Fri, Sep 18, 2015 at 9:12 PM, Sune Vuorela  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.
>
> Yes. I'm against. And I'm also against mirroring on github, but I didn't
> voice my opinion by that because it was said that issues and pull
> requests are not to be enabled.


yes, i'm not willing to deal with pull requests from github as well.

I don't like being on github, but if everybody likes to have a copy
here that's fine, until it's a copy and i don't have to use it.

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

[Jaroslaw Staniek]

On 18 September 2015 at 21:16, Marco Martin  wrote:
> On Fri, Sep 18, 2015 at 9:12 PM, Sune Vuorela  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.
>>
>> Yes. I'm against. And I'm also against mirroring on github, but I didn't
>> voice my opinion by that because it was said that issues and pull
>> requests are not to be enabled.
>
>
> yes, i'm not willing to deal with pull requests from github as well.
>
> I don't like being on github, but if everybody likes to have a copy
> here that's fine, until it's a copy and i don't have to use it.

You don't have to use pull requests, as I said: opt-in feature of a repo.

I won't use it too in my workflow. Treat it as an exception: some folks in KDE
friendly and openly accept patches sent by email and _friendly_
encourage that next time for non-trivial work it will be better to use
official tools.

@Sune you're from KDE but for example packagers often use email to
send "fix build" patches.

Nobody responded to this to so I'll repeat: I won't reject early
attempts of people wanting to contribute so if I have to I'll use
personal forks on github and any other places where I actually can
meet contributors.

Then the Issues thing is another matter: I'd appreciate that you read
- I am not proposing to use it as alternative bugzilla (which is
terrible BTW) but to solve integration issue I am having. Hopefully it
will be sorted more cleanly one day.

PS: We're also supporting "nonstandard" approach: patches in bugzilla
(that can never be marked as rejected if are invalid), shouldn't this
feature be blocked?

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

[Eike Hein]

On 09/18/2015 09:12 PM, Sune Vuorela wrote:
> Yes. I'm against. And I'm also against mirroring on github, but I didn't
> voice my opinion by that because it was said that issues and pull
> requests are not to be enabled.
> 
> We should not proprietarize our development workflow. We should not work
> towards anything that locks us in anywhere. 
> 
> Free software needs free tools.

+1


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

[Michael Pyne]

On Fri, September 18, 2015 23:28:37 Vishesh Handa wrote:
> On Fri, Sep 18, 2015 at 10:14 PM, Martin Graesslin  
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.

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).

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?

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.

Just my two cents...

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

[Vishesh Handa]

On Fri, Sep 18, 2015 at 10:14 PM, Martin Graesslin  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

[Jaroslaw Staniek]

On 18 September 2015 at 22:55, Andre Heinecke  wrote:
> On Friday 18 September 2015 22:29:31 Jaroslaw Staniek wrote:
>> I don't argue with that it needs free tools. Of course we need to be
>> able to operate as usual when the nonfree tools disappear.
>
> As one of the KDE-Windows developers. Who would be able to cope if their
> precious Visual Studio is unavailable? Well probably you, Ralf and me (Because
> I never used that compiler). The other developers are suckered in a "I'ts free
> (as in beer)" (just like github) mentality and didn't learn to how the basics
> work that are automated when they use visual studio. So their knowledge is
> dependent on the tools.

I learned that investing in mimicking *nix experience on windows
(cygwin, mingw, finally plasma on Windows) is a dead end. If msvc
disappears I'll be more than happy and fund a big company the next
day. Hundreds of folks would come to for help to port/maintain somehow
the their codebase on the new standard dev platform[tm].

If you care to look why: by using "standards" on the platform I
minimize my risks.
When I support my apps on GNOME I obey to the rules of GNOME. Same for
Unity, Windows, Mac, and mobile etc. or don't proceed. Everything else
is not worth my time. Your experience and interest may be different
and I accept that.

Cheap example: I know people running win95 on an android phone.

If you pick mingw for example, you're just picking different boundary
that you can effectively accept between Free and non-Free. I'd ask,
even if MS changed its attitude 179 degrees now, what happens if mingw
can't be effectively (technically/legally) used on Windows? And what's
more probable? There's no clear answer.
Note, I am developing on Linux which objectively is far better
environment for the task. So no matter what compiler I use, this is
mostly a deployment task. Plus maybe making things so beauty that
users of non-free platforms (99.5+% for my market) donate to drive the
open development.

>> I do argue with 'Free software needs to reject nonfree tools even at
>> the cost of alienating most of the non-KDE world'.
>
> I would argue against that. Encouraging Free Software tools even if they are
> not as convenient as proprietary tools is very important. Hell I'm hacking
> together Outlook Addins using free tools because the Idea is that you should
> not rely on proprietary tools to work on / with Free Software.
>
>> Disclaimer: unlike
>> rms I don't have access to secretary who browser the internet for me.
>> And I still use GSM.
>
> What do those two sentences mean? I interpret the first one as a cheap shot
> against Richard Stallman. (Uhh He eats things from his toes!!! Have you
> seen the video?!!)
> I fail to understand the second sentence.

Scary :)
It's a cheap and colorful example of an unrealistic approach of
someone who sometimes forget he's just a human being.  I know I just
won't meet too many contributors if I am suspicious on the first
contact. The second sentence means that we're all (except for rms :))
using closed protocols for vital parts of our lives. BTW, rms isn't
consistent - last time he travelled to Poland via plane full of
closed-source software and even worse hardware. It's his choice but
forcing it on me steals parts of my freedom.

>> It comes down to the question if one acts more inclusive or exclusive.
>>
>> For you: that's like 'reject closed-source drivers for kwin even if I
>> won't be able to use cool kwin features' type of rejection.
>>
>> I wouldn't have problem if presence on github would be completely
>> opt-in as Friedrich suggested, based on subprojects' requests. It
>> would also help to sort out the issue with some obsolete repos.
>> Yesterday just dying in project.kde.org playgrounds and today
>> everything is mirrored on github. Or is it too late?
>
> No I don't think that is the point. For me it is more like "Do we start to
> accept patches that are created by this proprietary tool and review them using
> this same tool?"

I did not say that. It's not even similar. Read this as opt-in. You
don't get these notifications in projects where I am the maintainer.

Patches are created by like-minded individuals in their brilliant
minds. How they are encoded, transmitted and visualised does not
matter. They can come to me by email and land in proprietary inbox
that I read with the help of my properietary x86 CPU. So what.

> It's like asking me to install Visual Studio to review and accept patches. No
> I will not do this  (Yeah github is a webapp but the principle still
> applies imo)

I did not say that. It's not even similar.

There people willing to help with a simple thing of pasting a patch
into phabricator.
Writing a patch is quite more expensive so if it lands anywhere I'll
travel there to grab it and say thank you.

Your experience may differ and I value that. Opt-in - nobody forces you.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, 

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

[Vishesh Handa]

On Fri, Sep 18, 2015 at 9:05 PM, Jaroslaw Staniek  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

[Jaroslaw Staniek]

On 18 September 2015 at 13:42, Boudhayan Gupta  wrote:
> Ladies and gentlemen, as you read this mail github.com/kde is being
> populated by the initial sync of all repositories.
>
> Maybe someone should make a public announcement?
>
> Shout out to Ben, he truly is a superhero.

Thanks a lot!
Is it possible to enable Issues support for a given project? (as I
said needed by the bountysource infra at least)



>
> On 17 September 2015 at 20:00, David Edmundson
>  wrote:
>>
>>
>> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth  wrote:
>>>
>>> Hm I have an existing github mirror with some stars. Instead of
>>> creating a new mirror I'd prefer to just set KDE to the new owner of
>>> the Project.
>>> I guess this is not the only project where that kind of migration is
>>> preferable.
>>> So what to do for those projects?
>>>
>>
>> We would need to add you as an admin member of the github KDE group, then
>> you click "Transfer ownership" in the repo settings.
>> Stars and forks migrate (I tested this just now).
>>
>> Providing the repo names match KDE, the script we have shouldn't create a
>> new repo but will just push into this one.
>>
>> More info at: https://help.github.com/articles/transferring-a-repository/
>>
>> David
>>
>>
>> ___
>> 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



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

[Ben Cooksley]

On Fri, Sep 18, 2015 at 11:42 PM, Boudhayan Gupta  wrote:
> Ladies and gentlemen, as you read this mail github.com/kde is being
> populated by the initial sync of all repositories.
>
> Maybe someone should make a public announcement?
>
> Shout out to Ben, he truly is a superhero.

Credit belongs mostly to you and David, for writing the code and
getting ownership of github.com/kde/ for us :)
I just deployed it...

Cheers,
Ben

>
> On 17 September 2015 at 20:00, David Edmundson
>  wrote:
>>
>>
>> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth  wrote:
>>>
>>> Hm I have an existing github mirror with some stars. Instead of
>>> creating a new mirror I'd prefer to just set KDE to the new owner of
>>> the Project.
>>> I guess this is not the only project where that kind of migration is
>>> preferable.
>>> So what to do for those projects?
>>>
>>
>> We would need to add you as an admin member of the github KDE group, then
>> you click "Transfer ownership" in the repo settings.
>> Stars and forks migrate (I tested this just now).
>>
>> Providing the repo names match KDE, the script we have shouldn't create a
>> new repo but will just push into this one.
>>
>> More info at: https://help.github.com/articles/transferring-a-repository/
>>
>> David
>>
>>
>> ___
>> 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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Ben Cooksley]

On Sat, Sep 19, 2015 at 12:14 AM, Jaroslaw Staniek  wrote:
> On 18 September 2015 at 14:00, Ben Cooksley  wrote:
>> On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek  wrote:
>>> On 18 September 2015 at 13:42, Boudhayan Gupta  wrote:
 Ladies and gentlemen, as you read this mail github.com/kde is being
 populated by the initial sync of all repositories.

 Maybe someone should make a public announcement?

 Shout out to Ben, he truly is a superhero.
>>>
>>> Thanks a lot!
>>> Is it possible to enable Issues support for a given project? (as I
>>> said needed by the bountysource infra at least)
>>
>> From what I saw of the above consensus, issues and pull requests would
>> be disabled as those should go through our usual infrastructure
>> (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
>> post otherwise i'd be happy to be pointed to it though?
>
> I see what you mean but there was no discussion about this matter in
> this thread at least.
>
> For code I maintain I welcome:
> - any form of patches even if they come via pull requests, just like
> for me emailed patches are also better than no patches
> - any form of donations for features -> for that Issues are needed
>
> It's possible to fork these mirrors to get this support and I am doing
> this now for a test in case of kreport.git.
> https://github.com/staniek/kreport-1
>
> But again, please consider this as less controlled/predictable
> activity - that forking will happen anyway, as this is the value of
> github-based collaboration, and (IMHO) sense of our existence on
> github.

The decision isn't mine, it's the community's decision. I've already
added a note suggesting people submit patches on Reviewboard.
For a decision on those two points, i'd welcome pointers to where that
was made in the above thread - or the opening of a new thread on those
topics.

Regards,
Ben

>
>>>

 On 17 September 2015 at 20:00, David Edmundson
  wrote:
>
>
> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth  wrote:
>>
>> Hm I have an existing github mirror with some stars. Instead of
>> creating a new mirror I'd prefer to just set KDE to the new owner of
>> the Project.
>> I guess this is not the only project where that kind of migration is
>> preferable.
>> So what to do for those projects?
>>
>
> We would need to add you as an admin member of the github KDE group, then
> you click "Transfer ownership" in the repo settings.
> Stars and forks migrate (I tested this just now).
>
> Providing the repo names match KDE, the script we have shouldn't create a
> new repo but will just push into this one.
>
> More info at: https://help.github.com/articles/transferring-a-repository/
>
> David
>
>
> ___
> 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
>>>
>>>
>>>
>>> --
>>> 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
>> ___
>> 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
___
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]

Ladies and gentlemen, as you read this mail github.com/kde is being
populated by the initial sync of all repositories.

Maybe someone should make a public announcement?

Shout out to Ben, he truly is a superhero.

On 17 September 2015 at 20:00, David Edmundson
 wrote:
>
>
> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth  wrote:
>>
>> Hm I have an existing github mirror with some stars. Instead of
>> creating a new mirror I'd prefer to just set KDE to the new owner of
>> the Project.
>> I guess this is not the only project where that kind of migration is
>> preferable.
>> So what to do for those projects?
>>
>
> We would need to add you as an admin member of the github KDE group, then
> you click "Transfer ownership" in the repo settings.
> Stars and forks migrate (I tested this just now).
>
> Providing the repo names match KDE, the script we have shouldn't create a
> new repo but will just push into this one.
>
> More info at: https://help.github.com/articles/transferring-a-repository/
>
> David
>
>
> ___
> 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

[Ben Cooksley]

On Sat, Sep 19, 2015 at 12:50 AM, Myriam Schweingruber  wrote:
> Hi all,

Hi Myriam,

>
> On Fri, Sep 18, 2015 at 1:42 PM, Boudhayan Gupta  wrote:
>> Ladies and gentlemen, as you read this mail github.com/kde is being
>> populated by the initial sync of all repositories.
>>
>> Maybe someone should make a public announcement?
>>
>> Shout out to Ben, he truly is a superhero.
>
> I see quite a few things showing up there that I doubt are useful to
> mirror, as the development of those parts is dead since quite some
> time. Examples: various koffice-* parts and phonon-xine. Not sure this
> is in our interest...

The script is simply transferring a copy of all our mainline
repositories to Github. As the list is sorted by activity I believe,
our regular repositories should rise to the top once the initial
population has completed. It also indicates that we have plenty of
repos which should be cleaned up...

>
> Regards, Myriam

Cheers,
Ben

>
> --
> 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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[David Edmundson]

On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin 
wrote:

> On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:
> > On 18 September 2015 at 14:00, Ben Cooksley  wrote:
> > > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek 
> wrote:
> > >> On 18 September 2015 at 13:42, Boudhayan Gupta 
> wrote:
> > >>> Ladies and gentlemen, as you read this mail github.com/kde is being
> > >>> populated by the initial sync of all repositories.
> > >>>
> > >>> Maybe someone should make a public announcement?
> > >>>
> > >>> Shout out to Ben, he truly is a superhero.
> > >>
> > >> Thanks a lot!
> > >> Is it possible to enable Issues support for a given project? (as I
> > >> said needed by the bountysource infra at least)
> > >
> > > From what I saw of the above consensus, issues and pull requests would
> > > be disabled as those should go through our usual infrastructure
> > > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> > > post otherwise i'd be happy to be pointed to it though?
> >
> > I see what you mean but there was no discussion about this matter in
> > this thread at least.
> >
> > For code I maintain I welcome:
> > - any form of patches even if they come via pull requests, just like
> > for me emailed patches are also better than no patches
> > - any form of donations for features -> for that Issues are needed
> >
> > It's possible to fork these mirrors to get this support and I am doing
> > this now for a test in case of kreport.git.
> > https://github.com/staniek/kreport-1
> >
> > But again, please consider this as less controlled/predictable
> > activity - that forking will happen anyway, as this is the value of
> > github-based collaboration, and (IMHO) sense of our existence on
> > github.
>
> Issues can are disabled

Pull requests we can't disable.
However I've found this bot: http://nopullrequests.com/

that gets pull requests then automatically repsonds closing it.
Might be worth us doing, saying "go to reviewboard.kde.org"

Just as a reminder



> We must be extremely careful to not proprietarize our development
> infrastructure. Accepting the one pull request is no problem, but once all
> development happens through pull request, we have moved our development
> infrastructure to a proprietary platform and run in a vendor-lock-in
> situation.
>
> If you want to accept pull requests think about what it means. This is
> quite
> different to mail: mail is not a single vendor lock-in and also not
> proprietary.
>
> My suggestion is that it's ok to accept pull request from new contributors,
> but at the same time tell them how to contribute in future. That it's an
> exception and not the rule.
>
> I also suggest that we update our README(.md) files and point out how to
> contribute.
>
> Cheers
> Martin
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>


On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin 
wrote:

> On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:
> > On 18 September 2015 at 14:00, Ben Cooksley  wrote:
> > > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek 
> wrote:
> > >> On 18 September 2015 at 13:42, Boudhayan Gupta 
> wrote:
> > >>> Ladies and gentlemen, as you read this mail github.com/kde is being
> > >>> populated by the initial sync of all repositories.
> > >>>
> > >>> Maybe someone should make a public announcement?
> > >>>
> > >>> Shout out to Ben, he truly is a superhero.
> > >>
> > >> Thanks a lot!
> > >> Is it possible to enable Issues support for a given project? (as I
> > >> said needed by the bountysource infra at least)
> > >
> > > From what I saw of the above consensus, issues and pull requests would
> > > be disabled as those should go through our usual infrastructure
> > > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> > > post otherwise i'd be happy to be pointed to it though?
> >
> > I see what you mean but there was no discussion about this matter in
> > this thread at least.
> >
> > For code I maintain I welcome:
> > - any form of patches even if they come via pull requests, just like
> > for me emailed patches are also better than no patches
> > - any form of donations for features -> for that Issues are needed
> >
> > It's possible to fork these mirrors to get this support and I am doing
> > this now for a test in case of kreport.git.
> > https://github.com/staniek/kreport-1
> >
> > But again, please consider this as less controlled/predictable
> > activity - that forking will happen anyway, as this is the value of
> > github-based collaboration, and (IMHO) sense of our existence on
> > github.
>
> We must be extremely careful to not proprietarize our development
> infrastructure. Accepting the one pull request is no problem, but 

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

[Jaroslaw Staniek]

On 18 September 2015 at 14:00, Ben Cooksley  wrote:
> On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek  wrote:
>> On 18 September 2015 at 13:42, Boudhayan Gupta  wrote:
>>> Ladies and gentlemen, as you read this mail github.com/kde is being
>>> populated by the initial sync of all repositories.
>>>
>>> Maybe someone should make a public announcement?
>>>
>>> Shout out to Ben, he truly is a superhero.
>>
>> Thanks a lot!
>> Is it possible to enable Issues support for a given project? (as I
>> said needed by the bountysource infra at least)
>
> From what I saw of the above consensus, issues and pull requests would
> be disabled as those should go through our usual infrastructure
> (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> post otherwise i'd be happy to be pointed to it though?

I see what you mean but there was no discussion about this matter in
this thread at least.

For code I maintain I welcome:
- any form of patches even if they come via pull requests, just like
for me emailed patches are also better than no patches
- any form of donations for features -> for that Issues are needed

It's possible to fork these mirrors to get this support and I am doing
this now for a test in case of kreport.git.
https://github.com/staniek/kreport-1

But again, please consider this as less controlled/predictable
activity - that forking will happen anyway, as this is the value of
github-based collaboration, and (IMHO) sense of our existence on
github.

>>
>>>
>>> On 17 September 2015 at 20:00, David Edmundson
>>>  wrote:


 On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth  wrote:
>
> Hm I have an existing github mirror with some stars. Instead of
> creating a new mirror I'd prefer to just set KDE to the new owner of
> the Project.
> I guess this is not the only project where that kind of migration is
> preferable.
> So what to do for those projects?
>

 We would need to add you as an admin member of the github KDE group, then
 you click "Transfer ownership" in the repo settings.
 Stars and forks migrate (I tested this just now).

 Providing the repo names match KDE, the script we have shouldn't create a
 new repo but will just push into this one.

 More info at: https://help.github.com/articles/transferring-a-repository/

 David


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

[Thomas Baumgart]

Hi,

On Friday 18 September 2015 17:12:12 Boudhayan Gupta wrote:

> Ladies and gentlemen, as you read this mail github.com/kde is being
> populated by the initial sync of all repositories.
> 
> Maybe someone should make a public announcement?
> 
> Shout out to Ben, he truly is a superhero.

Thanks Ben, you rock!

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-
I used to be a hypochondriac AND a kleptomaniac. So I took something for it.
-


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

[Martin Graesslin]

On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:
> On 18 September 2015 at 14:00, Ben Cooksley  wrote:
> > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek  
wrote:
> >> On 18 September 2015 at 13:42, Boudhayan Gupta  wrote:
> >>> Ladies and gentlemen, as you read this mail github.com/kde is being
> >>> populated by the initial sync of all repositories.
> >>> 
> >>> Maybe someone should make a public announcement?
> >>> 
> >>> Shout out to Ben, he truly is a superhero.
> >> 
> >> Thanks a lot!
> >> Is it possible to enable Issues support for a given project? (as I
> >> said needed by the bountysource infra at least)
> > 
> > From what I saw of the above consensus, issues and pull requests would
> > be disabled as those should go through our usual infrastructure
> > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> > post otherwise i'd be happy to be pointed to it though?
> 
> I see what you mean but there was no discussion about this matter in
> this thread at least.
> 
> For code I maintain I welcome:
> - any form of patches even if they come via pull requests, just like
> for me emailed patches are also better than no patches
> - any form of donations for features -> for that Issues are needed
> 
> It's possible to fork these mirrors to get this support and I am doing
> this now for a test in case of kreport.git.
> https://github.com/staniek/kreport-1
> 
> But again, please consider this as less controlled/predictable
> activity - that forking will happen anyway, as this is the value of
> github-based collaboration, and (IMHO) sense of our existence on
> github.

We must be extremely careful to not proprietarize our development 
infrastructure. Accepting the one pull request is no problem, but once all 
development happens through pull request, we have moved our development 
infrastructure to a proprietary platform and run in a vendor-lock-in 
situation.

If you want to accept pull requests think about what it means. This is quite 
different to mail: mail is not a single vendor lock-in and also not 
proprietary.

My suggestion is that it's ok to accept pull request from new contributors, 
but at the same time tell them how to contribute in future. That it's an 
exception and not the rule.

I also suggest that we update our README(.md) files and point out how to 
contribute.

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

[Martin Graesslin]

On Friday, September 18, 2015 1:53:36 PM CEST David Edmundson wrote:
> On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin 
> 
> wrote:
> > On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:
> > > On 18 September 2015 at 14:00, Ben Cooksley  wrote:
> > > > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek 
> > 
> > wrote:
> > > >> On 18 September 2015 at 13:42, Boudhayan Gupta 
> > 
> > wrote:
> > > >>> Ladies and gentlemen, as you read this mail github.com/kde is being
> > > >>> populated by the initial sync of all repositories.
> > > >>> 
> > > >>> Maybe someone should make a public announcement?
> > > >>> 
> > > >>> Shout out to Ben, he truly is a superhero.
> > > >> 
> > > >> Thanks a lot!
> > > >> Is it possible to enable Issues support for a given project? (as I
> > > >> said needed by the bountysource infra at least)
> > > > 
> > > > From what I saw of the above consensus, issues and pull requests would
> > > > be disabled as those should go through our usual infrastructure
> > > > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> > > > post otherwise i'd be happy to be pointed to it though?
> > > 
> > > I see what you mean but there was no discussion about this matter in
> > > this thread at least.
> > > 
> > > For code I maintain I welcome:
> > > - any form of patches even if they come via pull requests, just like
> > > for me emailed patches are also better than no patches
> > > - any form of donations for features -> for that Issues are needed
> > > 
> > > It's possible to fork these mirrors to get this support and I am doing
> > > this now for a test in case of kreport.git.
> > > https://github.com/staniek/kreport-1
> > > 
> > > But again, please consider this as less controlled/predictable
> > > activity - that forking will happen anyway, as this is the value of
> > > github-based collaboration, and (IMHO) sense of our existence on
> > > github.
> > 
> > Issues can are disabled
> 
> Pull requests we can't disable.
> However I've found this bot: http://nopullrequests.com/
> 
> that gets pull requests then automatically repsonds closing it.
> Might be worth us doing, saying "go to reviewboard.kde.org"

Oh I think we should add that bot. I thought pull-requests are disabled by 
default. I certainly don't want to check all the repos I maintain for pull-
requests.

Cheers
Martin

> 
> Just as a reminder
> 
> > We must be extremely careful to not proprietarize our development
> > infrastructure. Accepting the one pull request is no problem, but once all
> > development happens through pull request, we have moved our development
> > infrastructure to a proprietary platform and run in a vendor-lock-in
> > situation.
> > 
> > If you want to accept pull requests think about what it means. This is
> > quite
> > different to mail: mail is not a single vendor lock-in and also not
> > proprietary.
> > 
> > My suggestion is that it's ok to accept pull request from new
> > contributors,
> > but at the same time tell them how to contribute in future. That it's an
> > exception and not the rule.
> > 
> > I also suggest that we update our README(.md) files and point out how to
> > contribute.
> > 
> > Cheers
> > Martin
> > ___
> > kde-community mailing list
> > kde-community@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-community
> 
> On Fri, Sep 18, 2015 at 1:41 PM, Martin Graesslin 
> 
> wrote:
> > On Friday, September 18, 2015 2:14:00 PM CEST Jaroslaw Staniek wrote:
> > > On 18 September 2015 at 14:00, Ben Cooksley  wrote:
> > > > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek 
> > 
> > wrote:
> > > >> On 18 September 2015 at 13:42, Boudhayan Gupta 
> > 
> > wrote:
> > > >>> Ladies and gentlemen, as you read this mail github.com/kde is being
> > > >>> populated by the initial sync of all repositories.
> > > >>> 
> > > >>> Maybe someone should make a public announcement?
> > > >>> 
> > > >>> Shout out to Ben, he truly is a superhero.
> > > >> 
> > > >> Thanks a lot!
> > > >> Is it possible to enable Issues support for a given project? (as I
> > > >> said needed by the bountysource infra at least)
> > > > 
> > > > From what I saw of the above consensus, issues and pull requests would
> > > > be disabled as those should go through our usual infrastructure
> > > > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a
> > > > post otherwise i'd be happy to be pointed to it though?
> > > 
> > > I see what you mean but there was no discussion about this matter in
> > > this thread at least.
> > > 
> > > For code I maintain I welcome:
> > > - any form of patches even if they come via pull requests, just like
> > > for me emailed patches are also better than no patches
> > > - any form of donations for features -> for that Issues are needed
> > > 
> > > It's possible to 

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

[Sune Vuorela]

On 2015-09-18, Jaroslaw Staniek  wrote:
> Don't we slowly drop support for Reviewboard?
> (even I am still not sure how to correctly update phabricator diff
> from command line)

Then notes should be changed when we move from reviewboard to 

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

Yes. I'm against. And I'm also against mirroring on github, but I didn't
voice my opinion by that because it was said that issues and pull
requests are not to be enabled.

We should not proprietarize our development workflow. We should not work
towards anything that locks us in anywhere. 

Free software needs free tools.

And the BDSM Free Software Definition:
"I refuse to be bound by software I cannot negotiate with".

/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

[David Edmundson]

On Thu, Sep 17, 2015 at 10:03 AM, Ben Cooksley  wrote:

> On Thu, Sep 17, 2015 at 12:57 AM, David Edmundson
>  wrote:
> > I am great.
> >
> > https://github.com/kde is now ours.
>
> Well done, that was quick. Anyone volunteers to write the script which
> mirrors the repositories up to Github?
> For now, let's not worry about cleaning up destroyed repositories...
>
>
Done.
https://paste.kde.org/p3nmyfp1e

Gnome were kind enought to leave their script public, so I just did
s/gnome/kde.

Only thing I'm missing is automatically filling in the descriptions.

Means we'll push only mirror to github as and when someone makes a commit
to each repo, but that should be enough.

David


> >
> > David
>
> Cheers,
> Ben
>
> >
> > ___
> > 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
>
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Ben Cooksley]

On Thu, Sep 17, 2015 at 12:57 AM, David Edmundson
 wrote:
> I am great.
>
> https://github.com/kde is now ours.

Well done, that was quick. Anyone volunteers to write the script which
mirrors the repositories up to Github?
For now, let's not worry about cleaning up destroyed repositories...

>
> David

Cheers,
Ben

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

[Boudhayan Gupta]

On 16 September 2015 at 12:04, Ben Cooksley  wrote:
> Nobody from the Sysadmin team has time to work on this at the moment,
> so it'll get worked on as part of the Phabricator migration as we have
> to overhaul the Anongit system then anyway. If anyone wants to work on
> it before then, please contact me.

I was just going to go ahead and create an organization before anyone
else took github.com/kde, but apparently it's been taken since Feb 10,
2009.

Any other ideas?

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

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

[Ben Cooksley]

On Wed, Sep 16, 2015 at 6:01 PM, Martin Graesslin  wrote:
> On Tuesday, September 15, 2015 11:21:34 PM CEST Vishesh Handa wrote:
>> 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.

Nobody from the Sysadmin team has time to work on this at the moment,
so it'll get worked on as part of the Phabricator migration as we have
to overhaul the Anongit system then anyway. If anyone wants to work on
it before then, please contact me. It should be fairly simple to use
the Github API to create / delete repositories as need be, and then
hook into our existing mirroring infrastructure to push the latest
state of the repository when a developer pushes to it.

>
> There seems to be consensus on we want it, but nobody started to do work on
> it. Maybe you want to get it going? Instead of doing "KDE Baloo" taking "KDE
> community" (or something like that)?
>
> Cheers
> Martin

Regards,
Ben

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

On Tuesday, September 15, 2015 11:21:34 PM CEST Vishesh Handa wrote:
> 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.

There seems to be consensus on we want it, but nobody started to do work on 
it. Maybe you want to get it going? Instead of doing "KDE Baloo" taking "KDE 
community" (or something like 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] Official KDE mirror on github

[Boudhayan Gupta]

On 16 September 2015 at 13:25, Boudhayan Gupta  wrote:
> Hi,
>
> On 16 September 2015 at 13:05, Ben Cooksley  wrote:
>> If someone would like to reach out to the person nicely, that would be
>> appreciated and would help things move along.
>
> I'll try to get in touch. I grabbed github.com/kde-mirror, just in case.
>
> -- BG

No joy. The profile has no contact information, and I've been unable
to get an e-mail address from even api.github.com.

The profile has no repos or code contribution, in fact the only
activity is that it has starred one repository.

Are we sure it's not one of us who's kept this profile so that no one
else can grab it?
___
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]

It's fairly inactive and github doesn't allow name squatting. Someone
should make a request to reclaim it on behalf of KDE. (Maybe e.V ?)

L

Loïc Grobol
On 16 Sep 2015 08:42, "Boudhayan Gupta"  wrote:

> On 16 September 2015 at 12:04, Ben Cooksley  wrote:
> > Nobody from the Sysadmin team has time to work on this at the moment,
> > so it'll get worked on as part of the Phabricator migration as we have
> > to overhaul the Anongit system then anyway. If anyone wants to work on
> > it before then, please contact me.
>
> I was just going to go ahead and create an organization before anyone
> else took github.com/kde, but apparently it's been taken since Feb 10,
> 2009.
>
> Any other ideas?
>
> -- Boudhayan
> ___
> 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

[Ivan Čukić]

> That was why I suggested reaching out to GitHub instead of the user :)

+1

Even if the account was active, it is still our TM.

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

[Ben Cooksley]

On Wed, Sep 16, 2015 at 6:51 PM, Loïc Grobol  wrote:
> It's fairly inactive and github doesn't allow name squatting. Someone should
> make a request to reclaim it on behalf of KDE. (Maybe e.V ?)

If someone would like to reach out to the person nicely, that would be
appreciated and would help things move along.

>
> L
>
> Loïc Grobol

Cheers,
Ben

>
> On 16 Sep 2015 08:42, "Boudhayan Gupta"  wrote:
>>
>> On 16 September 2015 at 12:04, Ben Cooksley  wrote:
>> > Nobody from the Sysadmin team has time to work on this at the moment,
>> > so it'll get worked on as part of the Phabricator migration as we have
>> > to overhaul the Anongit system then anyway. If anyone wants to work on
>> > it before then, please contact me.
>>
>> I was just going to go ahead and create an organization before anyone
>> else took github.com/kde, but apparently it's been taken since Feb 10,
>> 2009.
>>
>> Any other ideas?
>>
>> -- Boudhayan
>> ___
>> 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
___
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]

On 16 September 2015 at 10:06, Boudhayan Gupta  wrote:
> No joy. The profile has no contact information,

That was why I suggested reaching out to GitHub instead of the user :)

L

Loïc Grobol.
___
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,

On 16 September 2015 at 13:05, Ben Cooksley  wrote:
> If someone would like to reach out to the person nicely, that would be
> appreciated and would help things move along.

I'll try to get in touch. I grabbed github.com/kde-mirror, just in case.

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

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

[Ben Cooksley]

On Wed, Sep 16, 2015 at 8:32 PM, Ivan Čukić  wrote:
>> That was why I suggested reaching out to GitHub instead of the user :)
>
> +1
>
> Even if the account was active, it is still our TM.

I was trying to avoid using that club :)
Could someone start a dialogue with Github to recover the account?

>
> Cheers,
> Ivan

Thanks,
Ben

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

[Jonathan Riddell]

On Wed, Sep 16, 2015 at 05:25:29PM +0530, Boudhayan Gupta wrote:
> On 16 September 2015 at 14:09, Ben Cooksley  wrote:
> > I was trying to avoid using that club :)
> > Could someone start a dialogue with Github to recover the account?
> 
> I think it's best that someone from eV do this.

Mike is a KDE friendly type who's sorted out similar problems for me in the 
past at github.
http://mikemcquaid.com/

sorry I've no energy to take this up

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

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

[David Edmundson]

I am great.

https://github.com/kde is now ours.

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

[Stefan Derkits]

Hi,

On 2015-09-16 14:57, David Edmundson wrote:
> https://github.com/kde is now ours.

yay & thanks :)

Stefan



signature.asc
Description: OpenPGP digital signature
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Mirko Boehm]

Hehe, 

> On 16 Sep 2015, at 14:57, David Edmundson  wrote:
> 
> I am great.
> 
> https://github.com/kde  is now ours.

Nice work, David. 

Mirko.
-- 
Mirko Boehm | mi...@kde.org | KDE e.V.
FSFE Fellow, FSFE Team Germany
Qt Certified Specialist
Request a meeting: https://doodle.com/mirkoboehm



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

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

[Thiago Macieira]

On Wednesday 16 September 2015 13:57:37 David Edmundson wrote:
> I am great.
> 
> https://github.com/kde is now ours.

Awesome! You are indeed great!

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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