Re: Review Request: allow passing arguments to kcmodule from kcmshell command

Re: [Kde-finance-apps] Review request

On Monday 27 December 2010 08:45:06 Thomas Baumgart wrote:
> [libalkimia]

There is a problem in the list of installed files:

> -- Installing: /local/kde4/lib/libalkimia.so.4.3.0
> -- Installing: /local/kde4/lib/libalkimia.so

The file "libalkimia.so.4" is missing.

Christoph Feck (kdepepo)

Re: [Kde-finance-apps] Review request

Hi,

on Saturday 01 January 2011 17:57:39 Christoph Feck wrote:

> On Monday 27 December 2010 08:45:06 Thomas Baumgart wrote:
> > [libalkimia]
> 
> There is a problem in the list of installed files:
> > -- Installing: /local/kde4/lib/libalkimia.so.4.3.0
> > -- Installing: /local/kde4/lib/libalkimia.so
> 
> The file "libalkimia.so.4" is missing.

Fixed in SVN. Good catch.

Happy new year to everyone.

--

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
There are only 10 types of people in the world: those who
understand binary arithmetic and those who don't.
-------------------------------------------------------------

Re: Adding KFontUtils to kdeui

A Dimarts, 28 de desembre de 2010, Jeremy Whiting va escriure:
> Albert Astals Cid <aacid <at> kde.org> writes:
> > > > Anyway it's obvious i'm too late on this, let's just wait for KDE 4.4
> > > 
> > > Maybe. I do not think I am in the position to stop you :) I have to
> > > agree with Parker that the current suggested patch does not feel "Qt
> > > way", though.
> > 
> > Well, i've done all you both have suggested, so don't know what more you
> > want.
> > 
> > Anyway, let's stop this, makes no sense keep discussing for something
> > that maybe we'll never ship.
> > 
> > Albert
> > 
> > > > Albert
> 
> Christoph, Albert, Others,
> 
> I'd like to see this happen in the 4.7 timeframe (sooner than later)
> especially because it will help kdeedu/libkdeedu/kdeeduui disappear, which
> removes a dependency of a couple of kdeedu applications prior to the
> migration to git.
> 
> Thoughts about the last patches sent by Albert? otherwise I suggest we move
> this class into kdelibs/kdeui where all kde applications can benefit from
> it.

I'm all for it, not sure if i fixed all of Christoph and Parker concerns 
though.

Albert

> 
> Best Regards,
> Jeremy

Re: Git Scratch-Pads for every identity.kde.org account (not only developers)

Andrea Diamantini, 31.12.2010:
> On Thursday 30 December 2010 17:55:35 Milian Wolff wrote:
> > Hey all,
> > 
> > I want to bring this topic to discussion. As developer of KDevelop and
> > Kate I'm forced to jump through hoops to get code by new contributors
> > in.
> > 
> > Right now the workflow is like this:

<snip>

> > Bye
> 
> +1 from here.
> In rekonq development and being used to gitorious and easyness of git
> remotes, we really suffer from this situation.
> I know KDE people is used to reviewboard + svn and I can understand that it
> simply adds "something more" to the usual svn development workflow.
> But this is not the same with git, being it decentralized and having
> remotes and bla bla. In the git case, it seems "forcing" a different
> workflow from what seems natural and easier (pulling the remote branch).
> I also noticed people tending to just comment what is "visible" and "easy"
> in reviewboard (wrong coding style, unuseful changes in the code, etc..)
> instead of downloading/applying/testing locally the patch. Thing that
> never happened before.

True, I've also seen me just commenting on the obvious stuff before actually 
trying the stuff out. Downloading a patch and applying it is just a royal 
pita. Adding a remote and switching branches is easy, esp. if the other 
updates his work and you simply pull in his latest changes into your local 
checkout.

> Is it just us not (yet) used enough to the new situation or is it a real
> problem?
> 
> Regards,

--

-- 
Milian Wolff
mail <at> milianw.de
http://milianw.de

Re: Git Scratch-Pads for every identity.kde.org account (not only developers)

Torgny Nyblom, 31.12.2010:
> On Thursday 30 December 2010 17.55.35 Milian Wolff wrote:
> > Hey all,
> > 
> > I want to bring this topic to discussion. As developer of KDevelop and
> > Kate I'm forced to jump through hoops to get code by new contributors
> > in.
> > 
> > Right now the workflow is like this:
> > 
> > - new contributor says he has a patch
> > - asked to created account on identitiy.kde.org
> > - asked to put patch on reviewboard
> > - gets reviewed
> > - if it's a single commit patch, I ask him to use git format-patch and
> > send me the commit so I can git am it
> > - if it's a new feature or a big bugfix consisting of several commits the
> > above is just a royal pita, hence I ask him to make his git branch public
> > somewhere (gitorious, github, ...)
> > 
> > What I'd like to see improved:
> > 
> > - give every i.k.o account the ability to use his scratch pad without
> > having the developer status.
> > - make it possible to create a review board entry based on a branch in a
> > scratch pad repo. Bonus points for automatic/easier update of the diff
> > based on this branch. And I know that reviewboard does not support
> > anything but single patches (yes, I don't like this as well but I can
> > live with it), yet something like `git diff $branch..master` can be
> > automated.
> > 
> > And for the final merging of commits I could simply add their clone as a
> > remote and merge it just like I used to do on gitorious.
> > 
> > BTW: Opening up scratch pad repos is probably also good for new people
> > working on completely new plugins or apps, since they can use our git
> > infrastructure from the beginning without first having to use
> > gitorious/github/... I know that most people will run into problems
> > sooner or later and need me or someone else to take a look at their
> > code, hence "just work in a local clone at the beginning" is not an
> > option.
> 
> I'm affraid that opening scratch for everyone will make our git solution
> into a new github/gitorious.
> 
> But I'm all for everyone can create a clone of a already hosted project.
> This will fix the concerns above and still keep the focus on KDE.

And what about my last paragraph? Kate and KDevelop see lots of contributions 
from people working on plugins. Both can/should happen in designated repos at 
the beginning imo. Now they have to use gitorious/github/...

Is this how it should be? How was this in SVN times? Did people also start new 
work somewhere else and waited for the time it was kde-review-able to merge it 
into KDE?

Bye
--

-- 
Milian Wolff
mail <at> milianw.de
http://milianw.de

Re: Suspending mailinglists due to lack of moderators.

Tom Albers, 01.01.2011:
> Hi,
> 
> These are the top mailinglists with the most amount of moderation requests.
> For most of them we have tried to contact the current moderators without
> much success last year. So now I suggest we get rid of these mailinglists.
> 
> Note that if you object, you are volunteering for taking over moderation.

>      42 quanta
>      32 quanta-devel

Make me the admin/moderator of these two please.

Bye

--

-- 
Milian Wolff
mail <at> milianw.de
http://milianw.de

Re: Suspending mailinglists due to lack of moderators.

----- Original Message -----
> > Note that if you object, you are volunteering for taking over
> > moderation.
> 
> >      42 quanta
> >      32 quanta-devel
> 
> Make me the admin/moderator of these two please.

Done. Thanks.

--

-- 
Tom Albers
KDE Sysadmin

Re: Git Scratch-Pads for every identity.kde.org account (not only developers)

On 1/1/2011 10:28 PM, Milian Wolff wrote:
> Is this how it should be? How was this in SVN times? Did people also start new
> work somewhere else and waited for the time it was kde-review-able to merge it
> into KDE?

The policy to get a KDE developer account (-> write access to all
of SVN, and now also git) hasn't changed in a very long time. You
are required to state a  convincing reason for why you want the
account and can optionally name an existing dev account as a
supporter, who is then automatically asked by mail to verify his support.

When it comes to determining whether the stated reason is convin-
cing a huge factor is citing any prior successful contributions.
The point is that KDE is team work, so we look for evidence that
the holder of the new dev account has already gathered some ex-
perience working with others in KDE and so has gotten an idea of
the social etiquette and processes involved (having a supporter
goes a long away towards proving this and thus the quality of the 
written reason becomes less important at that point).

That's in their interest as much as the project's as it either
avoids someone unknown suddenly committing to your codebase, or
if someone is committing to your codebase who is indeed unknown
to you you can at least expect that he has a certain level of
familiarity with how things work in KDE.

It's also a mechanism to ensure that stuff served up under a
*.kde.org domain name isn't random crap (this issue is relevant
to your proposal, btw; if you want to see anything like it done,
please come up with a solid plan in this area that can be im-
plemented with the available manpower).

Sometimes dev accounts are also granted for the purpose of comit-
ting entirely new works to playground even without naming a
supporter, but only when the written reason is really solid and
indicates someone who knows what he's doing and appears respon-
sible.

Notably that's a much lower barrier to entry than in probably
most other FOSS projects (which I think is a good thing, btw).

--

-- 
Best regards,
Eike Hein

Re: Suspending mailinglists due to lack of moderators.

At Sat, 1 Jan 2011 21:25:23 +0000 (UTC),
Tom Albers wrote:
>      40 kdelibs-bugs
>      28 plasma-bugs

Aren't these the default assignees for most kdelibs and plasma bugs?
Would they then be assigned to unassigned-bugs <at> ?