date:20150131


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122320/#review75114
---


Looks ok from here.
Martin may be able to tell whether checking whether the platform is xcb can 
save you tiem over a failed attempt to create an xcb connection.

If you picked the connection validity from some real life code or a public 
tutorial, I suggest to inform the author.

- Thomas Lübking


On Jan. 31, 2015, 11:07 nachm., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122320/
> ---
> 
> (Updated Jan. 31, 2015, 11:07 nachm.)
> 
> 
> Review request for kde-workspace, Martin Gräßlin and Thomas Lübking.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> this patch makes kcminit behave like in kde4: it uses proper xcb screen count 
> which may be different from QGuiApplication::screens().count().
> 
> for example when i connext external monitor via vga to my laptop, xcb screen 
> count is still '1', while QGuiApplication::screens().count() returns '2'.
> 
> switching from QGuiApplication to QCoreApplication still wasn't possible 
> because modules like 'mouse' need gui initialized and would crash if kcminit 
> uses QCoreApplication.
> 
> 
> Diffs
> -
> 
>   startkde/kcminit/CMakeLists.txt b17951f 
>   startkde/kcminit/main.cpp 1008966 
> 
> Diff: https://git.reviewboard.kde.org/r/122320/diff/
> 
> 
> Testing
> ---
> 
> i have built kcminit on ubuntu vivid alpha 32-bit, replaced binaries and 
> libraries in the system and successfuly could run kcminit_startup and reboot 
> also went fine.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

Re: Another proposal for modernization of our infrastructure

On Saturday, January 31, 2015 22:41:36 Jan Kundrát wrote:
> On Saturday, 31 January 2015 21:38:23 CEST, Inge Wallin wrote:
> > It is one thing if there is one tool that is totally too weak to work for
> > experienced people and one tool that is awesome but very
> > difficult to learn.
> > But that's not the situation we have here.  I think we have one
> > tool that is
> > very good and then one that many have pointed out as cumbersome
> > and difficult to
> > learn for not very experienced people - but - with an edge when it comes
> > to
> > advanced git users.
> 
> I am a bit surprised to read that Phabricator is apparently considered
> "very good" even though no KDE project has tried it yet. I was under the
> impression that the usual order of steps is:

This is true. It's not proven yet.  What I described above was my impression 
taken from the comments by the people who did try it in other situations.  The 
real status has to be determined by tests.  So let me add a "supposedly" to 
the sentence above.

No decision should be made without real tests, of course.

> 1) install a tool,
> 2) play with it,
> 3) identify its strenghts and weeknesses,
> 4) make an informed opinion.
> 
> Did I miss something? Which KDE project has been testing Phabricator?
> 
> > I know how long it took for me to get used ot git, and I think I'm pretty
> > experienced. Adding to that burden is not the way to get new people.
> 
> I'll repeat my request from earlier in this thread -- please quantify the
> expected increase of the barrier to entry. "Different" does not imply
> "harder".

It does, actually.  Not forever, of course, but the very fact that something 
is different than what you know before makes it more difficult to learn. But 
you 
knew that already, so I wonder why you were saying the above. And also, 
different from what? I bet that both Gerrit and Phabricator are quite different 
than Reviewboard.

But that aside, I am a bit surprised by your request to "quantify difficulty". 
What unit do you want it in? Brain-hours? Headaches? I would be interested in 
your own opinion about a quantified measure of difficulty to learn and use 
Gerrit 
compared to Phabricator.  Or if you are unfamiliar with Phabricator, then the 
quantified measure of difficulty for Gerrit is enough.

Anyway, I'll let it rest from here on.  I suppose that the real tests will 
show us which tool is the best, and which weaknesses and strength they have.

Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support

2015-01-31 Thread David Narváez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122341/
---

(Updated Jan. 31, 2015, 11:07 p.m.)


Review request for kde-workspace, Bhushan Shah and David Faure.


Changes
---

Removed commented code from the diff


Repository: kio-extras


Description
---

Only major difference would be the lack of fallback to KFMI. Maybe we could 
implement thumbnail features in KFileMetadata?


Diffs (updated)
-

  thumbnail/thumbnail.cpp 39e8de5 

Diff: https://git.reviewboard.kde.org/r/122341/diff/


Testing
---

Only tested compilation.


Thanks,

David Narváez

Re: Review Request 122320: use xcb-screen count instead of qguiapplication.screens

2015-01-31 Thread Nick Shaforostoff


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122320/
---

(Updated Jan. 31, 2015, 11:07 p.m.)


Review request for kde-workspace, Martin Gräßlin and Thomas Lübking.


Changes
---

added xcb_connection_has_error() check


Repository: plasma-workspace


Description
---

this patch makes kcminit behave like in kde4: it uses proper xcb screen count 
which may be different from QGuiApplication::screens().count().

for example when i connext external monitor via vga to my laptop, xcb screen 
count is still '1', while QGuiApplication::screens().count() returns '2'.

switching from QGuiApplication to QCoreApplication still wasn't possible 
because modules like 'mouse' need gui initialized and would crash if kcminit 
uses QCoreApplication.


Diffs (updated)
-

  startkde/kcminit/CMakeLists.txt b17951f 
  startkde/kcminit/main.cpp 1008966 

Diff: https://git.reviewboard.kde.org/r/122320/diff/


Testing
---

i have built kcminit on ubuntu vivid alpha 32-bit, replaced binaries and 
libraries in the system and successfuly could run kcminit_startup and reboot 
also went fine.


Thanks,

Nick Shaforostoff

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Alexander Neundorf

On Saturday, January 31, 2015 22:52:22 Andreas Pakulat wrote:
> Hi,
> 
> just a short note (don't want this to become a complete subthread
> distracting from the actual proposal-discussion)
> 
> On Sat, Jan 31, 2015 at 9:38 PM, Alexander Neundorf 
> 
> wrote:
> >  that KDE still couldn't agree even on a set of git workflows to use, the
> > 
> > wiki page still just lists a few proposed drafts. :-/
> 
> I think thats actually a good thing and would just not work for 'KDE' (i.e.
> the whole community with all projects). KDE is just to big and diverse to
> impose one particular git workflow onto all its projects, in particular
> since some of them also impose certain release management. Different
> projects move at different paces, they have different needs for their
> release management and the maintainers actually doing the work may have
> differing opinions or even just time.

Even if it should not be possible to agree on ONE workflow, maybe it should be 
possible to agree on two or three (e.g. everything in master, or everything in 
feature branches, and maybe a third one) standard workflows, and document them 
properly. Then every project could simply state "we are using workflow (A|B|
C)" and things would be clear. It wouldn't be too much IMO to make it 
mandatory for "KDE" projects to use one of two/three official KDE git 
workflows.

Alex

Re: Another proposal for modernization of our infrastructure


On Thursday, 29 January 2015 19:31:20 CEST, Eike Hein wrote:

Just for the record: I consider you a KDE sysadmin (you're
administrating infra used by KDE, after all), so I meant the
"kde.org" more general. Thanks.


I forgot about this mail, and I realize that I am not sure whether my reply 
was clear or if it left some space for a possible misunderstanding. Sorry 
for noise if we already understood each other.


The following KDE people have root there:
- Ben Cooksley
- Frederik Gladhorn
- Victor Blazques

If there are others who need access, there's no problem adding them. The 
KDE server holding the PostgreSQL backups is tesla.kde.org.


--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Samstag, 31. Januar 2015 22:41:36 CEST, Jan Kundrát wrote:

Maybe the newcomers just do not care whether they're learning 
about Phabricator, Reviewboard or Gerrit.


Since it's always better to waste CPU time than to waste my time, we could btw. 
also provide a bash script that does all the required stuff (incl. the key 
generation and git aliases config) - and regardless of the actual tool in use 
(given Phabricator supports automation through some API for this), since the 
git process requires all that and we probably want to prevent contributors from 
downloading tarball after tarball.

Cheers,
Thomas

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Andreas Pakulat

Hi,

just a short note (don't want this to become a complete subthread
distracting from the actual proposal-discussion)

On Sat, Jan 31, 2015 at 9:38 PM, Alexander Neundorf 
wrote:
>
>  that KDE still couldn't agree even on a set of git workflows to use, the
> wiki page still just lists a few proposed drafts. :-/
>

I think thats actually a good thing and would just not work for 'KDE' (i.e.
the whole community with all projects). KDE is just to big and diverse to
impose one particular git workflow onto all its projects, in particular
since some of them also impose certain release management. Different
projects move at different paces, they have different needs for their
release management and the maintainers actually doing the work may have
differing opinions or even just time.

I always found it nice that 'KDE' did not impose too many rules onto its
projects and their developers.

Andreas

Re: Another proposal for modernization of our infrastructure


On Saturday, 31 January 2015 21:38:23 CEST, Inge Wallin wrote:
It is one thing if there is one tool that is totally too weak to work for 
experienced people and one tool that is awesome but very 
difficult to learn.  
But that's not the situation we have here.  I think we have one 
tool that is 
very good and then one that many have pointed out as cumbersome 
and difficult to 
learn for not very experienced people - but - with an edge when it comes to 
advanced git users.


I am a bit surprised to read that Phabricator is apparently considered 
"very good" even though no KDE project has tried it yet. I was under the 
impression that the usual order of steps is:


1) install a tool,
2) play with it,
3) identify its strenghts and weeknesses,
4) make an informed opinion.

Did I miss something? Which KDE project has been testing Phabricator?

I know how long it took for me to get used ot git, and I think I'm pretty 
experienced. Adding to that burden is not the way to get new people.


I'll repeat my request from earlier in this thread -- please quantify the 
expected increase of the barrier to entry. "Different" does not imply 
"harder".


In Trojita, we have GCI students submitting patches wihin 15 minutes, 
following the developer-oriented newbie-unfriendly documentation. 15 
minutes for a high-schooler to start contributing. Translators have sent 
patches via Gerrit as well. Interestingly enough, the only complaint was 
from an experienced KDE developer, not from a newcomer.


Maybe the newcomers just do not care whether they're learning about 
Phabricator, Reviewboard or Gerrit.


Anyway, I don't really see a problem with the following steps:

0) Ignore any documentation, especially the "clone" command which already 
includes getting the hook. I don't read no documentation.

1) git clone ...
2) make changes && make && run
3) git commit -a
4) git push
5) Damn, that stupid Gerrit tells me on a command line that I should push 
to refs/for/master instead of just master. Oh well, stupid crap.

6) git push origin refs/for/master
7) Damn, now that stupid Gerrit tells me that I am supposed to copy-paste 
this line into my terminal for some crazy hook or what not, and to amend my 
commits. Annoying crap!

8) (copy-paste a line from Gerrit's output)
9) git commit --amend
10) git push origin refs/for/master

For those who actually read the documentation, it's of course more 
straighforward, but we all know that nobody reads documentation, hence the 
extra detours.


Besides, it has been already established that there will be support for 
direct patch upload.


It would be very interesting to hear the VDG people's and the 
translators' and documentors' view on this.


Given that the translators still use SVN, I sincerely hope that the 
proposed outcome does not involve us switching back to Subversion, or 
reducing our use of Git to an SVN equivalent.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Saturday, 31 January 2015 22:09:36 CEST, Thomas Lübking wrote:
Aside that this is an exhaustive HowTo on git and gerrit*, 
there're apparently "upload your plain diff" webfrontends.
(Though I think the question was brought up and not answered 
how follow-up patches are handled - eg. whether you've to pass 
some existing gerrit url to fetch the change-id from)


The gerrit-patch-uploader says that you are supposed to copy-paste the 
Change-Id line from e.g. the change page, yes.


Keep in mind that Gerrit 2.11 allows editing your change right from the 
Gerrit's web UI, so there is no need to upload another followup patch for a 
significant chunk of these changes.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Samstag, 31. Januar 2015 21:11:19 CEST, Eike Hein wrote:


ReviewBoard already has some screenshot functio-
nality and we actually have policy in place to require
showing screenshots for review requests that change UI
(i.e. this is something gerrit will actually regress us
on afaics)


I don't have a commit link, but asked Jan that in the context of some trojita 
patch and he promised that the current git version of gerrit already has the 
ability to upload illustrating screenshots.

Cheers,
Thomas

Re: Another proposal for modernization of our infrastructure


On Samstag, 31. Januar 2015 20:37:31 CEST, Christoph Feck wrote:

On Saturday 31 January 2015 20:07:42 Eike Hein wrote:

[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway [...]


Excuse me, but if KDE developers will have to follow equivalent steps 
as described at http://qt-project.org/wiki/Setting-up-Gerrit to 
contribute, then I predict another big loss of developers. 


Aside that this is an exhaustive HowTo on git and gerrit*, there're apparently 
"upload your plain diff" webfrontends.
(Though I think the question was brought up and not answered how follow-up 
patches are handled - eg. whether you've to pass some existing gerrit url to 
fetch the change-id from)


Gerrit is however very git-centric, so if you managed the git challenge, 
there's relly no additional complexity (and that includes things to learn. 
Messy repo/branch setups are messy).
If you however did W!!! GIT!!! (and I was close to that twice or 
thrice when KDE moved svn -> git) - you're indeed lost (resp. have to follow a 
very cumbersome patch upload path that kills all user-side gerrit benefits at once)

Cheers,
Thomas

* Setting up git, with creating an account, uploading a key and configuring git 
certainly /is/ a one-time job you've to fulfill, but it's git, resp. actually 
scm related, not gerrit related.
The only** gerrit overhead here was really to dowload the change-id injecting 
hook.

**Though the demo setup also required to add a second repo, but that's hardly 
the case if gerrit would do the entire scm instead of being replicated to the 
git.kde repo that I originally fetched the code from (and because that's also 
been a clone, I actually have three repos there ;-)

Re: Another proposal for modernization of our infrastructure



... in fact, even if you consider Qt and KDE in symbiosis,
you could say that KDE is the place you can do things that
don't fit the narrower scope of Qt Project, and that calls
for tooling that supports things gerrit doesn't support
well enough. If gerrit is a constraint, then KDE picking
tooling other than gerrit would arguably contribute to the
combined ecosystem by making a resource available that is
otherwise lacking.


Cheers,
Eike

Re: Another proposal for modernization of our infrastructure

On Saturday, January 31, 2015 20:07:42 Eike Hein wrote:
> On 01/31/2015 10:37 AM, Jan Kundrát wrote:

> I'd like to summarize my current feelings on both proposals.
> 
> 
> Here's what I think gerrit's strong points are:
> 
> * There's undeniably synergy and cultural alignment with
>middleware communities we depend on to be had. Qt is
>using gerrit and we intend to remain a major stakeholder
>in Qt development, which means a sizable number of KDE
>developers need to be familiar with gerrit anyway. KDE
>using gerrit lowers the barrier for KDE developers to
>work upstream, and for folks in the wider Qt community
>to involve themselves in KDE. Particularly for Frame-
>works development this could be a boon.

Aside from the point that Christopher made that a too strictly restricted 
workflow will drive developers away, I also think this point is overstressed.  
The problem is not the developers that are good enough to actually contribute 
to Qt.  The problem is the new people that will never stay around if they have 
to too much to learn until they can make their first contribution.

It is one thing if there is one tool that is totally too weak to work for 
experienced people and one tool that is awesome but very difficult to learn.  
But that's not the situation we have here.  I think we have one tool that is 
very good and then one that many have pointed out as cumbersome and difficult 
to 
learn for not very experienced people - but - with an edge when it comes to 
advanced git users.

I know how long it took for me to get used ot git, and I think I'm pretty 
experienced. Adding to that burden is not the way to get new people.

I'd like to liken this with myself as an emacs user.  I have so far not seen 
one feature in any visual development environment that is not also available 
as a plugin feature for emacs. Emacs simply has a superset of all the features 
of all the other integrated devtools out there - but - it does it without 
graphics and with keyboard shortcuts. It's not without reason that emacs has 
sometimes been interpreted as escape-meta-alt-control-shift. :)

Despite all this awesomeness, I have a hard time convincing people to use 
emacs. And why? Because it has a steep learning curve. So if I were to force 
people to use emacs they would run for the hills. I think I could outedit 
almost anybody when it comes to pure editing text files whatever the task.  
This is due to the sheer size of the emacs toolbox coupled with extreme 
versatility of the tools themselves.  

But this is not what makes people productive with development. Editing is but 
one of the many steps we have to do when developing our KDE applications. And 
it's the same way with patch review. Even if a complicated tool would make the 
top people's job easier, the cost to the community would be too great if we 
were to force this tool on everybody. So with the current choices I from now 
on will support Phabricator as the choice of the community.

Caveat:
The above choice is only valid if Phabricator is actually up to the task. I 
guess the tests will tell us this.

> * gerrit and the community around gerrit (which includes
>Jan) appears to have considerable chops when it comes
>to solving hard infrastructure problems like advanced
>CI and replication. This is stuff that can enhance the
>quality of our products by improving our processes,
>but it also stands to make KDE a more attractive envi-
>ronment for incubating new projects. Infrastructure
>should not be the sole platform we run recruitment on,
>but staying competitive is important, and one way to
>do that is to try and lift things only a community of
>KDE's size can lift -- and that can e.g. include
>gathering donations for fancy CI cluster setups. 

...provided we will have any new people that can execute those processes.  :)
I'm still unconvinced that gerrit is the tool to grow our community.

> Here's what I think Phabricator's strong point is:
> 
> * From what I've seen and played with so far, I really
>like the UI. This is a short bullet, but an important
>one.
> 
> * In terms of cultural alignment, I see communities like
>Blender and Wikimedia pick Phabricator. Lowering the
>barrier for cross-pollination with communities like
>this seems very attractive to me, because there's
>types of talent engaged in those communities that we
>need more of in KDE, e.g. designers and artists.

This is a good point that I actually didn't consider before.  How does e.g. 
the Visual Design Group Work with review? Do they? And if not, would they if 
they had the proper tools?  And how do Gerrit and Phabricator stack up here?

> * I expect the above drivers to make it more likely that
>Phabricator will develop functionality that will make
>it more useful for these types of contributors. For
>example, good diff viewers for visual assets, good
>handling of screenshot

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Alexander Neundorf

On Saturday, January 31, 2015 21:11:19 Eike Hein wrote:
> On 01/31/2015 08:57 PM, Alexander Neundorf wrote:
> > hmm, looking back at our switch to git, I don't consider our standards for
> > documentation of the developer workflow as very high unfortunately. :-/
> 
> Considering I wrote the majority of
> https://community.kde.org/Sysadmin/GitKdeOrgManual I guess I'll have to
> take that to heart, then ...

this page is the best we have for git, it contains a lot, but also things 
which I as a developer who just wants to contribute to some project, am not 
interested in, e.g. "Commands related to repository importing", "Commands for 
system adminisitrators", "Commands to manage personal repositories" and more.

I was more referring to this one: https://techbase.kde.org/Development/Git , 
and that KDE still couldn't agree even on a set of git workflows to use, the 
wiki page still just lists a few proposed drafts. :-/

Alex

Re: Another proposal for modernization of our infrastructure




On 01/31/2015 09:25 PM, Boudewijn Rempt wrote:

In short, Qt uses gerrit is a bogus argument in favor of gerrit.


The argument isn't so much that gerrit is working well
for Qt, but more that there's a certain simplicity in
using the same tooling across the KDE/Qt stack, and
that KDE benefits from having more KDE people active in
Qt. But I actually find contributing to Qt pretty frus-
trating (the infra is flaky, the process tends to break
down here and there, and I sometimes have to step out-
side gerrit and side-channel via email to get things
moving again), yeah.

It's one bullet from a long mail that addresses many
other points, though ... I agree that the KDE community
has concerns and ambitions unrelated to its relation-
ship with Qt and a broader activity scope than the Qt
project, and our tooling needs to be evaluated in that
broader context.



Boudewijn


Cheers,
Eike

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Boudewijn Rempt


On Sat, 31 Jan 2015, Christoph Feck wrote:


On Saturday 31 January 2015 20:07:42 Eike Hein wrote:

[...] Qt is using gerrit and we intend to remain a major stakeholde
in Qt development, which means a sizable number of KDE developers
need to be familiar with gerrit anyway [...]


Excuse me, but if KDE developers will have to follow equivalent steps
as described at http://qt-project.org/wiki/Setting-up-Gerrit to
contribute, then I predict another big loss of developers.

Christoph Feck (kdepepo)



Maybe quite a few KDE developers would want to contribute to Qt, and maybe 
Qt would like more contributors, but KDE is so much bigger -- I'd like to 
see some numbers, but I seriously doubt that the majority of KDE 
developers are potential Qt developers. Even if we have to work around Qt 
bugs quite often.


In any case, if Qt wants more contributors out of the KDE developer pool, 
they'd better ease up their submission process and drop using gerrit. I 
know that I, and I've been a KDE developer for over a decade, won't do 
anything for Qt in my spare time as long as they have this gerrit-based 
workflow. If people are paying me for it, well, that's different, but no 
way am I going to submit to that process for fun and for for free.


In short, Qt uses gerrit is a bogus argument in favor of gerrit. And I am 
pretty sure that if gerrit becomes a requirement for working on KDE 
projects, KDE will not just lose a lot of developers, it will lose a lot 
of projects.


Boudewijn

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Gregor Mi

> On 01/31/2015 08:57 PM, Alexander Neundorf wrote:
>> hmm, looking back at our switch to git, I don't consider our standards for
>> documentation of the developer workflow as very high unfortunately. :-/
> 
> Considering I wrote the majority of 
> https://community.kde.org/Sysadmin/GitKdeOrgManual I
> guess I'll have to take that to heart, then ...

For me as newcomer the mentioned wiki page and
https://techbase.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages
were valuable resources to get familiar with the KDE dev workflow. So it cannot 
be that
bad. ;-)

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Alexander Richardson

2015-01-31 19:37 GMT+00:00 Christoph Feck :
> On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
>> [...] Qt is using gerrit and we intend to remain a major stakeholde
>> in Qt development, which means a sizable number of KDE developers
>> need to be familiar with gerrit anyway [...]
>
> Excuse me, but if KDE developers will have to follow equivalent steps
> as described at http://qt-project.org/wiki/Setting-up-Gerrit to
> contribute, then I predict another big loss of developers.
>

I fully agree here! I only now managed to contribute my first patch to
Qt because setting up gerrit really scared me.
I would have moved on to another project if I hadn't been
using+developing KDE for a few years.
After having used it now I think gerrit is a great tool but the
barrier of entry is just too high. Unless that somehow gets fixed I am
strongly in favour of the Phabricator proposal.

Alex

Re: Another proposal for modernization of our infrastructure




On 01/31/2015 08:57 PM, Alexander Neundorf wrote:

hmm, looking back at our switch to git, I don't consider our standards for
documentation of the developer workflow as very high unfortunately. :-/


Considering I wrote the majority of 
https://community.kde.org/Sysadmin/GitKdeOrgManual I guess I'll have to 
take that to heart, then ...


My vision for how to do a "use gerrit" page well would be to
lead with the minimal recipe for how to clone a project and
upload a change for review. It should put visual focus on
those couple of commands, and make explanation of what they
do secondary. It should also encourage the use of kdesrc-
build as an even quicker alternative. Most of the content
on the Qt page should only be much further down and less in-
your-face, or even on a secondary page, and framed as con-
venience tweaks useful when contributing regularly.

Basically similar to how programming languages or web frame-
works will structure their website these days, leading with
"get you started" info and putting effort into making that
a fast path.

It'd be nice to even make this recipe box a bit dynamic -
click something to get a project selector, pick the KDE
project, and get the commands shown adapted for copying
with the right repo URL inserted.

I think it's doable in principle, but I think the best-
case scenario is still to make gerrit be not a hassle on
coders; I think both its UI and the way you interact with
it have fundamental problems when it comes to non-code
contributors.

I don't think this is shifting of goal posts either be-
cause (a) ReviewBoard already has some screenshot functio-
nality and we actually have policy in place to require
showing screenshots for review requests that change UI
(i.e. this is something gerrit will actually regress us
on afaics) (b) the very reason we entertain shaking up
our infra is because we're unhappy with limitations in
our tools.



Alex


Cheers,
Eike

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Alexander Neundorf

On Saturday, January 31, 2015 20:52:44 Eike Hein wrote:
> On 01/31/2015 08:37 PM, Christoph Feck wrote:
> > Excuse me, but if KDE developers will have to follow equivalent steps
> > as described at http://qt-project.org/wiki/Setting-up-Gerrit to
> > contribute, then I predict another big loss of developers.
> 
> This information could be pared down considerably and presented
> much more nicely - and would have to be if we decide to use
> gerrit. In addition, kdesrc-build could automate some of the
> local setup (Qt's ./init-repository script does as well) to get
> people started faster.
>
> I agree the barrier-to-entry with gerrit is high, but I don't
> consider that Qt page to be up to our standards if we were to
> put serious thought behind communicating the use of gerrit.

hmm, looking back at our switch to git, I don't consider our standards for 
documentation of the developer workflow as very high unfortunately. :-/

Alex

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Martin Graesslin

On Saturday 31 January 2015 20:37:31 Christoph Feck wrote:
> On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
> > [...] Qt is using gerrit and we intend to remain a major stakeholde
> > in Qt development, which means a sizable number of KDE developers
> > need to be familiar with gerrit anyway [...]
> 
> Excuse me, but if KDE developers will have to follow equivalent steps
> as described at http://qt-project.org/wiki/Setting-up-Gerrit to
> contribute, then I predict another big loss of developers.

I have to agree. Whenever I need to do a change for Qt I need to google for 
how to do it. Including putting serious thought in how the push command must 
look like, how I need to adjust the examples provided and for which 
ref/for/foo it has to be this time. This is something which seriously concerns 
me with the outlook of gerrit. git has a steep learning curve, gerrit adds 
quite some further steepness to it :-(

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Another proposal for modernization of our infrastructure




On 01/31/2015 08:37 PM, Christoph Feck wrote:

Excuse me, but if KDE developers will have to follow equivalent steps
as described at http://qt-project.org/wiki/Setting-up-Gerrit to
contribute, then I predict another big loss of developers.


This information could be pared down considerably and presented
much more nicely - and would have to be if we decide to use
gerrit. In addition, kdesrc-build could automate some of the
local setup (Qt's ./init-repository script does as well) to get
people started faster.

I agree the barrier-to-entry with gerrit is high, but I don't
consider that Qt page to be up to our standards if we were to
put serious thought behind communicating the use of gerrit.

Keep in mind though I've raged quite a bit about gerrit's UI
in this thread, and yes, this is part of it. I think gerrit's
useful, but I don't enjoy using it, personally.



Christoph Feck (kdepepo)


Cheers,
Eike

Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support

2015-01-31 Thread Christoph Feck


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122341/#review75101
---



thumbnail/thumbnail.cpp


Please do not use "//" on every line to disable a section of code. It 
touches every line in the git change log. Better use "#if" on a separate line.


- Christoph Feck


On Jan. 31, 2015, 6:24 p.m., David Narváez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122341/
> ---
> 
> (Updated Jan. 31, 2015, 6:24 p.m.)
> 
> 
> Review request for kde-workspace, Bhushan Shah and David Faure.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Only major difference would be the lack of fallback to KFMI. Maybe we could 
> implement thumbnail features in KFileMetadata?
> 
> 
> Diffs
> -
> 
>   thumbnail/thumbnail.cpp 39e8de5 
> 
> Diff: https://git.reviewboard.kde.org/r/122341/diff/
> 
> 
> Testing
> ---
> 
> Only tested compilation.
> 
> 
> Thanks,
> 
> David Narváez
> 
>

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Christoph Feck

On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
> [...] Qt is using gerrit and we intend to remain a major stakeholde
> in Qt development, which means a sizable number of KDE developers
> need to be familiar with gerrit anyway [...]

Excuse me, but if KDE developers will have to follow equivalent steps 
as described at http://qt-project.org/wiki/Setting-up-Gerrit to 
contribute, then I predict another big loss of developers. 

Christoph Feck (kdepepo)

Re: Another proposal for modernization of our infrastructure




On 01/31/2015 10:37 AM, Jan Kundrát wrote:

About the "we could" vs. "we will" in general, I have to admit I'm
slightly confused by that. The proposal is careful to describe what is
available today, and to make a clear difference in saying what needs to
be done in future. Maybe some part needs clarification -- what parts do
you think are more of the yes-this-would-be-nice-but-I'm-worried nature?


I just wanted to make the point (but I agree I made it a bit
poorly) that it's worth differentiating between features the
proposed solutions are guaranteed to deliver right away, and
features they may enable in the future, but only if certain
other conditions are met, e.g. raw infrastructure expansion.

That's not a knock against your proposal, though - it's much
easier to e.g. ask for hardware donations when you can point
to a clearly identifyable need.

--- snip ---

I'd like to summarize my current feelings on both proposals.


Here's what I think gerrit's strong points are:

* There's undeniably synergy and cultural alignment with
  middleware communities we depend on to be had. Qt is
  using gerrit and we intend to remain a major stakeholder
  in Qt development, which means a sizable number of KDE
  developers need to be familiar with gerrit anyway. KDE
  using gerrit lowers the barrier for KDE developers to
  work upstream, and for folks in the wider Qt community
  to involve themselves in KDE. Particularly for Frame-
  works development this could be a boon.

* gerrit and the community around gerrit (which includes
  Jan) appears to have considerable chops when it comes
  to solving hard infrastructure problems like advanced
  CI and replication. This is stuff that can enhance the
  quality of our products by improving our processes,
  but it also stands to make KDE a more attractive envi-
  ronment for incubating new projects. Infrastructure
  should not be the sole platform we run recruitment on,
  but staying competitive is important, and one way to
  do that is to try and lift things only a community of
  KDE's size can lift -- and that can e.g. include
  gathering donations for fancy CI cluster setups.


Here's what I think Phabricator's strong point is:

* From what I've seen and played with so far, I really
  like the UI. This is a short bullet, but an important
  one.

* In terms of cultural alignment, I see communities like
  Blender and Wikimedia pick Phabricator. Lowering the
  barrier for cross-pollination with communities like
  this seems very attractive to me, because there's
  types of talent engaged in those communities that we
  need more of in KDE, e.g. designers and artists.

* I expect the above drivers to make it more likely that
  Phabricator will develop functionality that will make
  it more useful for these types of contributors. For
  example, good diff viewers for visual assets, good
  handling of screenshot attachments to change proposals,
  etc. I feel like it is less likely that gerrit will
  become similarly useful for non-code assets.

* The conflation of change review and issue tracking in
  Phabricator makes sense in the above context as well,
  and could greatly improve our non-programming develop-
  ment processes. In short, I don't see gerrit benefit
  our non-code contributors at all, but I see a shot at
  Phabricator doing so.

Given all of this, I find it really hard to have a firm
opinion at this point. Both proposals promise strong
benefits to different aspects of what the community is
doing, which makes this an exercise in weighing those
aspects and predicting future outcomes based on different
ratios between them.

That said, at this point, I have more experience work-
ing with gerrit than with Phabricator, and I think that's
something that needs to be addressed as part of this
process. I think we should proceed with setting up a test
instance and giving it a spin, this should help with
getting things into clearer focus.


Cheers,
Eike

Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support

2015-01-31 Thread David Narváez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122341/
---

Review request for kde-workspace, Bhushan Shah and David Faure.


Repository: kio-extras


Description
---

Only major difference would be the lack of fallback to KFMI. Maybe we could 
implement thumbnail features in KFileMetadata?


Diffs
-

  thumbnail/thumbnail.cpp 39e8de5 

Diff: https://git.reviewboard.kde.org/r/122341/diff/


Testing
---

Only tested compilation.


Thanks,

David Narváez

Re: Review Request 122330: Associate .qmltypes and .qmlproject files with the text/x-qml mime type

2015-01-31 Thread Denis Steckelmacher


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122330/
---

(Updated Jan. 31, 2015, 6:48 p.m.)


Review request for KDE Frameworks, kdelibs and KDevelop.


Repository: kcoreaddons


Description
---

The KDevelop QML/JS plugin sometimes needs to parse .qmltypes files (in order 
to list the content of installed QML modules, for instance), but KDevelop 
requires that files parsed using the QML/JS plugin have the text/x-qml mime 
type.

Because .qmltypes and .qmlproject files are valid QML files (they follow the 
standard QML syntax), this patch proposes to add these extensions to the ones 
associated with the text/x-qml mime type.


Diffs
-

  src/mimetypes/kde5.xml cc9f71e 

Diff: https://git.reviewboard.kde.org/r/122330/diff/


Testing
---

Installing kcoreaddons and updating the system MIME database allows KDevelop to 
detect that files with the .qmltypes and .qmlproject extensions have to be 
parsed using the QML/JS language support plugin. This allows QML files to use 
QML modules installed system-wide (and fixes the unit tests of kdev-qmljs).


Thanks,

Denis Steckelmacher

Re: Another proposal for modernization of our infrastructure


On Saturday, 31 January 2015 13:08:07 CEST, Inge Wallin wrote:

Well, all of the above and more.  Hosting, electricity, networking,


I'm including all of the above as "HW costs" in my proposal. We (KDE) do 
not have our own datacenter after all.



manual work as the number of physical machines increas


Due to the nature of build jobs which constitute a pretty bursty load, 
renting VMs sounds like a cost-effective approach for our scale. I do not 
expect that it would make financial sense for us to procure enough physical 
HW to cover the peak demand -- hence the VMs. Renting VMs also enables 
corporate sponsors to offer unused capacity for less money, or even for 
free.


Another benefit is that bootstrapping a new VM is about executing a single 
command (and this is not hype; it's how all of the current build VMs in use 
by Gerrit were launched).



manual work as the complexity increases, and so on.


I would prefer if we stopped using phrases such as "increased complexity", 
and switched to expressing a specific and measurable difference in costs.


The reason for this request is that "increased complexity" is almost always 
true, yet people have no way of actually judging what it is going to mean. 
For example, we have in-house expertise in Jenkins where Ben, Nicolas, 
Scarlett and Marko understand the stack we use. Switching to anything else 
will cost us some time to get the respective sysadmins up to speed to the 
new tools. I do not question this.


However, chances are that at the same time adopting a new system could 
provide significant savings in future. For example, if a new system allowed 
easier updates to the build structure, it is reasonable to have a wiki page 
with instructions and to let developers propose changes for their projects. 
That way, sysadmin time could be freed for other tasks. So even though 
there is some initial investment, the long-term operation can easily get 
less demanding, and cheaper.


In fact, a better tooling could attract more people. "Hey, this is a nice 
system which provides almost exactly what I need; can I improve it?" It 
also presents an opportunity to clean some of the cruft accumulated over 
years, thereby reducing the barrier of entry for new contributors and 
improving the bus factor.


Finally, there is also that aspect of providing a better service to our 
developers. Running infrastructure costs something, yet we do it. IMHO, we 
should strive for offering the best service that we can afford with the 
resources we have today, and have a contingency plan for future.


Right now, we have access to some nice CPUs for free. If it proves useful 
and we get used to it and if the resources stop being free at some future 
point and if we cannot obtain a free alternative from some other sponsor, 
then we should take a look on how much money it would cost us on a 
comercial basis at that point. If the price is too big, then the service is 
*not* that useful for us after all, and we will live without it just fine. 
If, however, we decide that the cost is worth the price and no free/cheaper 
altenrative exists, then we should go and pay. There is no vendor lock-in, 
and it is trivial to migrate to another provider. I just don't see why we 
should be actively prevented from using resources which we have today just 
because we might have to ask somewhere else in future. Turning off 
pre-merge CI would get us back to the current level of resource utilization 
immediately.


That's what this proposal is all about, and please keep in mind that it's 
something which is already deployed and tested. It isn't an 
out-of-thin-blue proposal with uncertain cost of deployment.


Everything can be automated in theory but in practice there is 
never a fully automatic system.


Yes, which is why it's important to looks at the architecture and to spell 
out what our expectations of maintenance effort are. It might be reasonable 
to e.g. compare them with the current effort which goes into keeping 
Jenkins alive and modernizing it.


Keeping the current state has its very real cost, too.

With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Thursday, 29 January 2015 23:11:29 CEST, Eike Hein wrote:

Maybe, but this is actually something I like from the
Phabricator proposal: It provides an impression of our
relationship with Phabricator upstream, which it says
is a good and constructive one.


I believe that our relation with the Gerrit upstream community is a good 
and constructive one, too. We also have patches to demonstrate this.


Then we have the infra people of OpenStack which are an excellent group of 
highly-tallented people who know very well what they are doing, and yet are 
patient enough to help others and to explain why they are doing stuff the 
way they do to curious newcomers. That's one of the reasons why this 
proposal is modeled after the infrastructure which the OpenStack project 
uses.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Saturday, 31 January 2015 11:14:01 CEST, Ben Cooksley wrote:

Fixing a usability glitch and accepting a radical redesign of your
interface are completely different.


Your mail suggested that they apparently do not care about improving their 
UI, because if they did, they would have solved everything already. I 
disagree with that, and provide evidence which supports the idea that 
Gerrit upstream in fact also cares about users, including those who are not 
already experienced with its UI.



We're not the first ones to complain about it's interface but they've
not done anything to remedy this despite a complete redesign (which
reduced the level of functionality interestingly).


How does the ChangeScreen2 reduce the level of functionality?


I see the following in that section:

1) A note that Jenkins is a "glorified job launcher" as we don't use
any of it's advanced functionality (which I refuted - it is much more
than that).


You reiterated that it is cool to have graphs tracking number of failed 
tests. I proposed to fix the tests instead, and offered a solution which 
eliminates this problem for tests that are inherently unstable (see 
3.3.2.). I also explained how running cppcheck and code coverage fits into 
this.


The way I understand this reasoning is: "we have failing tests" -> "we got 
to have graphs so that people know whether any more tests start failing". 
That sounds rather suboptimal to me. I would much prefer to fix the actual 
cause of pain rather than to provide tools which plot the pain level and 
frequency of patient's seizures. Defect tracking is a tool, not a goal. If 
there is another tool which ensures that no additional defects can enter a 
repository, why not simply use that? (Please see the report for dealing 
with non-deterministic tests; this *is* covered.)



2) Some notes that a proposed patch may be based against a week old
revision. This is making assumptions about how a Jenkins setup would
be made - as we're in control of what it does there is nothing to stop
us trying to apply the patch on top of the latest code in Git.


You have to somehow account for the delay between a human reviews a patch 
and the time it gets merged. Any patch could have landed in the meanwhile. 
What builds a patch queue so that you have this covered?



In terms of checking dependency buildability, once again - this is
possible but we don't do anything like this at the moment to preserve
resources.


Given enough CPUs, how would you do this with our current Jenkins setup? 
This is absolutely not just a resource problem; you need something to build 
these projects against appropriate refs, and do this in an atomic manner. 
Zuul does it, and internally it's a ton of work. Jenkins does not do it. 
KDE's CI scripts do not do it, either.



As for it not having a declarative configuration, we're in the process
of refining the Groovy based Job DSL script Scarlett wrote. This will
shift the configuration of Jenkins jobs entirely into Git, and
depending on how things work out - jobs could be automatically setup
when new repositories come into existence or when branch metadata is
revised.


The report said that there are automated tools which provide workarounds 
for this aspect of Jenkins. It's good to see KDE adopting one now.


However, you are investing resources in making a tool with horrible 
configuration more usable. More power to you, it's your time, but this is 
exactly what the report says -- you are working around the tool's 
limitations here.



About the only point left standing is that it doesn't check individual
subcommits, but we've yet to see whether the KDE project as a whole
sees this as necessary


The fact that most of KDE's projects have no use of pre-merge CI does not 
imply that projects who want to opt-in should be punished. This is 
absolutely *not* about pushing an advanced workflow to everybody. It is 
about being *able* to accomodate such an advanced workflow at all.


This is possible today with Gerrit+Zuul, and it was easy to configure that 
way. Our Zuul builds the dependencies (=projects "outside of Gerrit") on a 
per-push basis, exactly how KDE's Jenkins does it. There is no time wasted 
on doing per-commit builds for these, because nobody could react on 
failures anymore -- a change is already in master by that point.


What this is all about is enforcing that each commit which goes through 
code review is regression free.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure

On Saturday, January 31, 2015 12:56:56 Jan Kundrát wrote:
> On Saturday, 31 January 2015 12:20:15 CEST, Inge Wallin wrote:
> > Given how few of our community who have participated so far, I think it
> > borders on pure falsehood to claim "clear consensus" on *anything*. I
> > would
> > put more like "some people want it", and I can certainly see
> > the appeal.
> 
> Fair enough, you have a point -- I suspect there is no consensus that CI is
> useful, or that there is any value in having a clean git history without
> "fix missing semicolon" commits. I agree that having a per-commit CI
> coverage can be well considered an undesirable thing by some developers.
> 
> Which is why I have no intention of pushing these to all KDE projects. What
> I am proposing is an opt-in for those who care.
> 
> > But
> > from that to simply state "the costs in HW are worth it" (and conveniently
> > forgetting cost in maintenance) is a very long step.
> 
> I believe that the cost of maintenance is sufficiently covered by section 5
> of the proposal, so I have to admit that I don't know what I am
> conventiently forgetting about.
> 
> Could you please explain what maintenance cost you are worried about? Is it
> perhaps related to the number of build jobs being run, or the number of
> throwaway VMs we use for builds? Is it about the services which replace
> Jenkins?

Well, all of the above and more.  Hosting, electricity, networking, manual 
work as the number of physical machines increas, manual work as the complexity 
increases, and so on.

Everything can be automated in theory but in practice there is never a fully 
automatic system.

> The scripting which is currently used for build VMs with Gerrit/Zuul lives
> at [1]. The bootstrapping part which turns a downloaded, minimal VM image
> into a build node is [2].

I bet these have to change frequently as code changes and as linux 
distributions and other OS'es change. Everything costs in time, money or both.  
And both resources are limited in KDE at the moment.

> Cheers,
> Jan
> 
> [1] http://quickgit.kde.org/?p=sysadmin%2Fgerrit-project-config.git&a=tree
> [2]
> http://quickgit.kde.org/?p=sysadmin%2Fgerrit-project-config.git&a=blob&f=tur
> bo-hipster%2Fcloud-init.sh

Re: Another proposal for modernization of our infrastructure

On Saturday, 31 January 2015 12:20:15 CEST, Inge Wallin wrote:
Given how few of our community who have participated so far, I think it
borders on pure falsehood to claim "clear consensus" on *anything*. I would
put more like "some people want it", and I can certainly see
the appeal.

Fair enough, you have a point -- I suspect there is no consensus that CI is
useful, or that there is any value in having a clean git history without
"fix missing semicolon" commits. I agree that having a per-commit CI
coverage can be well considered an undesirable thing by some developers.

Which is why I have no intention of pushing these to all KDE projects. What
I am proposing is an opt-in for those who care.

But
from that to simply state "the costs in HW are worth it" (and conveniently
forgetting cost in maintenance) is a very long step.

I believe that the cost of maintenance is sufficiently covered by section 5
of the proposal, so I have to admit that I don't know what I am
conventiently forgetting about.

Could you please explain what maintenance cost you are worried about? Is it
perhaps related to the number of build jobs being run, or the number of
throwaway VMs we use for builds? Is it about the services which replace
Jenkins?

The scripting which is currently used for build VMs with Gerrit/Zuul lives
at [1]. The bootstrapping part which turns a downloaded, minimal VM image
into a build node is [2].

Cheers,
Jan

[1] http://quickgit.kde.org/?p=sysadmin%2Fgerrit-project-config.git&a=tree
[2]
http://quickgit.kde.org/?p=sysadmin%2Fgerrit-project-config.git&a=blob&f=turbo-hipster%2Fcloud-init.sh

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure

On Saturday, January 31, 2015 23:14:01 Ben Cooksley wrote:

> About the only point left standing is that it doesn't check individual
> subcommits, but we've yet to see whether the KDE project as a whole
> sees this as necessary - especially considering that the vast majority
> of projects would use CI in an advisory role only for code reviews,
> and would regular developers continuing to push directly
> (necessitating post-push CI anyway).

I don't know how the rest of KDE does it, but in Calligra we have a pretty 
strict new-features-in-branches policy. You develop a new feature in a branch, 
and then put it up for review when it's finished or at some important 
milestone.

When I work in a feature branch, I often make 20-50 commits, smaller and 
bigger, before I'm done and >100 is far from unheard of.  Naturally I make 
sure that my patches build before I commit anything but also naturally I don't 
test all configurations or all platforms.

I think it would be VERY bad utilization of the KDE resources to check all my 
commits with the full power of CI. It's a good habit to make small and simple 
changes and frankly I think it would be impossible to do. 

Or have I misunderstood what people mean when they say "subcommit"?

> > Cheers,
> > 
> > Jan
> 
> Regards,
> Ben
> 
> > --
> > Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure

On Saturday, January 31, 2015 10:37:26 Jan Kundrát wrote:
> On Thursday, 29 January 2015 21:03:32 CEST, Eike Hein wrote:
> > I think it's a real concern, and I'm wary of "we can patch
> > it away" because carrying a huge custom patch delta for UI
> > mods is what kept us from upgrading Bugzilla for multiple
> > years. I think "is it realistic that we can maintain this
> > and keep up with upstream even if Ben or Jan get hit by a
> > bus" is an important question with regard to both proposals.
> 
> That's a very good question, and a reason for why I am not patching Gerrit
> with stuff not accepted upstream. I agree that carrying big custom patches
> won't scale.
> 
> So far, we don't have any patches at all. I'll be backporting stuff such as
> the show-headers-prior-to-cpp from 2.11 because it is super-easy to do so,
> and because 2.11 isn't released yet.
> 
> We also have some JavaScript proof-of-concept for Bugzilla integration. You
> can check its complexity at [1]. I managed to write that over a Sunday, and
> I am definitely not a web guy. I had zero jQuery experience prior to this.
> 
> > I have similar concerns with some of the promised benefits
> > in the proposal because they strike me more of "we could",
> > which is cool, but it's not "we will". E.g. if test build-
> > ing precombined patches takes an OpenStack cluster - do we
> > have one? Where are we going to get that horsepower? Can
> > we keep it?
> 
> Designing contingency plans is indeed important (see section 5 of that
> proposal; it talks about managing infrastructure-as-code). You are also
> right that the current infrastructure is best-effort and that KDE won't get
> an SLA without paying for one. If we (KDE) need an SLA, we (the company the
> cluster is hosted at) will be happy to be asked for a quote :). Or we (KDE)
> can just host this stuff anywhere else and pay someone else.
> 
> But it seems to me that we already have pretty clear consensus that we
> absolutely do want a pre-approval CI coverage, and that the costs in HW are
> worth it.

The rest of the discussion aside, this is something I want to strongly object 
to.

Given how few of our community who have participated so far, I think it 
borders on pure falsehood to claim "clear consensus" on *anything*. I would 
put more like "some people want it", and I can certainly see the appeal. But 
from that to simply state "the costs in HW are worth it" (and conveniently 
forgetting cost in maintenance) is a very long step.

> Does someone from KDE e.V. know whether we could get some free HW
> resources from a commercial partner (hi RedHat/SuSE/Digia)? Do we have some
> backup cash to e.g. rent VM time from Amazon/Rackspace/whatever in an
> unlikely event that the current hosting platform is withdrawn with no prior
> notice?
> 
> About the "we could" vs. "we will" in general, I have to admit I'm slightly
> confused by that. The proposal is careful to describe what is available
> today, and to make a clear difference in saying what needs to be done in
> future. Maybe some part needs clarification -- what parts do you think are
> more of the yes-this-would-be-nice-but-I'm-worried nature?
> 
> With kind regards,
> Jan
> 
> [1] https://gerrit.vesnicky.cesnet.cz/r/static/bugzilla.js

Re: Another proposal for modernization of our infrastructure

2015-01-31 Thread Ben Cooksley

On Sat, Jan 31, 2015 at 10:53 PM, Jan Kundrát  wrote:
> On Thursday, 29 January 2015 22:57:33 CEST, Ben Cooksley wrote:
>>
>> Given that upstream has had multiple attempts now at an improved
>> interface, I would question whether they would be willing to accept a
>> user interface which is suitable for our needs. It appears that they
>> are quite comfortable with an interface many find unintuitive or
>> difficult to use. If they weren't, considering the number of backers
>> it has - one would think someone would have sponsored such an
>> interface.
>
>
> I don't think this is an accurate and fair description of upstream. They
> fixed a UI usability glitch that Martin complained about in less than 12
> hours. That sounds like they are pretty welcoming to 3rd-party feedback,
> IMHO.

I respectfully disagree.
Fixing a usability glitch and accepting a radical redesign of your
interface are completely different.

We're not the first ones to complain about it's interface but they've
not done anything to remedy this despite a complete redesign (which
reduced the level of functionality interestingly).

>
>> As for the CI backend, please mention what is wrong with Jenkins - if
>> it would be integrated to check code review submissions.
>
>
> The reasons for considering another CI platform are described in my report
> in section 3.3.

I see the following in that section:

1) A note that Jenkins is a "glorified job launcher" as we don't use
any of it's advanced functionality (which I refuted - it is much more
than that).
2) Some notes that a proposed patch may be based against a week old
revision. This is making assumptions about how a Jenkins setup would
be made - as we're in control of what it does there is nothing to stop
us trying to apply the patch on top of the latest code in Git.

In terms of checking dependency buildability, once again - this is
possible but we don't do anything like this at the moment to preserve
resources.

As for it not having a declarative configuration, we're in the process
of refining the Groovy based Job DSL script Scarlett wrote. This will
shift the configuration of Jenkins jobs entirely into Git, and
depending on how things work out - jobs could be automatically setup
when new repositories come into existence or when branch metadata is
revised.

This is 100% declarative - and also integrated into our existing
tooling reducing repetition and storage of information, without the
need to convert or replicate the information even temporarily. We may
even be able to eliminate the prepare-environment.py script, utilising
Jenkins functionality for this instead - and allowing us to eliminate
some of the commit hook complexity we have at the moment in the
process.

About the only point left standing is that it doesn't check individual
subcommits, but we've yet to see whether the KDE project as a whole
sees this as necessary - especially considering that the vast majority
of projects would use CI in an advisory role only for code reviews,
and would regular developers continuing to push directly
(necessitating post-push CI anyway).

>
> Cheers,
>
> Jan

Regards,
Ben

>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Thursday, 29 January 2015 22:57:33 CEST, Ben Cooksley wrote:

Given that upstream has had multiple attempts now at an improved
interface, I would question whether they would be willing to accept a
user interface which is suitable for our needs. It appears that they
are quite comfortable with an interface many find unintuitive or
difficult to use. If they weren't, considering the number of backers
it has - one would think someone would have sponsored such an
interface.


I don't think this is an accurate and fair description of upstream. They 
fixed a UI usability glitch that Martin complained about in less than 12 
hours. That sounds like they are pretty welcoming to 3rd-party feedback, 
IMHO.



As for the CI backend, please mention what is wrong with Jenkins - if
it would be integrated to check code review submissions.


The reasons for considering another CI platform are described in my report 
in section 3.3.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure


On Thursday, 29 January 2015 21:03:32 CEST, Eike Hein wrote:

I think it's a real concern, and I'm wary of "we can patch
it away" because carrying a huge custom patch delta for UI
mods is what kept us from upgrading Bugzilla for multiple
years. I think "is it realistic that we can maintain this
and keep up with upstream even if Ben or Jan get hit by a
bus" is an important question with regard to both proposals.


That's a very good question, and a reason for why I am not patching Gerrit 
with stuff not accepted upstream. I agree that carrying big custom patches 
won't scale.


So far, we don't have any patches at all. I'll be backporting stuff such as 
the show-headers-prior-to-cpp from 2.11 because it is super-easy to do so, 
and because 2.11 isn't released yet.


We also have some JavaScript proof-of-concept for Bugzilla integration. You 
can check its complexity at [1]. I managed to write that over a Sunday, and 
I am definitely not a web guy. I had zero jQuery experience prior to this.



I have similar concerns with some of the promised benefits
in the proposal because they strike me more of "we could",
which is cool, but it's not "we will". E.g. if test build-
ing precombined patches takes an OpenStack cluster - do we
have one? Where are we going to get that horsepower? Can
we keep it?


Designing contingency plans is indeed important (see section 5 of that 
proposal; it talks about managing infrastructure-as-code). You are also 
right that the current infrastructure is best-effort and that KDE won't get 
an SLA without paying for one. If we (KDE) need an SLA, we (the company the 
cluster is hosted at) will be happy to be asked for a quote :). Or we (KDE) 
can just host this stuff anywhere else and pay someone else.


But it seems to me that we already have pretty clear consensus that we 
absolutely do want a pre-approval CI coverage, and that the costs in HW are 
worth it. Does someone from KDE e.V. know whether we could get some free HW 
resources from a commercial partner (hi RedHat/SuSE/Digia)? Do we have some 
backup cash to e.g. rent VM time from Amazon/Rackspace/whatever in an 
unlikely event that the current hosting platform is withdrawn with no prior 
notice?


About the "we could" vs. "we will" in general, I have to admit I'm slightly 
confused by that. The proposal is careful to describe what is available 
today, and to make a clear difference in saying what needs to be done in 
future. Maybe some part needs clarification -- what parts do you think are 
more of the yes-this-would-be-nice-but-I'm-worried nature?


With kind regards,
Jan

[1] https://gerrit.vesnicky.cesnet.cz/r/static/bugzilla.js

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Another proposal for modernization of our infrastructure