On 11/02/2017 07:33 PM, David Edmundson wrote:
> What's the intended destination after review?
Honestly, no idea. Playground? Extragear, does that still exist? Where
do we put random projects these days? :)
I don't want it to be in kdeplasma-addons: That would be one menu too
many, and this is
Hi,
I'd like to submit the "Simple Menu" widget for Plasma to kdereview.
Sysadmin kindly moved the repo in position for me:
https://cgit.kde.org/plasma-simplemenu.git/
A shiny website is found here:
https://store.kde.org/p/1169537/
And here is an old announcement blog:
https://blogs.kde.org
On 01/22/2017 10:58 AM, Sandro Knauß wrote:
> For me the whole text sounds to bureaucratic and too many "you can do this
> after waiting that long" .
I hear you, but we just had a major blow-up about this topic where
people got extremely agitated and threatened to walk out. The hoped
benefit of
Hi devs,
this month, a heated exchange on kde-core-devel about a dep
change breaking CI has moved us to draft a new policy to better
handle situations like this in the future.
While not "law", the policy _strongly_ suggests some guidelines
forming a quid-pro-pro protocol between developers and s
On 01/19/2017 04:55 PM, Ben Cooksley wrote:
> It's already been fixed - by having the CI build libxkbcommon. It was
> also required to build an updated version of xorg-macros upon which
> that depended.
> Libraries that depend on KWindowSystem will have the self-built
> libxkbcommon made availabl
On 01/19/2017 03:59 AM, Friedrich W. H. Kossebau wrote:
> Given this is a policy affecting all of the KDE projects, please first
> propose
> it officially in a separate own thread, with a proper subject. Perhaps even
> on
> kde-community, as kde-core-devel might not be read by many, given it u
On 01/17/2017 11:46 PM, Adriaan de Groot wrote:
> But CI has a really important function: it shows us the health of the sources
> for everything; and that's something the release team needs, and the whole
> community can be interested in. So "opting out" of CI deprives us of a good
> view of t
New draft is up, all changes are to the last section:
* I changed the overall tone from law into strongly suggested
guidelines, with the central idea that sysadmin will only
promise to keep up its end for projects which keep up theirs,
i.e. a reasonable quid-pro-quo hrotocol witj properly c
On 01/16/2017 06:58 AM, Alexander Neundorf wrote:
> - OTOH, if you are maintaining kwin fulltime as paid job, I consider it
> reasonable to expect that the maintainer is able to maintain necessary
> #ifdefs, or apply pragmatic solutions, just to solve the problem for his
> users... but that is
I'll use this as a launching-off point to continue the debate:
Coming out of the weekend, after reflecting a little, I no longer
feel like the extremely hard approach I took in the current draft
is appropriate for the community at large, in line with ade's
concerns of over-democratizing. I don't
On January 14, 2017 1:23:20 AM GMT+09:00, "Martin Gräßlin"
wrote:
>Am 2017-01-13 13:21, schrieb Eike Hein:
>> Ok, here we go. My draft of a formal policy for dep changes and the
>CI:
>>
>> https://community.kde.org/Policies/Dependency_Changes_and_CI
>>
Quick follow-up notes: I improved the formatting a little more,
please refresh if you were reading already - now waiting for
comments, though.
Cheers,
Eike
Ok, here we go. My draft of a formal policy for dep changes and the CI:
https://community.kde.org/Policies/Dependency_Changes_and_CI
Compared to my earlier email, this draft contains some hard deadlines
and an attempt to specify failure modes if the deadlines are not met.
Please chime in with s
> Sure, every time I need a new dep I'm going to do a bikeshed discussion like
> this one. That was the last time I'm going through this. I can do better
> things with my time. No, thank you. After the experience in this thread I can
> only advise everybody to never ever tell the larger KDE com
On 01/13/2017 02:07 AM, Martin Gräßlin wrote:
> Fedora devs don't want it.
Since it might help: Kevin Kofler isn't part of the Fedora KDE SIG, so
his opinion in the thread is his own rather than representative of that
team/community.
> Martin
Cheers,
Eike
On 01/13/2017 01:13 AM, Luca Beltrame wrote:
> Remember: even if we have disagreements (even strong), we're all on the
> same side.
I strongly agree with this. We have enough problems (e.g. making
great software) without fighting each other. As a bystander I've
been disappointed by multiple part
So my view of the situation is that we have a bunch of desires and
needs, and we need to sort them. Here's a couple I can reasily
identify:
* We want to have a working CI that gives us useful results
* We want to have developer flexibility in terms of using and catering
latest dependencies
*
Hi,
exciting work! Just the other day I was hoping someone would pick
up work on PyKDE5 ...
Cheers,
Eike
Hi,
exciting work! Just the other day I was hoping for someone
to take up PyKDE5 ...
Cheers,
Eike
On 09/24/2015 12:11 PM, Boudhayan Gupta wrote:
> Now, what'll come of KSnapshot? Spectacle clearly obsoletes KSnapshot
> on X11 (and Wayland as long as KWin is running - if a generic Wayland
> protocol isn't out by dependency freeze I'll add a generic KWin
> backend temporarily for this release).
On 06/28/2015 11:10 AM, Martin Gräßlin wrote:
> In opposite KSnapshot is a very mature application with a decade
> of development behind it.
It's also a rather stagnant one, and a new developer with
the desire to improve upon the status quo is a high-value
community asset much in the same way a
On 04/20/2015 08:17 PM, Albert Astals Cid wrote:
IMHO the duty of a distro is providing software to their users to use
But not under any circumstance: Enforcing some level of hygiene and
quality in the software provided is a service rendered in my interest
and protects me as a user. A lot of
On 04/13/2015 03:04 PM, Sebastian Kügler wrote:
This sounds awesome.
+1 - just speaking as a user even, that's great news.
Cheers,
Eike
On 01/22/2015 11:42 AM, Jonathan Riddell wrote:
kio-extras is currently released part of Plasma 5. It's need said
that it would be better to be part of applications because they're
plugins used by applications and typically not by the desktop.
kio-extras contains the desktop:/ kioslave that
On 02/02/2015 01:20 PM, Milian Wolff wrote:
Sigh, I find it highly sad to read this over and over again. People keep
confusing the flaky CI and the high quality barrier in Qt with gerrit
itself... Seriously, gerrit the tool is OK, what makes it hard and what is the
actual barrier to entry in Qt
... 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
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 fr
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
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
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 c
On 01/29/2015 10:34 PM, Thomas Lübking wrote:
Given the multiple concerns on the gerrit webfrontend (not only in this
kcd thread) I however also assume that it should be not too hard to get
a serious improvement upstream.
That includes "If we endup w/ a -hypothetical- decision between
'powerful
On 01/29/2015 08:54 PM, Luca Beltrame wrote:
This is only the perspective of an occasional contributor, so perhaps it
doesn't weigh as much.
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 upgradin
On 01/29/2015 06:51 PM, Jan Kundrát wrote:
The VM runs at my workplace. The KDE sysadmins have root access,
PostgreSQL backups are automatically pushed to a KDE server twice a day,
and Git is replicated to git.kde.org within seconds after each push.
Just for the record: I consider you a KDE s
On 01/29/2015 06:24 PM, Milian Wolff wrote:
Much nicer, I think!
I disagree - having the comment in a floating popup instead
of breaking up source code makes it easier to read the code
for me.
Personally, I agree that the gerrit UI is terrible to use.
It's not just the diff viewer, either. T
On 01/29/2015 06:16 PM, Milian Wolff wrote:
FWIW, this document reads like a fairy tale to me. The fact that so much is
already tested and deployed
One thing I'm unclear on: Does the gerrit test instance run
on machines administrated by kde.org these days?
Cheers,
Eike
Hi,
it's becoming increasingly clear from feedback that we didn't
think the decision to ship KF5 apps in 14.12 through very well.
Distros are currently rolling it out as an upgrade to KDE 4
systems over the last 4.x apps, and users are running into the
following problems:
* KF5-based apps don'
On 01/21/2015 10:18 PM, Ivan Čukić wrote:
Hi,
I'm volunteering KActivities for the test.
Konversation, too.
Cheerio,
Ivan
Cheers,
Eike
On 01/21/2015 05:12 AM, Ben Cooksley wrote:
Hi all,
As promised in the earlier thread, i'd like to present the sysadmin
report on the state of the infrastructure surrounding our code.
As someone on the original git infra team, I'm impressed - thanks
for your hard work.
Cheers,
Ben Cooksl
On 13.09.2014 21:34, Martin Gräßlin wrote:
I also see that I should have elaborated more. I had written more and removed
it before sending the mail.
I just wanted to say thanks for a well thought-out reply - I
didn't reply in turn because the discussion continued on the
other fork, and it's p
On 13.09.2014 22:50, Sven Brauch wrote:
That's my opinion as well. It would be nice to have an explicit way to
differentiate the "I think this patch is okay, but I'm not very
familiar with the code you changed" (+1) and "I'm confident this patch
is fine" (+2) cases, and I think everyone with a
On 13.09.2014 21:10, Kevin Krammer wrote:
So your suggestion would be to not have +2 but a policy of some sort that only
the +1 of the maintainer, if there is an active one, is considered as "go
ahead"?
Basically my thinking is roughly this: It actually happens
extremely rarely in practice th
On 13.09.2014 20:21, Ivan Čukić wrote:
I agree, +2 should be retained by the maintainer, or a smaller set of
developers as decided by the maintainer.
Or perhaps it simply turns out that the whole idea of
*having* a '+2' is incompatible with the KDE community
in the first place.
Do we really
On 13.09.2014 17:49, Martin Gräßlin wrote:
my understanding was that it's still possible to bypass the code review, so I
cannot see that it's against the KDE Manifesto as it's only a kind of social
contract. Or am I missing something.
Personally I like the idea of having the +2 limited to the
On 09.09.2014 15:51, Jan Kundrát wrote:
Hi,
we agreed on the Frameworks BoF that the following two repos are now
using Gerrit for some initial testing:
Exclusively, or do they remain on ReviewBoard as well?
Cheers,
Eike
On 07.09.2014 11:00, Jan Kundrát wrote:
Hi folks,
as requested by Ben, I would like to accounce that Trojita
(extragear/pim/trojita) is now using Gerrit [1] for patch review.
The system is open for other KDE projects as well -- if you're
interested, see [2] for further details, or come to my t
-CREATION
src/kcms/webshortcuts/main.h PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119280/diff/
Testing
---
Thanks,
Eike Hein
/knewfilemenu.cpp 4f1ca10
Diff: https://git.reviewboard.kde.org/r/119130/diff/
Testing
---
Thanks,
Eike Hein
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119130/#review61649
---
On July 5, 2014, 1:26 p.m., Eike Hein wrote:
>
> --
/filewidgets/knewfilemenu.cpp 4f1ca10
Diff: https://git.reviewboard.kde.org/r/119130/diff/
Testing
---
Thanks,
Eike Hein
re).
- Eike
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119130/#review61646
---
On July 5, 2014, 12:50 p.m
---
Thanks,
Eike Hein
ed8) at
/home/sho/devel/build/kde/applications/konsole/src/konsole_dummy.cpp:3
- Eike Hein
On June 18, 2014, 5:50 p.m., Jeremy Whiting wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http
.h e8e74c3
kwalletd/kwalletd.cpp fa9fc11
Diff: https://git.reviewboard.kde.org/r/110328/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
http://git.reviewboard.kde.org/r/113447/diff/
Testing
---
Thanks,
Eike Hein
sting
---
Thanks,
Eike Hein
org/r/113447/diff/
Testing
---
Thanks,
Eike Hein
discarded.
Review request for kde-workspace, Plasma and Eike Hein.
Description
---
Fix the crash in plasma-desktop caused by newer QML taskbar widget.
Simple steps to reproduce this crash.
1) Pin any task/application to taskbar using "show launcher when not running"
option
> On Aug. 24, 2013, 3:17 p.m., Eike Hein wrote:
> > Hm, on the face of it, this patch doesn't really make sense ... launcher
> > items don't have an associated task, so the function should already return
> > early and the extra condition should be r
> On Aug. 24, 2013, 3:17 p.m., Eike Hein wrote:
> > Hm, on the face of it, this patch doesn't really make sense ... launcher
> > items don't have an associated task, so the function should already return
> > early and the extra condition should be r
patch, but I really still have to find a way to reproduce
this bug before just applying this blindly - it might be treating a symptom
instead of addressing the root cause.
- Eike Hein
On Aug. 24, 2013, 2 p.m., Bhushan Shah wrote:
>
> --
On Tuesday 04 June 2013 23:50:26 Albert Astals Cid wrote:
> The idea is to have a centralized point of information for all the software,
> of course if maintainers ignore the page it won't work. I'd rather have
> people care about the page than delete it, but as making people care is
> hard, sure g
next week.
- Eike Hein
On May 8, 2013, 11:16 p.m., Eike Hein wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
next week.
- Eike Hein
On May 8, 2013, 11:12 p.m., Eike Hein wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
next week.
- Eike Hein
On May 6, 2013, 5:25 p.m., Eike Hein wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
ed at runtime.
Thanks,
Eike Hein
kwalletd/kwalletd.cpp fa9fc11
Diff: http://git.reviewboard.kde.org/r/110330/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
r
disable (be silent)?
- Eike
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110330/#review32224
---
On May 6,
rtheme.h b4b6c53
kcontrol/input/xcursor/xcursortheme.cpp 2fc7504
Diff: http://git.reviewboard.kde.org/r/110339/diff/
Testing
---
Runtime switching, relogin.
Thanks,
Eike Hein
or/xcursortheme.cpp 2fc7504
Diff: http://git.reviewboard.kde.org/r/110339/diff/
Testing
---
Runtime switching, relogin.
Thanks,
Eike Hein
.cpp fa9fc11
Diff: http://git.reviewboard.kde.org/r/110330/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
;d say it makes sense to pick this up.
Diffs (updated)
-
kwalletd/kwalletd.h e8e74c3
kwalletd/kwalletd.cpp fa9fc11
Diff: http://git.reviewboard.kde.org/r/110328/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
>
> How does KWallet encrypt if no password has been set?
>
About as badly as one would expect. It does still generate a hash which
it uses for encryption. What kwalletd does is try whether it can open a
wallet with an empty password first (thus generating the same hash) and
ask for one to be ente
ur requests [2] is just one line change and the other [1] is not visible
> > from reviewboard. I think you should merge those two requests below with
> > this one.
> >
> > [1] https://git.reviewboard.kde.org/r/110330
> > [2] https://git.reviewboard.k
>
> $ grep -A1 QString::clear /usr/include/qt4/QtCore/qstring.h
> inline void QString::clear()
> { if (!isNull()) *this = QString(); }
>
Fun - the "and makes it empty" part in the QString docs sure makes it sound
like it's going to make it non-null, I guess that's what Lamarque thought.
OK, so b
kwalletd/kwalletd.cpp fa9fc11
Diff: http://git.reviewboard.kde.org/r/110328/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
, it cares whether password is null or empty via
an isNull() check. An empty QString is different from a null one.
- Eike
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110328/#re
ard.kde.org/r/110330/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
, operation verified at runtime.
Thanks,
Eike Hein
ill be posted for
review separately.
Diffs
-
kwalletd/kwalletd.h e8e74c3
kwalletd/kwalletd.cpp fa9fc11
Diff: http://git.reviewboard.kde.org/r/110330/diff/
Testing
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
10328/diff/
Testing (updated)
---
Test package for Kubuntu by Harald Sitter, operation verified at runtime.
Thanks,
Eike Hein
fault.
In the interest of keeping the delta between upstream and downstream as small
as possible I'd say it makes sense to pick this up.
Diffs
-
kwalletd/kwalletd.h e8e74c3
kwalletd/kwalletd.cpp fa9fc11
Diff: http://git.reviewboard.kde.org/r/110328/diff/
Testing
---
Tha
ialog
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/13/tint.png
Thanks,
Eike Hein
l me out for
it I guess).
- Eike
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109997/#review30996
---
On April 13, 2013, 3:
Diffs
-
kio/kio/kfileitemdelegate.cpp 50cc3b6
Diff: http://git.reviewboard.kde.org/r/109997/diff/
Testing
---
File Attachments
Before/after in KFileDialog
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/13/tint.png
Thanks,
Eike Hein
rkdown). I think we should encourage people to experiment in
this direction, rather than press "learn Docbook".
I use asciidoc in another project which can be converted to
Docbook and is really nice:
http://www.methods.co.nz/asciidoc/
--
Best regards,
Eike Hein
documentation? Could it be that you are
simply driven away by the Docbook's towering hulk? :)
Yes - that's basically what I alluded to re "gives you easy preview".
--
Best regards,
Eike Hein
On 07/01/2012 03:28 PM, Anne Wilson wrote:
Eike - there is a Special:RecentChangesLinked - have you explored the
possibility of that working for you?
Visiting a page == polling.
--
Best regards,
Eike Hein
out to be impossible to get the right sort of emails from
MediaWiki (namely one for every new page or page change under a cer-
tain prefix), so I had to resort to polling via the API.
--
Best regards,
Eike Hein
ion while maintaining the wiki comes a lot
easier to us. And it's better to have wiki documentation than
no good documentation, IMHO.
--
Best regards,
Eike Hein
On 05/19/2012 12:49 PM, Friedrich W. H. Kossebau wrote:
So? Instead of remove do a move to tags/unmaintained/2 ?
Aye, sounds like a good solution to me. Thanks!
Cheers
Friedrich
--
Best regards,
Eike Hein
l the
history of the palettes be available in the converted git reposito-
ries?
Cheers
Friedrich
--
Best regards,
Eike Hein
up menu allowing the choice of
which profile to use.
Rich.
--
Best regards,
Eike Hein
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103623/#review9523
---
Ship it!
Looks good, will commit, thanks.
- Eike Hein
On
ld be as easy as a Web
Slice with preconfiguration.
Anyone interested in developing a suitable Redmine plugin
(could be as easy as setting up an existing one, there
are many third-party Redmine plugins), getting it set up
properly and putting together a plasmoid?
--
Best regards,
Eike Hein
;m willing to bet it wouldn't have
been updated now that plans have changed and we
actually made a 4.8 branch (I just fixed the kde-
src-build sample config because it hadn't been up-
dated yet).
--
Best regards,
Eike Hein
-always-needed
stuff behind an Advanced button in normal mode? I think --fullmode is too hard
to discover, I sometimes hear devs say "I wish I could log to a file" because
they don't know it's there.
- Eike Hein
On Dec. 13, 2011, 1:15 p.m., A
On 12/13/2011 12:52 PM, Eike Hein wrote:
the behavior shown in the mail I was disrespect-
ful to others.
Missing words there, "shown in the mail I was
replying to was disrespectful to others", rather.
--
Best regards,
Eike Hein
concern was stopping cold a possible
flame thread, but I could have used the opportu-
nity to explain to Bartolomé what he was doing
wrong and how he could communicate more effectively
in the future.
--
Best regards,
Eike Hein
On 12/12/2011 8:30 PM, Ingo Klöcker wrote:
On Sunday 11 December 2011, Eike Hein wrote:
This isn't k-c-d material, obviously flamy and bikesheddy,
and most likely a case of our esteemed list mods having
had a too luxurious breakfast on this fine Sunday morning.
I'm sorry, but cen
f our
list climate!
--
Best regards,
Eike Hein
1 - 100 of 120 matches
Mail list logo
