Re: Proposal unify back our release schedules

[David Edmundson]

> As a result I'll rescind my idea to slow down Frameworks feature
> releases.

Then I'll take over and fight for it!

>that having a fast Frameworks release cycle allows
> people developing apps with features in Frameworks to not have to live
> on master like we do in Plasma.

That was the motivation for the change. And it's simply a bad motivation.

The most important stakeholder of our release cycle is not app
developers. It's the end-user.

We've seen this in practice over the last 10 years that the user
experience suffers with the short release cycle. Less than a month is
not enough for any meaningful testing, especially for API that we
commit to for years and years.  We've seen last minute respins and
panics on so many 5.x releases.That trumps any other developer-centric
argument by far as the most important thing for developers is their
apps to work well with the libraries they use.

I am 100% certain we would have better products with a different
branch policy on frameworks than the current optimistic policy of
master always being perfect and not having bugfix releases.

How branch policy changes how we do releases still has many many
options, but I would like to see something change and this proposal
does fix that.

David

Re: Proposal unify back our release schedules

[David Edmundson]

>> in that event I'd like for us to put it
>> to a formal KDE e.V. vote


> Is this an eV topic?

Yes and no.

The original decision had a big impact, changing things again will
have a big impact. It's not something that should be decided by a few
people, nor is it something that should be decided or squashed by a
"who can talk for longest" on a mailing list.

Should it be discussed behind closed doors on the eV mailing list? No.
Is an eV vote the only way to get something that's fair and
representative and reach a binary conclusion? I can't think of
anything better

I think it's a resource we should use more often.

David

Re: KDE's 6th Megarelease release parties

[David Edmundson]

I will be organising a party in the UK in Cambridge.
Details (or lack thereof) are on the wiki. Please let me know if
you're interested.

David

Re: KDE's 6th Megarelease release parties

[David Edmundson]

>
>
> P.S: This is all David Edmundson's fault/responsibility I'm just the
> messenger
>

Which means I should volunteer to organise something in England. Probably
Cambridge.
If anyone has thoughts or wants to help on that feel free give me a shout.

Re: Proposal: remove the restriction on normal Bugzilla users being able to change the Severity field

[David Edmundson]

>
> I might recommend taking those on a case-by-case basis, by removing
> severity-modification privileges for just the problematic users who
> abuse the system.

If we have the ability to do that, then I have no objections.

David

Re: Proposal: remove the restriction on normal Bugzilla users being able to change the Severity field

[David Edmundson]

>The reason for this change was to stop users with excessive ego from marking 
>their own tickets and tickets they care deeply about as having the "critical" 
>Severity level.

So what will we do to avoid getting this situation back?
I don't care if a user changes it once, but users who constantly set
their minor UI concern to critical gets tiring quickly. Angrily
closing doesn't work because you can get threads with multiple people
and then that isn't fair.

David

Re: All About the Apps Goal

[David Edmundson]

> Recently I made a minimum viable patch for the KDE Gear release tooling to 
> bump up the version numbers where those apps have snapcraft packaging files.  
> However I've been told I shouldn't "overstate the nature of the goal" with an 
> objection to integrating the packaging into the app repositories.

A goal does not define implementation.

That particular patch is confusing as it's claiming to be about giving
developers control, but it's changing a file in the release scripts to
take the control away from the app developers... the exact opposite of
your opening paragraph.

I'm probably understanding it wrong, but then so are others.

It's a technical discussion and as such requires an actual technical
response. Telling us it's for the goal or appealing to the community
with this thread isn't helping deal with the communication issues
which are clearly present on that MR to help everyone work out what
your masterplan is and how this fits in and actually works towards the
end goal.

David

Re: Qt goes "commercial only! - what now?

[David Edmundson]

That subject title is misleading.

>From a user point of view, there will be no impact.

David

Re: Telemetry questions

[David Edmundson]

> - The telemetry policy says: « applications honor system-wide telemetry
> settings where they exist (global "kill switch") »
>
> Is it documented? How can a system administrator prevent users from turning
> telemetry on?
>

```
/etc/xdg/KDE/UserFeedback.conf
[UserFeedback]
Enabled=false
```

Documented at: 
https://userbase.kde.org/KDE_System_Administration/Kiosk/Keys#Telemetry

Arguably not a technically kiosk key, but semantically similar enough
that it made sense together.

David

Re: Telemetry questions

[David Edmundson]

> - discover
> - plasma (including plasmashell, systemsettings)

Plasma has always had public review at every single step from at least
two reviewers.

David

https://phabricator.kde.org/D24011
https://phabricator.kde.org/D5961

Re: reddit r_KDE uses KDE logo in LGBT colors

[David Edmundson]

On Sun, Jul 12, 2020 at 11:14 AM sabayon11  wrote:

> I have a question:
> Is it legal for reddit moderators of r_KDE to use KDE logo in LGBT
> colors. Is it consistent with logo license?
>

Like KDE itself, Oxygen Icons have a liberal copying policy. Anyone may,
and is encouraged to, use Oxygen Icons in their applications, websites and
physical artwork. *Modification is also allowed*. The only restriction is
that you can not restrict what others then do with the artwork.

The copying licence is the GNU LGPL 3, see Policies/Licensing_Policy
 and LGPL licence text
 for the full legal details.

Source: https://techbase.kde.org/Projects/Oxygen/Licensing . Emphasis is
mine.




>
> https://www.reddit.com/r/kde/
>
> Is it in line with KDE code of conduct - to support certain groups
> that are politically active and be selective in this choice?
>

Changing a logo on a 3rd party social media site is not against the code of
conduct.

Again a helpful link: https://kde.org/code-of-conduct/

I hope this helps address your concerns.

David


> Do you realize that it can stop certain people from funding KDE? Of
> course on the other hand it can make others, like George Soros to fund
> but does KDE really want to go in that direction and engage in such
> politics. Pretending that it has nothing to do with politics is a pure
> lie.
>

> What other KDE contributors think about it? For example: do all KDE
> funders support engaging software community in non-software activity?
>
> I know that reddit is separate website and has nothing to do with this
> forum, however this is social and community issue as well.
>
> What about adding to KDE code of conduct: KDE is not engage in social
> or political dispute. KDE doesn't discriminate nor support any groups
> other than Free Software.
>
> Personally I believe there are thousands of other better places on the
> Internet to express whatever point of view someone has and KDE and its
> community should not be involved in such activities.
>
> It is now off. But this doesn't change the meaning of this action.
> My first message about it to this list was on 3rd of July but has not
> been accepted by moderators yet, so I had to subscribe.
>

Re: Google Summer of Code Proposal (Draft)

[David Edmundson]

As a general rule, brand new programs do not make for good GSOCs.

They stall after GSOC ends, and students don't get the real-world
experience of working in a team on a project.

I would also recommend being more conservative with your goals, so
that any pending mentors see them as realistic. A game engine in 3
months is very optimistic.

David

Re: New homepage for kde.org

[David Edmundson]

>From that website, one thing I'd like to make clear (and I don't know
how) is the different target audience/state of completion for plasma
vs plasma mobile.

Plasma is a ready-to-use user facing product that unskilled people can
"just use"
Plasma mobile is still aimed at the developers stage.

I fear if we present them at the same level in public things we give a
confusing message that will cause us problems.
---

As for "TODO TEXT PLASMA" - is that a request for help, or just a
placeholder for yourself?

David

Re: Please don't make planet.kde.org into a politics feed

[David Edmundson]

Let's avoid taking the politics to the mailing list as well please,
that's even worse.

David

Re: General Infrastructure Maintainability: API and EBN

[David Edmundson]

For EBN, personally I don't find myself using it. I think clang / llvm
warnings / new Qt warnings cover a large part of the source code
section.

I've made a task listing everything EBN currently checks. Then
together can mark off what things have other replacement, and what
remaining things are actually still useful:
https://phabricator.kde.org/T12013

David

Re: Invent/gitlab, issues and bugzilla

[David Edmundson]

>
> Plasma Mobile projects are not included in bugzilla. So, gitlab issues
> is the only "decent" alternative for bug tracking. If we disable
> issues, then the only alternative I see is to report issues to
> Phabricator, which, from my point of view, should be avoided.
>
Things can be added to bugzilla.

> - --

Re: Anonymous contributions

[David Edmundson]

We would need to ask a lawyer.
I only know enough to know that I don't know enough.

Re: Anonymous contributions

[David Edmundson]

There are legal implications as the copyright is ultimately held by real people.

Right now the linux kernel does not accept anonymous or pseudonyms for
that reason.
There was a thread a while back, it needs a real free software lawyer
to give an answer.

David

Re: help desk vs bug tracker

[David Edmundson]

>I'm also wondering whether other KDE projects have the
seem need as we have for Krita,

With my Plasma hat on:

Surprisingly, we don't get too many end user questions on bugzilla. I think
it tends to get loaded onto the distros instead.

We do get quite a few where the user thinks they have a bug but it's an
issue on their end but I don't think a helpdesk would solve them.

David

Re: Closing NEEDSINFO bugs after 30 days

[David Edmundson]

> One of the areas I've found that could use improvement

IMHO it's really not a huge problem*.

If a reporter doesn't answer back, then they clearly don't care.
If its marked as needsinfo it's not in my lists, it doesn't affect me as a
dev in the slightest. They're filtered out by default, I have to go out of
my way to include needsinfo ones.

I have no objections to the proposal, but in terms of what I think will
have best effort-reward, dead products and dead bugs aren't a problem, the
active ones are where resources will pay best.

David

*Making sure to reopen bugs after the commenter replies is a different
story where we do sometimes miss useful things.

Re: Default bug editing privileges can't change Importance field

[David Edmundson]

It's not a mistake. From the thread where permissions are relaxed:

>How about we make it so that normal users have full privilages except the
following:
>
>- Can't bulk change
>- Can't change Importance field
>- Can't re-open bugs in the CLOSED state

For a user user the bug that affects them is always the most important.
We need something for devs to still be able to use.

If you're a triager/developer we can get you edit rights.

David

Re: Twitter access

[David Edmundson]

> Maybe someone can edit the wik page and remove my name.

Done

David

Re: Twitter access

[David Edmundson]

> So that's a no then.  Tell these higher-ups that partial blocking of a
> proven contributor from completing a specific task when they have 15
> years of track record is demotivating and not how things should be
> done in KDE.
>

Peer review is exactly how things should be done in KDE.

I don't understand the problem, maybe you can explain what is unique about
your specific task that means you should skip it.

David

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[David Edmundson]

We have a thread where someone proposes removing statuses, and a proposal
which involves adding a status :/
That doesn't sound like we're unified on what we need at all.

​Personally I would use flags for this "reproducible" or not.

Advantages are:
 - it visibly lists who could reproduce it in a way that is retained after
status changes  (if set up as "multiplicable") and optionally even shows
who has tried and can't.

 - we can enable it per-product (doesn't even need a sysadmin)

 - we don't have to do a difficult migration over bugzilla.  Renaming some
fields is one thing, modifying the core is a lot of work and dangerous.



That hopefully frees up unconfirmed/confirmed to be back to their meaning of

 "do I need anything else from the reporter?"
yes -> needs info
no -> confirmed/resolved

which is how I'd like things to be

David

Re: Plasma sprint in Berlin, Germany: April 21st-27th 2018

[David Edmundson]

I've started a wiki page, please add yourself when you know you're coming.
https://community.kde.org/Sprints/Plasma/2018

This is in addition to the reimbursments page if needed.

I'm thinking given there's so many cheap hostels in Berlin we could book a
couple of big dorm rooms together if we have numbers early.

David

Re: KDE and Google Summer of Code 2018

[David Edmundson]

On Fri, Jan 19, 2018 at 4:41 PM, Marco Martin <notm...@gmail.com> wrote:

> On venerdì 19 gennaio 2018 13:42:25 CET David Edmundson wrote:
> > Note that they'll be finishing GSOC around the same time as 5.14, so that
> > potentially means GSOC work released in 5.15.
> > We shouldn't pick high priority ones that we want done before then.
>
> basing on the priorities recorded in https://phabricator.kde.org/
> project/view/
> 254/
>
> a possible list, among the "medium":
> * removable devices
> * printers
> * spell check
> * formats
>
> among the "high", but we can live if gets delayed a bit:
> * mouse (can of worms?)
> * date/time
> * user manager
>
> other suggestions?
>

Mouse is maybe covered by Roman's existing task?
Printers isn't part of Plasma, we need to check with the author.

But I think all of them are good options.

They're not the same size, I don't think working on date and time would
take up 3 months.
Maybe we can group a few of the simpler ones together?

Go for it.
You can put me down in the list of mentors.

David


>
> --
> Marco Martin
>

Re: KDE and Google Summer of Code 2018

[David Edmundson]

On Fri, Jan 19, 2018 at 9:42 AM, Marco Martin  wrote:

> On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham 
> wrote:
> > I've submitted an idea for System Settings: Improve handling for
> touchpads
> > and mice with Libinput
>
> Speaking of systemsettings, would be a good fit porting to qml some
> medium-to-big kcm?
>

It's perfect.

Though I'd like us to emphasise that it's not just about doing a simple 1:1
switch of the UI layer but building on Andy's mockups with a UI redesign,
doing a code tidy up, and fixing any relevant open bugs in that module at
the same time.

Note that they'll be finishing GSOC around the same time as 5.14, so that
potentially means GSOC work released in 5.15.
We shouldn't pick high priority ones that we want done before then.

David

Re: Shipping non-free drivers

[David Edmundson]

>Can we ship it on KDE's file server

I would strongly say no.

Partly because of the legalities of that code, but also because unless you
want to allow everyone to do device specific Neon customisations upstream
in Neon, Neon itself shouldn't be doing any.

David

Re: KDE at Qt World Summit 2017 - let's make it the best yet!

[David Edmundson]

​If there's sitll space, I'm happy to come help out.

David

Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

[David Edmundson]

>We should probably also ask the sysadmin team whether they would be
willing to maintain our own chat server.

That's "maintain a third chat server".

They maintain both kdetalk (jabber) and Conpherence (phabricator) already.

David

Re: Applications Lifecycle Policy

[David Edmundson]

> 2. Remove playground
>

Lots of projects get started and die.

I think it's important to have some flag (however you want to call it) that
says; CI admins, translators and even packagers should not bother looking
at this project yet.  Otherwise we waste a lot of people's time.

The review process in it's current reality is mostly an extension of that,
with the people checking those things off.
There is little actual code review, it's mostly CMake and i18n.

Re: Changes to the bugzilla workflow: 2 proposals

[David Edmundson]

On Sun, Dec 11, 2016 at 9:35 PM, Luigi Toscano 
wrote:

> Hi,
>
> I would like to propose two changes to the Bugzilla workflow for our
> instance
> on bugs.kde.org. The two proposals are totally independent from each
> other.
>
> a) use the "needinfo" flag instead of the NEEDINFO status.
>
> This is implemented on various instances of bugzilla (mozilla.org,
> redhat.com,
> opensuse.org) and allows the requester to set a needinfo on one or more
> specific user.
>
>
> In terms of bugzilla workflow, we need to indicate 3 possible states of
who we are waiting on:

 - needs bugzilla input from a developer (current unconfirmed)
 - needs bugzilla input from the reporter (current needsinfo)
 - doesn't require any further bugzilla input (current confirmed/resolved
as appropriate)

I don't think it can be done in any fewer statuses, and I don't really see
how it requires any more.


> b) change back the initial state from UNCONFIRMED to NEW.
>
> This was the default until Bugzilla 3. But Many of our developers don't
> really
> use the UNCONFIRMED->CONFIRMED transition and this confuses the users.
> Moreover, NEW is still the initial status on various bugzilla instances.
>

Not arguing, but it's worth noting this was a deliberate default change
between bugzilla 3 and bugzilla 4.

Whether they have new or not, is probably an indication of how old that
project's bugzilla instance is.
They document the reason here:
https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/

However, we have another problem: You can rename every status in bugzilla
except this one...
http://bugzilla.readthedocs.io/en/latest/administering/workflow.html

>I would introduce an ASSIGNED state so that developers that want to mark
that
they have acknowledged it and they are going to work on it can do it.

That's quite clearly 3 proposals. I'll report a bug :P

FWIW that's bugzilla 4/5's default "INPROGRESS".

David

Re: Bugzilla Update Staged: Testing Requested

[David Edmundson]

I had a poke round.

There's a new section on the show_bug page between the status summary and
the attachments list, which shows a time tracker where you say how long a
job should take/is taking.

I don't think this makes any sense outside a coroporate environment, so we
should turn this off.

It's in an if block: [% IF user.is_timetracker %] which is set if the
user is in the group "timetrackinggroup". I think it might be a new feature
in Bugzilla 5 that auto set to on.


Also, in the clone only one of my tracked users in email preferences ->
user watching still exists, So it seems the porting hasn't migrated
something properly. Nothing critical, but worth me mentioning.

Re: [kde-community] user stats for Neon

[David Edmundson]

On Thu, Apr 14, 2016 at 2:16 PM, Jonathan Riddell  wrote:

> A while ago Albert gave a talk at Akademy about collecting some data
> on our users.  This got me thinking and with Neon I wanted to see how
> many installs we had.  Our package install software will check for new
> versions being available and I could count the IPs of this check but
> that's very unreliable.  Canonical counts IPs from the NTP ping at
> boot up but of course it's only useful at best as a relative metric of
> numbers of installs not absolute numbers.  So I added a machine-id to
> the URL it checks which is the unique value set at install time by
> systemd (/etc/machine-id) so now it has a good idea of being able to
> count the number of installs.
>
>
To acomplish all the goals you've listed we don't need any UID at all.
If you want to count installs, change the client software to add a
parameter only on the first run and count that.


But KDE cares about privacy and it's in our Vision and I don't want to
> be accused of violating that.  But currently I can't see how this can
> violate users privacy any more than an IP address can so I'm curious
> to hear what arguments might come up against this.
>
> Jonathan
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] finding a clear vision for KDE - first draft for discussion

[David Edmundson]

I have two main questions. I'll make them as new threads.

KDE as a community currently has a clear unique selling point for new
projects; Qt libraries, Qt expertise, and connections. A common thread that
makes it worth being a community. We've seen this work in the past with
existing Qt projects like gcompris, tupi coming to us for that reason.

With the unfocussed vision, it seems we lose that. My question therefore is
is, what is our USP, and what benefit is there for any new project to join
us?
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Write our own pull request bot?

[David Edmundson]

On Sun, Sep 20, 2015 at 3:56 PM, Martin Klapetek 
wrote:

> On Sun, Sep 20, 2015 at 10:53 AM, Bhushan Shah  wrote:
>
>> On Sun, Sep 20, 2015 at 8:20 PM, Martin Klapetek
>>  wrote:
>> >
>> > Gnome in their years history of github mirroring had 4 pull requests
>> > (it was mentioned in the other thread...one of the others).
>>
>> Sorry no [1]
>>
>> https://github.com/pulls?utf8=%E2%9C%93=is%3Aopen+is%3Apr+org%3Agnome
>
>
> Cool. I admit I haven't checked, as I said it's a number from
> one of the 300 threads going on.
>
> I said that number but wrt "GTK" not "Gnome"

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

Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)

[David Edmundson]

> >
> > I was under the impression they were disabled by the options we had
> > selected. Unfortunately that is not the case.
>
> Thanks for clarifying on this.
>
> I hope they can still be disabled.
>
> They can't. I had spent some time looking before. Sorry.

However, we have solid hard data that it's a non-issue.

Gnome has been mirrored on github for nearly 2 years, in that time GTK has
had a grand total of 4 pull requests over time.
Most others (gedit, cheese, epiphany) have had 0.

Interestingly they have had literally hundreds of github "forks", which
implies it has led to sustantiable numbers of patches back using the
traditional methods

I've made a wiki page, which says how to turn a pull request into a
reviewboard submission.
https://techbase.kde.org/Development/GithubMirror

If we get any questions we can then just copy and paste that, and don't
need to spend any time explaining. Bam, done.

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

Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)

[David Edmundson]

On Fri, Sep 18, 2015 at 9:10 PM, Friedrich W. H. Kossebau 
wrote:

> Hi,
>
> Am Freitag, 18. September 2015, 17:12:12 schrieb Boudhayan Gupta:
> > Ladies and gentlemen, as you read this mail github.com/kde is being
> > populated by the initial sync of all repositories.
>
> Pardon for the late input, missed the dynamic of the people behind this
> idea
> (and actually expected it would be shot down, at least to me it seems not a
> good idea to add value to a proprietary platform by also adding our source
> code there).
>
> Can we please only mirror those projects whose maintainers are okay with
> the
> added workload due to another public interface which allows interaction
> from
> 3rd-party? Too many people will not get that this is only a mirror, even if
> you put it in bold there. Or worse, not accept it is a mirror, because
> their
> time is more valueable than the time of the maintainers of course.
>
>
I have no time (and actually also no interest) to care for people poking via
> github (incl. the time needed to redirect them to the real official KDE
> infrastructure and any bad vibrations because having to argue why I/we do
> not
> support github really). Other people might have that time and interest, so
> their decision.
> But I don't. I joined KDE for some reason and am doing my FLOSS software
> development here, because of certain values.
> Same would be true for sourceforge.net, gitlab.com, code.google.com (okay,
> dead) or whereever else some people think we should mirror because it's
> where
> "the people" are currently.
>
> So as maintainer I would like to have at least the repos of Okteta,
> libkoralle, cagibi removed from the official KDE github page.


There shouldn't be any extra workload.
Can we at least wait until we see if it's a problem before we try and solve
it?

David


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

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

[David Edmundson]

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

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

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

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

Just as a reminder



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


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

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

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

[David Edmundson]

On Thu, Sep 17, 2015 at 10:03 AM, Ben Cooksley <bcooks...@kde.org> wrote:

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

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

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

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

David


> >
> > David
>
> Cheers,
> Ben
>
> >
> > ___
> > kde-community mailing list
> > kde-community@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-community
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[David Edmundson]

I am great.

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

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

Re: [kde-community] Phabricator: Make it happen already!

[David Edmundson]

> that we'll be moving forward with Phabricator

Can we confirm what parts we're moving forwards with right now
  i.e out of projects.kde.org reviewboard, bugzilla, etc.

>Because a number of policy matters need to be decided, it would be
nice if a small group of people would work with sysadmin to set out a
plan for how we will implement Phabricator within KDE.

Happy to help. You know where to find me.

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

Re: [kde-community] Phabricator: Make it happen already!

[David Edmundson]

On Thu, Aug 27, 2015 at 3:43 PM, Sebastian Kügler se...@kde.org wrote:

 On Wednesday, August 26, 2015 20:57:25 Jaroslaw Staniek wrote:
  +1
  (I am using it as if it was official)

 Same here. The Plasma team is in the process of migrating to
 phaaab!
 already.


To clarify, the mobile only stuff is currently in there for trial.
The rest is pending.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Updating TechBase Getting_Started pages

[David Edmundson]

On Mon, Aug 17, 2015 at 9:53 AM, John Layt jl...@kde.org wrote:

 Hi,

 I've started to update the old TechBase Getting_Started pages for the
 new KF5 world [1].

 My aim is to teach the one simplest quickest way to build KF5 for new
 KDE contributors. There's a few key concepts I want this rewrite to
 follow:
 1) There is only one way to do things, no giving alternatives
 2) There is only KF5, no KDE4
 3) There is only kdesrc-build, no manual messing around

 The three build scenarios (= new dev personas) that will be presented will
 be:
 1) Build an app only using packaged Qt and KF5
 2) Build Plasma only using packaged Qt and KF5
 3) Build Frameworks using packaged Qt

 All the more detailed or historic information will be removed to other
 parts of TechBase [2]. New build instructions for external devs just
 wanting to use a Framework or two should also go here and not
 Getting_Started.

 This may result in some default build configs needing to be added to
 the kdesrc-build repo to make life easier. There may also need to be a
 couple of simple scripts to set-up kdesrc-build to start with, and to
 actually run things seeing as kdesrc-build doesn't. The less the new
 dev has to worry about the better.

 Thoughts? Is anyone else working on something similar?

 We have one for Plasma here.

https://community.kde.org/Plasma/Building

I'm happy for this to become a redirect and unifying them all.


John.

 [1] https://techbase.kde.org/KF5/Getting_Started
 [2] Probably https://techbase.kde.org/Development/Build?
 ___
 kde-community mailing list
 kde-community@kde.org
 https://mail.kde.org/mailman/listinfo/kde-community
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] retiring unmaintained modules?

[David Edmundson]

​I intend to close all systemsettings-kcm_randr

It's obsoleted in the last cycles of 4.x by kscreen and completely dropped
in Plasma 5. They're of no use to anyone now.

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

Re: [kde-community] Your KDE highlight of 2014?

[David Edmundson]

On 23 Dec 2014 20:19, Jonathan Riddell j...@jriddell.org wrote:


 I moved to Barcelona so I could spend my days in the KDE office here

*blue systems office


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

Re: [kde-community] RFC: Announcing new mailing lists

[David Edmundson]

On Sat, Dec 20, 2014 at 10:11 PM, Ben Cooksley bcooks...@kde.org wrote:

 On Sun, Dec 21, 2014 at 4:54 AM, Albert Astals Cid aa...@kde.org wrote:
  El Dissabte, 20 de desembre de 2014, a les 22:19:35, Ben Cooksley va
 escriure:
  On Sat, Dec 20, 2014 at 8:54 PM, Valorie Zimmerman
 
  valorie.zimmer...@gmail.com wrote:
   On Fri, Dec 19, 2014 at 3:19 PM, Albert Astals Cid aa...@kde.org
 wrote:
   Hi guys, sometimes i realize some interesting discussions are being
   carried on mailing lists i didn't ever know they existed.
  
   Do you think it'd be a good idea to ask sysadmins to send an email to
   this
   list every time a new public mailing list is created?
  
   Cheers,
  
 Albert
  
   It would be nice if *somebody* announced them - could be sysadmin,
   could be the new team, or the incubation team.
 
  In some instances, the creation of a new mailing list (like a
  bugs-dist list) would be noise.
  I'd be in favour of the requestor(s) announcing the new list though -
  so they could explain what the list would be used for.
 
  If sysadmin ends up doing it we'll likely be unable to provide as
  decent an explanation (as we're simply not as involved).
 
  But you're the only ones knowing that a mailing list has created. And as
 far
  as i understand there's a description field asked when requesting a list
 no?
  Could automatically send an email here saying List X was created with
  description Y.
 

 We're the only ones who know about every list that is created yes.
 However those requesting the new list will certainly be aware of it
 have being created.

 While we do request a description, sometimes people may want to
 provide additional details on what the list is intended for.


 That makes sense, it can be a simple social policy. Just like moving
something to kdereview.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Your KDE highlight of 2014?

[David Edmundson]

On Fri, Dec 19, 2014 at 11:08 AM, Lydia Pintscher ly...@kde.org wrote:

 Hey folks :)

 2014 is coming to an end. This gives us some time for reflection. What
 are your KDE highlights of 2014? A team that kicked ass? A really good
 release? An event where you made great new friends? Something entirely
 different?

 My personal highlight of 2014 is that we have an amazing visual design
 and usability team that really gets what KDE is all about and makes
 our software look great and ready for many more users.

 Definitely seeing Plasma 5.0 get out of the door. There was such an aura
or doom and gloom approaching the release both from within the team and
externally.

In the end.. a few issues but, all things considered, everything has been
pretty well received and we're very well set up for a very solid 5.x future.

Everyone involved  put so much time and energy especially in those last two
months of just cleaning and fixing in those last two months and it was
great to see that actually pay off.

David


 Cheers
 Lydia


 PS: I am writing a year-in-review piece for the dot and this will be
 part of the input.

 --
 Lydia Pintscher - http://about.me/lydia.pintscher
 KDE e.V. Board of Directors / KDE Community Working Group
 http://kde.org - http://open-advice.org
 ___
 kde-community mailing list
 kde-community@kde.org
 https://mail.kde.org/mailman/listinfo/kde-community

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

Re: [kde-community] Make the World a Better Place! - KDE End of Year 2014 Fundraising

[David Edmundson]

On Thu, Oct 23, 2014 at 7:19 AM, Martin Gräßlin mgraess...@kde.org wrote:

 On Thursday 23 October 2014 00:27:29 David Edmundson wrote:
   Simple Make the world better - link. Bugzilla mails always have at
 least
   2 lines footer anyway, like
  
   Better yet, only include it when it changes to RESOLVED - FIXED :D
 
  I liked my own idea so much I wanted to see how easy it would be.
  Should be just changing newchangedmail.txt.tmpl to
  http://paste.kde.org/pfum2jnjh

 very neat *thumbsup*. Is it also possible to only do for FIXED? If we set a
 bug to wontfix people might not be amused :-P


Updated:
http://paste.kde.org/p5ga9hm3j

Code looks right based on looking at some other people's templates; I
haven't tested it though.


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

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

Re: [kde-community] Make the World a Better Place! - KDE End of Year 2014 Fundraising

[David Edmundson]

 Simple Make the world better - link. Bugzilla mails always have at least
 2 lines footer anyway, like

 Better yet, only include it when it changes to RESOLVED - FIXED :D

I liked my own idea so much I wanted to see how easy it would be.
Should be just changing newchangedmail.txt.tmpl to
http://paste.kde.org/pfum2jnjh
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] High-quality apps in extragear - was - Re: Applications in KDE Generation 5

[David Edmundson]

Given my project is explicitly mentioned, I should reply :)

When KTp was moving out of playground, I was told:
It can't go into the SC because Kopete is there and we have a duty to
maintain that as the official client for all of 4.x

I don't know if that is true or not, it may have been a communication
breakdown or me misunderstanding. I think this was a private chat, not
an official ruling on a mailing list. I don't want to get into a
discussion of feature parity, we both have features that the other
doesn't have but I would like to be part of the SC at some point. So
we are an exception to the it's because the maintainers want that.
rule.

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

Re: [kde-community] Proposal: KDE Manifesto wording revision

[David Edmundson]

There's a change from

_can_ be defended via the FLA
to
_will_ be protected defended via the FLA

(emphasis added by me)

As I understand it the FLA is opt in (http://ev.kde.org/rules/fla.php)
and does not automatically cover all projects.

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