Re: Proposal unify back our release schedules

[Luigi Toscano]

(apologize, resending, I've missed a CC)

Carl Schwan ha scritto:
> Hello Community,
> 
> I know this might be a controversial idea, but I would like to propose reunify
> our release schedules. I feel like splitting our releases schedules between
> Frameworks, Plasma and Gear is not working as well as we intended it to be 
> when
> we split the releases schedules for Plasma 5. This is for multiple reasons:
> 
> * We end up with 3 different products which are released at different times 
> but
>   are connected together. Apps and Plasma both need Framework, Plasma needs 
> some
>   packages from gear like kio-extra, Gear needs some package from Plasma like
>   Breeze. Coordinating all these inter-groups dependencies is complex and was 
> one
>   the reason we had to do a megarelease for Plasma 6. Also for the end user, 
> one
>   product is a lot easier to understand.

We also have and we will continue to have applications which are not on this
schedule, and thus KDE will continue to be unfit as a general brand for them.
The work to reduce the dependencies improved with the move to Qt 6 (for
example the Frameworks-but-really-Plasma moved to Plasma), surely it can be
improved.

> * This results in very frequent releases which creates a lot of work for 
> distros
>   and talking with some distro maintainers they seems to agree that having a 
> big
>   releases every 4 months is better than having constantly a new minor or 
> major
>   release from either Framework, Gear or Plasma.




> 
> * We currently don't have a stable branch for Framework and it takes often up 
> to
>   one month for fixes to be deployed. The Framework releases is also not in 
> sync
>   with either Gear nor Plasma while these two modules heavily make use of 
> Framework
>   and contribute to Framework.

But the point of Frameworks is that it should be "always stable".

> 
> * We could have an unified LTS release including more than just Plasma. This 
> is
>   something that distros have been asking for some time already because having
>   just Plasma receiving bug-fixes but not Framework nor the apps is not that 
> helpful.

Wasn't it said that LTS are difficult? I've heard different voices even from
Plasma.


> 
> * In term of promotion, it is very difficult to advertise the 3 releases 
> because
>   combined we have an important release of either Gear, Plasma or Framework 
> every
>   few weeks. This is too frequent and often while a combined announcement 
> would
>   have enough content to be published in a tech newspaper. When splitting the 
> content
>   accross 2 announcements (Gear and Plasma), we reduce the content per
>   announcement and this makes it less interesting for the journalists to write
>   about us. This doesn't come from me, this is that some journalists directly
>   told me.

Again, this will still leave out everything which does not happen to be part
of this 3 blocks.


> 
> * We won't have 3 different release teams but instead have a bigger one with a
>   bigger bus factor. We could also unify the tooling for doing this mass 
> releases
>   a bit.

Releasing improved over time, and the tooling is definitely more unified than
before (I think Frameworks uses the same tool as Plasma). With the discussion
about improving the creating of tarballs directly from the tags, this may be
more a non-problem).

> 
> I do understand that there was valid reasons for splitting KDE Software 
> Collection
> for Plasma 5 but I don't think this worked out. These were as far as I know 
> the
> main arguments used for splitting the Software Collection.

It doesn't mean moving back is the solution. Also, the split happened before
Qt5, and the reason are still there.

> 
> * Trying to move away from "KDE" being recognized as the software instead of 
> the
>   community. This unfortunately didn't really work out, everyone is still 
> using
>   KDE to refer to the desktop. Even distros call their edition "KDE" and I 
> don't blame
>   them, it's difficult to find a better term than that as for example "Fedora 
> KDE Spin"
>   not only contains Plasma but also a lot of KDE apps. Splitting the releases 
> won't
>   help with that, we need to find a better approach or just let it go and 
> accept that
>   people will keep using KDE to describe the desktop/software.

And again, we have and will have stuff which does not fit that. The main
problem is the Desktop which is seen as "KDE".
Maybe it will take just more time and another generation of people.

> 
> * Better promotion of our apps outside of Plasma. This is a valid point but I 
> think
>   pursuing our current strategy of putting our apps in many app store to be 
> more
>   effective. We could also show the platforms support of each applications 
> more
>   prominently in our releases announcements like we already do on apps.kde.org
>   (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot 
> better
>   in term of promotion than the gear announcements and showing 

Re: Proposal unify back our release schedules

[Luigi Toscano]

Nate Graham ha scritto:

> I expect a vast amount of discussion to result from this proposal, and I think
> that's great. It'll be good to talk about it. But I suspect in the end we'll
> likely not achieve 100% consensus, and in that event I'd like for us to put it
> to a formal KDE e.V. vote so that the topic doesn't become stale and die after
> everyone's exhausted from a long discussion.

Is this an eV topic?


-- 
Luigi

Re: Proposal unify back our release schedules

[Luigi Toscano]

Carl Schwan ha scritto:
> Hello Community,
> 
> I know this might be a controversial idea, but I would like to propose reunify
> our release schedules. I feel like splitting our releases schedules between
> Frameworks, Plasma and Gear is not working as well as we intended it to be 
> when
> we split the releases schedules for Plasma 5. This is for multiple reasons:
> 
> * We end up with 3 different products which are released at different times 
> but
>   are connected together. Apps and Plasma both need Framework, Plasma needs 
> some
>   packages from gear like kio-extra, Gear needs some package from Plasma like
>   Breeze. Coordinating all these inter-groups dependencies is complex and was 
> one
>   the reason we had to do a megarelease for Plasma 6. Also for the end user, 
> one
>   product is a lot easier to understand.

We also have and we will continue to have applications which are not on this
schedule, and thus KDE will continue to be unfit as a general brand for them.
The work to reduce the dependencies improved with the move to Qt 6 (for
example the Frameworks-but-really-Plasma moved to Plasma), surely it can be
improved.

> * This results in very frequent releases which creates a lot of work for 
> distros
>   and talking with some distro maintainers they seems to agree that having a 
> big
>   releases every 4 months is better than having constantly a new minor or 
> major
>   release from either Framework, Gear or Plasma.




> 
> * We currently don't have a stable branch for Framework and it takes often up 
> to
>   one month for fixes to be deployed. The Framework releases is also not in 
> sync
>   with either Gear nor Plasma while these two modules heavily make use of 
> Framework
>   and contribute to Framework.

But the point of Frameworks is that it should be "always stable".

> 
> * We could have an unified LTS release including more than just Plasma. This 
> is
>   something that distros have been asking for some time already because having
>   just Plasma receiving bug-fixes but not Framework nor the apps is not that 
> helpful.

Wasn't it said that LTS are difficult? I've heard different voices even from
Plasma.


> 
> * In term of promotion, it is very difficult to advertise the 3 releases 
> because
>   combined we have an important release of either Gear, Plasma or Framework 
> every
>   few weeks. This is too frequent and often while a combined announcement 
> would
>   have enough content to be published in a tech newspaper. When splitting the 
> content
>   accross 2 announcements (Gear and Plasma), we reduce the content per
>   announcement and this makes it less interesting for the journalists to write
>   about us. This doesn't come from me, this is that some journalists directly
>   told me.

Again, this will still leave out everything which does not happen to be part
of this 3 blocks.


> 
> * We won't have 3 different release teams but instead have a bigger one with a
>   bigger bus factor. We could also unify the tooling for doing this mass 
> releases
>   a bit.

Releasing improved over time, and the tooling is definitely more unified than
before (I think Frameworks uses the same tool as Plasma). With the discussion
about improving the creating of tarballs directly from the tags, this may be
more a non-problem).

> 
> I do understand that there was valid reasons for splitting KDE Software 
> Collection
> for Plasma 5 but I don't think this worked out. These were as far as I know 
> the
> main arguments used for splitting the Software Collection.

It doesn't mean moving back is the solution. Also, the split happened before
Qt5, and the reason are still there.

> 
> * Trying to move away from "KDE" being recognized as the software instead of 
> the
>   community. This unfortunately didn't really work out, everyone is still 
> using
>   KDE to refer to the desktop. Even distros call their edition "KDE" and I 
> don't blame
>   them, it's difficult to find a better term than that as for example "Fedora 
> KDE Spin"
>   not only contains Plasma but also a lot of KDE apps. Splitting the releases 
> won't
>   help with that, we need to find a better approach or just let it go and 
> accept that
>   people will keep using KDE to describe the desktop/software.

And again, we have and will have stuff which does not fit that. The main
problem is the Desktop which is seen as "KDE".
Maybe it will take just more time and another generation of people.

> 
> * Better promotion of our apps outside of Plasma. This is a valid point but I 
> think
>   pursuing our current strategy of putting our apps in many app store to be 
> more
>   effective. We could also show the platforms support of each applications 
> more
>   prominently in our releases announcements like we already do on apps.kde.org
>   (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot 
> better
>   in term of promotion than the gear announcements and showing the 
> applications
>   on an unified 

Re: Post-MegaRelease projects

[Luigi Toscano]

Nate Graham ha scritto:
> I've started pondering post-megarelease projects. We've spent so long on
> porting and bugfixing that I think it might be useful to shift gears to
> feature work, and I'd like to brainstorm potential large-scale projects and
> gauge the level of interest in putting resources into them soon.
> 
> Here are some ideas of mine to get the creative juices started:

* remeber that the porting is not finished. Gear for example still has 51
modules which are KF5-only, including several edu modules and kdevelop.
It would be nice to solve at least the cases when a library need to support
both KF5 and KF6 due to dependencies.

Ciao
-- 
Luigu

Re: Retirement of IRC Services and KDETalk.net (Jabber)

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Sun, May 21, 2023 at 10:42 PM Christian (Fuchs)  > wrote:
> 
> Skreamer / Pursuivant: I'd retire these when the replacement is there, and
> not
> before it. I also seem to have missed which part does the auto
> announcement of
> e.g. bug reports, since that was active / fetching, and if I understand 
> site
> previews correctly, that is passive. As in: no automatic notice of new bug
> reports, but only when someone / something actively links them, correct?
> 
> 
> Pursuivant is responsible for the announcement of commits and bugs.
> As of late we have only seen removals of this functionality
> (see 
> https://invent.kde.org/sysadmin/irc-notifications/-/commits/master?ref_type=heads)
> from channels, hence why i'm slating it for decommissioning.

There are just two removal but several other notifications are active.
It has been useful to me to spot some changes in specific areas, I'm sure it's
useful to others. Of all the services you mentioned, I think this one should
be removed only after an alternative is deployed (maybe a plugin for
https://github.com/maubot/maubot ?).

Ciao
-- 
Luigi

Re: Extending the license policy to include Apache-2.0

[Luigi Toscano]

Jonathan Riddell ha scritto:
> I don't think it needs to be restricted to infrastructural tooling, maybe just
> a line somewhere saying Apache 2 is an option if needed for code sharing
> compatibility with third party projects.

That still prevents the usage of Apache 2.0 from scratch, as someone could
always say you can use MIT for a new project which uses Apache 2.0.


-- 
Luigi

Re: Extending the license policy to include Apache-2.0

[Luigi Toscano]

Jonathan Riddell ha scritto:
> I think I'd be against adding it to the policy, the aim of the policy has
> always been to keep it simple which licence to use so ensure code and be
> swapped around within and outwith KDE with minimal worry about different
> licences.  Apache 2 doesn't add any useful use case to our licences that isn't
> already covered by another one, it's just a bit more explicit about the
> intended uses.
> 
> There's no problem with linking to Apache 2 code such as openssl.  When Apache
> 2 licenced code is included in KDE because of policies used by other projects
> that share the code such as aether-ssas or mycroft that shouldn't be a
> problem, we can just note the reason why it's used and make clear the
> different licence.

Please consider that such a broad "no, you need to justify it every time"
basically blocks the usage of this license even for tooling. As pointed out,
for example, Apache 2 is widely used in the Python world.

Can we please at least have an exception for infrastructural tooling?


-- 
Luigi

Re: Extending the license policy to include Apache-2.0

[Luigi Toscano]

Alexander Potashev ha scritto:
> Hi,
> 
> Parts of https://invent.kde.org/websites/aether-sass/ are licensed
> under Apache License 2.0. This disagrees with the KDE licensing
> policy.
> 
> Considering Apache-2.0 is similar to MIT, I don't see why it shouldn't
> be allowed by the policy. Is anyone aware of past discussions of the
> KDE licensing policy and reasoning behind this fact?

It was previously discussed (and sadly rejected) here:
https://mail.kde.org/pipermail/kde-community/2019q4/005618.html


-- 
Luigi

Re: Releasing a non-KF5 library under MIT License

[Luigi Toscano]

Alexander Potashev ha scritto:
> Hi,
> 
> I would like to release a Go library under the terms of the MIT
> License and host it at invent.kde.org. The library definitely won't
> fit in KF5 because it has nothing to do with Qt.
> 
> The https://community.kde.org/Policies/Licensing_Policy says I can't
> do this because (according to this policy) the MIT License is only
> allowed for parts of the "KDE Platform". 

Does it? I see:

4. Source files that are part of a library with a public API which is part of
the KDE Platform (kdelibs, kdepimlibs, kde-runtime and KDE Frameworks) must be
licensed under:
[... licenses, including: ...]
 * MIT: MIT license as listed below.
[...]

5. Any other source files must be licensed under one of the terms listed under
4) or:
[ other licenses]


-- 
Luigi

Re: Rebranding the release service

[Luigi Toscano]

Philippe Cloutier ha scritto:
> Hi Jonathan,
> 
> Le 2021-02-15 à 09:49, Christoph Cullmann a écrit :
>> On 2021-02-15 15:36, Nate Graham wrote:
>>> On 2/15/21 6:01 AM, Jonathan Riddell wrote:
 Here at KDE we've always struggled a bit with branding and the
 announcement of formats for the bunch of releases that was originally
 "KDE" then "KDE SC" then "KDE Applications" and at Akademy 2019 we decided
 to debrand it and make it a release service with lots of different stuff
 in it.  We had monthly update announcements that included those releases
 on the months when they happened and otherwise included everything else
 released over the past month.  But the format doesn't seem to have caught
 on by various metrics.  So the promo group had some chat about different
 formats you can read at https://phabricator.kde.org/T14091
 

 Currently the plan is to reband it probably with the name KDE Gear.   That
 gets released every 4 months (same as currently) with a big announcement
 for it and everything in it.  It's still a collection of apps and
 supporting libraries with no connection to each other except they happen
 to be KDE projects which don't want to do their own release work.  Then
 every 4 months on the months between times we have an update article
 highlighting all the other stuff that has been released by KDE.  The
 bugfix releases for KDE Gear happen monthly as currently and only have a
 minimal announcement.

 We hope this format will get some more traction with engagement from
 outside press and social media buzz.  Any comments welcome.
>>>
>>> +1, I think this makes sense. I like "KDE Gear". It's short and sweet
>>> and suggestive, but not descriptive.
>>
>> +1, too
> 
> 
> If I understand correctly, this is discussing announcements like
> https://kde.org/announcements/releases/2021-02-apps-update/
> 
> But what exactly are we trying to name here? A bundle which contains all KDE
> applications as the ticket indicates?

The thing called "release service", i.e. a set of artifacts (applications,
libraries, even data, whose release process has been delegated to the "release
service" team and happens at the same time.

> In any case, "KDE Gear" sure is short and makes some sense if we consider it
> related to Extragear, but for those who don't know KDE's history, I am
> skeptical that gears are a good way to evoke applications. 

It doesn't need to evoke applications, the idea is to have a brand.

-- 
Luigi

Re: New mailing list for Bugsquad

[Luigi Toscano]

Thiago Masato Costa Sueto ha scritto:
> Hello community,
> 
> 
> I've requested a new mailing list for Bugsquad yesterday.
> 
> 
> https://mail.kde.org/cgi-bin/mailman/listinfo/bugsquad
> 
> 
> I'd strongly appreciate if current bug triagers and interested people
> subscribe to it. I created an Element/Matrix group  #bugsquad:kde.org  so
> there's a place for quick answers as well. For those who don't have an account
> over Matrix yet, you can simply join through this link:

There is already a #kde-bugs channel. Is this room bridged to it? If not,
please reuse the existing one.

-- 
Luigi

Re: auto-comment on bugzilla when making an MR?

[Luigi Toscano]

Nate Graham ha scritto:
> On 5/20/20 6:50 AM, Boudewijn Rempt wrote:
>> On woensdag 20 mei 2020 14:33:42 CEST Filipe Saraiva wrote:
>>> I like the idea, but I hope in future we use Gitlab issues as our tool
>>> for bug management. :)
>>
>> This has been discussed to death before... The plan is to use the issues to
>> replace phabricator's tasks, not bugzilla.
> 
> I'm pretty sure that migrating from Bugzilla to GitLab Issues will happen
> eventually. GitLab Issues has a radically better UI for bug reporting and its
> improved integration with the rest of GitLab will be a really nice thing to
> have. Centralizing everything in GitLab would bring real benefits
It's all about the right level of integration.

> 
> Speaking as an extensive bug triager, if it does indeed represent a downgrade
> in terms of organization and workflow, then we will engage with the GitLab
> people to get the issues fixed. They are pretty responsive, and it's better
> than using a dead, unmaintained version of a stagnant product.

This process will require time for sure, and some of the changes may not be
applied at all as not in line with the general way the system works (and also
the our internal changes to support it).

In the meantime, having the MR published in a bugzilla comment, and any other
integration mechanism, is surely welcome.

-- 
Luigi

Re: auto-comment on bugzilla when making an MR?

[Luigi Toscano]

Nate Graham ha scritto:
> On 5/20/20 6:50 AM, Boudewijn Rempt wrote:
>> On woensdag 20 mei 2020 14:33:42 CEST Filipe Saraiva wrote:
>>> I like the idea, but I hope in future we use Gitlab issues as our tool
>>> for bug management. :)
>>
>> This has been discussed to death before... The plan is to use the issues to
>> replace phabricator's tasks, not bugzilla.
> 
> I'm pretty sure that migrating from Bugzilla to GitLab Issues will happen
> eventually. GitLab Issues has a radically better UI for bug reporting and its
> improved integration with the rest of GitLab will be a really nice thing to
> have. Centralizing everything in GitLab would bring real benefits
It's all about the right level of integration.

> 
> Speaking as an extensive bug triager, if it does indeed represent a downgrade
> in terms of organization and workflow, then we will engage with the GitLab
> people to get the issues fixed. They are pretty responsive, and it's better
> than using a dead, unmaintained version of a stagnant product.

This process will require time for sure, and some of the changes may not be
applied at all as not in line with the general way the system works (and also
the our internal changes to support it).

In the meantime, having the MR published in a bugzilla comment, and any other
integration mechanism, is surely welcome.

-- 
Luigi

Re: Information regarding upcoming Gitlab Migration: clarifications

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Fri, May 1, 2020 at 4:38 PM Nate Graham  wrote:
>>
>>
>>
>> On 4/30/20 5:59 PM, Aleix Pol wrote:
>>> El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
 Am I the only person that just has all the repos on the same folder? I 
 thought it was the common thing to do :?
>>>
>>> I do too
>>
>> Same here. kdesrc-build's default settings do this, and download all
>> repos into ~/kde/src without any of the levels of hierarchy. This would
>> seem to require unique repo names, no?
> 
> Not necessarily.
> 
> Git allows you to override the name that the local folder is called
> when cloning, so there is no reason why we can't specify something in
> the metadata to override the local name that the folder gets called in
> your local checkout folder.
> This would allow for example:
> 
> - frameworks/kcoreaddons on Gitlab continues to be called
> 'kcoreaddons' in your local checkout folder
> - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout 
> folder
> 
> This allows for the URLs on Gitlab to make sense, while simultaneously
> allowing your local source checkout folders to continue to work in the
> manner in which they do currently.
> Note that we do not expect people to hit this in many cases - this is
> about giving us the flexibility for the long term without imposing
> unnecessary bureaucracy and limits on projects within the KDE
> umbrella.
> 
> Automated tooling such as kdesrc-build and the proposed clone script
> (that searches in namespaces) should be able to handle this without
> much issue.
> In the case of manually done clones, it is reasonable to expect people
> to know what they're doing with their clones, and name them
> appropriately in the event they have a collision.
> 
> Does this sound acceptable?

I'd like to add that this would solve an issue we have on the translation side.

Right now, a few translation files use the repository names as the base part
of the template file name. For example, the translation files for the desktop
and json files, which are called ._desktop_.po(t) and
._json_.po(t) respectively.

In the case where the repository name is not unique we would need to record
the expected name for the template somewhere. If this  information is added to
the repository metadata, would have scripty rely on that and don't need to
write it down somewhere else.

So yes, if you can please add this optional override which sets a unique name
to the metadata, that would help, thanks!

-- 
Luigi

Re: Information regarding upcoming Gitlab Migration

[Luigi Toscano]

Bhushan Shah ha scritto:

> - But most importantly, this breaks with the non-unique leaf repository
>   names feature offered by the proposed structure. So, There could be
>   maui/documentation and wikitolearn/documentation. But we would have
>   single KDE/documentation redirect



Just to clarify: are we going towards a non-unique leaf repository name? I
thought we were going to maintain the leaf uniqueness regardless.

If this is the case, I'd really like to express my disappointment: we are
basically forcing back the namespaces as part of the application name. Dolphin
is going to be referred to application/dolphin or application_dolphin, kstars
as education/kstars and so on, because we can have duplicates.

This is a huge step back, also because the namespaces are mixed: we have
subproject types (wikitolearn, maui, plasma-mobile) and category types
(education, pim, graphics, etc). What if plasma-mobile want to distinguish
their projects by categories? That's inconsistent.


We don't know where we will be in 10 years in terms of tooling, maybe gitlab
itself will  introduce better filtering capabilities, let's keep at least the
uniqueness of leaves.


I suspect we need some compromise decision (not win-win, sadly) here, but I
feel that having both (mixed) subcategories (non-flat) and no uniqueness of
repository names is going to be the worst combination.

-- 
Luigi

Re: Licensing Policy and modified Apache License

[Luigi Toscano]

Jonathan Riddell ha scritto:
> On Thu, 12 Mar 2020 at 15:41, L. E. Segovia  > wrote:
> 
> The modification in question is located here:
> https://github.com/wdas/SeExpr/blob/master/LICENSE
> 
> > Copyright Disney Enterprises, Inc.  All rights reserved.
> >
> > Licensed under the Apache License, Version 2.0 (the "License");
> > you may not use this file except in compliance with the License
> > and the following modification to it: Section 6 Trademarks.
> > deleted and replaced with:
> >
> > 6. Trademarks. This License does not grant permission to use the
> > trade names, trademarks, service marks, or product names of the
> > Licensor and its affiliates, except as required for reproducing
> > the content of the NOTICE file.
> >
> > You may obtain a copy of the License at
> > http://www.apache.org/licenses/LICENSE-2.0
> 
> Since my proposal for GSoC 2020 will involve linking Krita with that
> library, I wanted to check if that would be OK with you
> 
> 
> The difference is mostly that they removed
> "except as required for reasonable and customary use in describing the origin
> of the Work"
> as this is not restricted by law anyway it's not something they can license to
> us so it makes no difference.  Go ahead and use it.
> 

IANAL, but according the FSF, Apache 2.0 is only compatible with GPL3, so that
should make everything GPL3:
https://www.gnu.org/licenses/license-list.en.html#apache2

And also:
https://www.apache.org/licenses/GPL-compatibility.html

-- 
Luigi

Re: Sysadmin Load Reduction: Code Related Services

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Tue, Nov 19, 2019 at 6:20 AM Luigi Toscano  
> wrote:
>>
>> Ben Cooksley ha scritto:
>>> On Tue, Nov 19, 2019 at 1:34 AM Harald Sitter  wrote:
>>>>
>>>> On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley  wrote:
>>>>>
>>>>> On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan  wrote:
>>>>>>
>>>>>> Hi all,
>>>>>
>>>>> Hi Carl,
>>>>>
>>>>>>
>>>>>> Can the gitlab api be of useful in the future?
>>>>>>
>>>>>> e.g https://invent.kde.org/api/v4/groups/7
>>>>>
>>>>> While for many purposes Gitlab's API wil be perfectly fine, it doesn't
>>>>> provide us with the i18n branch information which some users will
>>>>> require.
>>>>
>>>> Something to perhaps consider at this point is to revise the
>>>> repo-metadata format in general and offload data to gitlab?
>>>
>>> Once we have transitioned repository hosting and code review to
>>> Gitlab, restructuring how repo-metadata works was one of the items I
>>> wanted to look into (if anything because i'd like to automate updates
>>> to repo-metadata so we don't have to create them on Gitlab and then
>>> register them in repo-metadata as a second separate step)
>>
>> Uhm, does gitlab allow to define custom properties? That may solve the
>> problem. (but probably it doesn't, or it would have already proposed.)
> 
> It doesn't allow us to define custom properties i'm afraid.

Uhm, there is something, but it requires administrative access and I'm not
sure whether it's available in the community edition:

https://docs.gitlab.com/ee/api/custom_attributes.html

>>>> project, e.g. projects/kde/workspace/sddm-kcm.yaml or perhaps even
>>>> more ideally projects/sddm-kcm.yaml (because the current dir structure
>>>> duplicates information encoded in repopath; so I would think either we
>>>> should drop the property or flatten projects/).
>>>
>>> We should mirror the repopath as in the Gitlab world it will be
>>> possible for us to have two repositories that have the same name, just
>>> in different parts of the tree.
>>
>> Can we keep the rule of having unique repository names, even if we could use
>> them? One of the plans to reduce the moves around for translations is to
>> flatten the structure without namespaces. Allowing duplicates would make this
>> impossible and introduce more complication (and it may complicate our life as
>> well if a duplicated repository ever moves to plasma or to frameworks).
> 
> It'll be hard to tell whether a name is unique or not when creating a
> repository unfortunately.
> For the most part I do not expect collisions to occur though and we
> certainly won't aim to create duplicate names.

I understand that, but still it means that we can't flatten the translation
repositories removing the namespaces.

Unless you use the future flattened translation repository as a way to see the
existing names. In fact, it should be possible to periodically (every two
days?) generate a list of all repository names; that should allow to check for
duplicates. Maybe this could reduce the minimum amount of uncertainty when
creating new repositories.

-- 
Luigi

Re: Sysadmin Load Reduction: Code Related Services

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Tue, Nov 19, 2019 at 1:34 AM Harald Sitter  wrote:
>>
>> On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley  wrote:
>>>
>>> On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan  wrote:

 Hi all,
>>>
>>> Hi Carl,
>>>

 Can the gitlab api be of useful in the future?

 e.g https://invent.kde.org/api/v4/groups/7
>>>
>>> While for many purposes Gitlab's API wil be perfectly fine, it doesn't
>>> provide us with the i18n branch information which some users will
>>> require.
>>
>> Something to perhaps consider at this point is to revise the
>> repo-metadata format in general and offload data to gitlab?
> 
> Once we have transitioned repository hosting and code review to
> Gitlab, restructuring how repo-metadata works was one of the items I
> wanted to look into (if anything because i'd like to automate updates
> to repo-metadata so we don't have to create them on Gitlab and then
> register them in repo-metadata as a second separate step)

Uhm, does gitlab allow to define custom properties? That may solve the
problem. (but probably it doesn't, or it would have already proposed.)

>> project, e.g. projects/kde/workspace/sddm-kcm.yaml or perhaps even
>> more ideally projects/sddm-kcm.yaml (because the current dir structure
>> duplicates information encoded in repopath; so I would think either we
>> should drop the property or flatten projects/).
> 
> We should mirror the repopath as in the Gitlab world it will be
> possible for us to have two repositories that have the same name, just
> in different parts of the tree.

Can we keep the rule of having unique repository names, even if we could use
them? One of the plans to reduce the moves around for translations is to
flatten the structure without namespaces. Allowing duplicates would make this
impossible and introduce more complication (and it may complicate our life as
well if a duplicated repository ever moves to plasma or to frameworks).

-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Māris Nartišs ha scritto:
> pirmd., 2019. g. 11. nov., plkst. 16:02 — lietotājs Luigi Toscano
> () rakstīja:
>>
>> Alexander Potashev ha scritto:
>>> вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano :
>>>>
>>>> Nate Graham ha scritto:
>>>>> On 11/9/19 4:50 PM, Nicolás Alvarez wrote:
>>>>>> El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) 
>>>>>> escribió:
>>>>>> - Experiment conversion to git and see if the resulting repo(s) are of
>>>>>> a reasonable size (I vaguely recall seeing bad results with this)
>>>
>>> I expect that a single Git repository would be several GBs in size.
>>
>> For the record, the current checkout (without svn metadata) of 
>> trunk/l10n-kde4
>> (ok, no more needed), branches/stable/l10n-kde4, branches/stable/l10n-kf5,
>> branches/stable/l10n-kf5-plasma-lts, trunk/l10n-kf5 and trunk/l10n-summit is
>> ~11 GiB. The trunk/l10n-kf5 branch alone is 5.3 GiB.
> 
> One of pro sides of SVN still is ability to work with a single
> directory instead of whole repo. For Latvian language it means using
> only ~300MB of disk space (I have less than 1GB free space on my
> laptop). Thus if a move to GIT is planned, I would vote to have a
> separate repo for each language.

Right, but that would make the life of people doing bulk changes (like me)
much more complicated. Right now I can do all the changes in one shot. That's
part of the problem.

-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Ilya Bizyaev ha scritto:
> A task shows this attitude much better as it is something that will be
> completed eventually. "[WIP] Migrate translations from SVN to Git" to me
> sounds like a clear intention.

A task and a document are different thing. A set of tasks are action items
which specifies is an action item which
> 
> Docs, in contrast, are static and do not display any motivation for migration.
> "Top 10 Reasons Why We Can't Use Git".

We may have a different ideas about documents, maybe.

A living document on the wiki (I read what Alexander wrote, but I think that
the wiki is the best place) is something that can evolve. When it's clear that
there are possible follow-ups, tasks can be created (this is not specific to
this issue, it's a more general process).

I'm not sure also why it should have a snarky title like that. It could be
something on the line of "Requirements and issues for migrating translations
to git".

-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Tue, Nov 12, 2019 at 10:00 AM Alexander Potashev
>  wrote:
>>
>> пн, 11 нояб. 2019 г. в 17:02, Luigi Toscano :
>>>
>>> Alexander Potashev ha scritto:
>>>> вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano :
>>>>> Most of translators are not so technical as the developers. And even
>>>>> developers can shoot them in the foot with git, I see many issues coming 
>>>>> from
>>>>> unwanted merges.
>>>>
>>>> We can block unwanted merged on the server with a Git hook like this:
>>>> https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-commit
>>>
>>> When I talk about local merges, I foresee a bit of mess when resolving a 
>>> merge
>>> locally, which may result in proper commits whose content has an invalid 
>>> syntax.
>>
>> I don't get it.
>>
>> If you have conflicting changes, either with SVN or Git, you have to
>> resolve the conflict manually. Of course it's easy to break the syntax
>> while doing so, however SVN does not make it any easier than Git.
>>
>>>> Cloning the whole repo would be too much for some translators, however
>>>> the new Git feature "git clone --filter" might be a solution:
>>>> https://unix.stackexchange.com/a/468182
>>>
>>> Documentation does not seem to help (or at least I don't seem to find it in
>>> the man pages for git 2.24). Do you know how it could filter just some
>>> directories? It seems more focused on filtering by object type.
>>
>> OK, I now tried this approach with Git 2.23 (see attached log) and
>> found horrible problems that make it basically unusable:
>>
>>  1. git-checkout downloads each file in a new SSH connection. It make
>> the download really slow: less than 1 file per second in my setup.
>> That means downloading of translations into one language would take
>> more than an hour.
>>
>>  2. git-status silently tries to download to whole Git repository.
>>
>>  3. git-commit tries to download some files one by one again.
>>
>>>> Shall I create a new Phabricator task "[WIP] Migrate translations from
>>>> SVN to Git" so we can put relevant ideas in one place?
>>>
>>> I don't know. For me having a board and tasks (it's not just a single task,
>>> it's an entire project) sounds like there is something that can be
>>> implemented, and I don't think it's the case.
>>
>> The tag [WIP] would hint that we are not sure if it can be
>> implemented. We can even name it "Reasons why translations cannot
>> migrate to Git", if necessary.
> 
> Sorry, but if you proceed with using a title such as that one, then
> you are not being constructive or helpful towards this conversation.
> 
> That title would indicate to me that the translation community is
> completely unwilling to consider change of any form.

That's why it shouldn't be a task at this point, but a document showing why we
can't migrate.
It's not a matter that we are unwilling to consider. The problem is that the
current state makes it almost impossible to migrate. The document would
explain why.


-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Alexander Potashev ha scritto:
> вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano :
>>
>> Nate Graham ha scritto:
>>> On 11/9/19 4:50 PM, Nicolás Alvarez wrote:
>>>> El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) 
>>>> escribió:
>>>>>
>>>>> Not knowing anything about the translation system we use... what are the
>>>>> blockers to moving it over to git?
>>>>>
>>>> Not necessarily in order:
>>>> - Experiment conversion to git and see if the resulting repo(s) are of
>>>> a reasonable size (I vaguely recall seeing bad results with this)
>>>> - Convince and teach every translator to use git (expect lots of friction 
>>>> here)
>>>> - Make scripty use git instead of svn (likely lots of work)
>>>> - Some language teams have their own tooling (local for translation,
>>>> or web for statistics) that would need to be gitified too. For
>>>> example, the Spanish team developed KSvnUpdater.
>>>> - Update lots of documentation in different languages (eg.
>>>> https://es.l10n.kde.org/repositorio.php)
>>>>
>>>> You may even need to migrate languages one by one (as you convince
>>>> each language team?), so in the meantime all tooling would need to
>>>> support both repos at the same time.
>>>>
>>>> It doesn't sound like fun...
>>>
>>> Thanks for the background.
>>>
>>> If we're going to keep SVN, I think we need to fully support it. If we don't
>>> have the resources to do this on an ongoing basis, then we need to invest 
>>> the
>>> resources now/soon to move away from it. I don't see any other realistic 
>>> options.
>>
>> New resources is the solution. Please see the other emails: the problem
>> discussed is not subversion itself, but the web interface.
>>
>>>
>>> Again, from a totally non-translation perspective, I am somewhat surprised 
>>> to
>>> hear that individual translators are required to be proficient in a source
>>> control system. Perhaps de-coupling the workflow from direct interaction 
>>> with
>>> the SCM would be beneficial? Isn't this what GUI apps like KLocalize do? If
>>> not, can it be modified to do the SCM interaction? This seems like a 
>>> solvable
>>> problem.
>>
>> Most of translators are not so technical as the developers. And even
>> developers can shoot them in the foot with git, I see many issues coming from
>> unwanted merges.
>> Also, in addition to some of the problem described above (not all of them are
>> blocker IMHO), more relevant: how would you convert the SVN repositories 
>> into git?
>> - a unique repository would be the easier way, and required by people who do
>> changes to all the languages (renamed and moves) but I can only foresee tons
>> of merging issues when committing (see above).
>> - a repository per language would mean a tons of work whenever you need to do
>> a global operation, and right now it's a no go.
> 
> Hi Luigi,
> 
> We can block unwanted merged on the server with a Git hook like this:
> https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-commit

When I talk about local merges, I foresee a bit of mess when resolving a merge
locally, which may result in proper commits whose content has an invalid syntax.

> 
>>>> - Experiment conversion to git and see if the resulting repo(s) are of
>>>> a reasonable size (I vaguely recall seeing bad results with this)
> 
> I expect that a single Git repository would be several GBs in size.

For the record, the current checkout (without svn metadata) of trunk/l10n-kde4
(ok, no more needed), branches/stable/l10n-kde4, branches/stable/l10n-kf5,
branches/stable/l10n-kf5-plasma-lts, trunk/l10n-kf5 and trunk/l10n-summit is
~11 GiB. The trunk/l10n-kf5 branch alone is 5.3 GiB.


> Cloning the whole repo would be too much for some translators, however
> the new Git feature "git clone --filter" might be a solution:
> https://unix.stackexchange.com/a/468182

Documentation does not seem to help (or at least I don't seem to find it in
the man pages for git 2.24). Do you know how it could filter just some
directories? It seems more focused on filtering by object type.

> Shall I create a new Phabricator task "[WIP] Migrate translations from
> SVN to Git" so we can put relevant ideas in one place?

I don't know. For me having a board and tasks (it's not just a single task,
it's an entire project) sounds like there is something that can be
implemented, and I don't think it's the case.
I think we should first document all the answers to this recurring questions
first.
-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Nate Graham ha scritto:
> On 11/9/19 4:50 PM, Nicolás Alvarez wrote:
>> El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) 
>> escribió:
>>>
>>> Not knowing anything about the translation system we use... what are the
>>> blockers to moving it over to git?
>>>
>> Not necessarily in order:
>> - Experiment conversion to git and see if the resulting repo(s) are of
>> a reasonable size (I vaguely recall seeing bad results with this)
>> - Convince and teach every translator to use git (expect lots of friction 
>> here)
>> - Make scripty use git instead of svn (likely lots of work)
>> - Some language teams have their own tooling (local for translation,
>> or web for statistics) that would need to be gitified too. For
>> example, the Spanish team developed KSvnUpdater.
>> - Update lots of documentation in different languages (eg.
>> https://es.l10n.kde.org/repositorio.php)
>>
>> You may even need to migrate languages one by one (as you convince
>> each language team?), so in the meantime all tooling would need to
>> support both repos at the same time.
>>
>> It doesn't sound like fun...
>
> Thanks for the background.
> 
> If we're going to keep SVN, I think we need to fully support it. If we don't
> have the resources to do this on an ongoing basis, then we need to invest the
> resources now/soon to move away from it. I don't see any other realistic 
> options.

New resources is the solution. Please see the other emails: the problem
discussed is not subversion itself, but the web interface.

> 
> Again, from a totally non-translation perspective, I am somewhat surprised to
> hear that individual translators are required to be proficient in a source
> control system. Perhaps de-coupling the workflow from direct interaction with
> the SCM would be beneficial? Isn't this what GUI apps like KLocalize do? If
> not, can it be modified to do the SCM interaction? This seems like a solvable
> problem.

Most of translators are not so technical as the developers. And even
developers can shoot them in the foot with git, I see many issues coming from
unwanted merges.
Also, in addition to some of the problem described above (not all of them are
blocker IMHO), more relevant: how would you convert the SVN repositories into 
git?
- a unique repository would be the easier way, and required by people who do
changes to all the languages (renamed and moves) but I can only foresee tons
of merging issues when committing (see above).
- a repository per language would mean a tons of work whenever you need to do
a global operation, and right now it's a no go.


-- 
Luigi

Re: Reducing the load on Sysadmin

[Luigi Toscano]

KDE ha scritto:
> Hi,
> 
> It seems there is always seem to be someone within KDE that wants something
> new and shiny, I name gitlab, Discourse, a new identity system, etc.
> 
> On the flip side, there is always someone that does not want to part with the
> old stuff. 
> 
> Hence there is always more stuff to do, while we must also maintain all the
> old stuff.
> 
> Sometime you need a step back to create room to go two forward. We are just
> asking to think with us if some services are really needed.

This way of representing the reality is a bit of a stretch, to say the least.

Most of the proposals haven't raised any concerns.
No one is going to shed a tear on the demise of cgit.
Moving to static-generator all the websites which does not need to be dynamic
has been on the work for a lot of time, and it will continue.
And so on.

What's left? Some services which you may think have no users, but they really
solve problems.
API and EBN are probably not working in their current form, but something that
covers they use case is needed anyway. There is some discussion, it's likely

Of course, when you propose many changes it is expected to see that not all of
them may work as planned. That's why the discussion here is needed.

About dealing with old services: it does not automatically mean "let's cancel
them" but more "let's see if this is useful, and if it but we have workload
issues, let's find a way to make it work".

Talking about websvn, I'm pretty sure that there are various solutions and
some of them have been proposed. To summarize the need: we do reference websvn
from pointing out specific changes in emails or other channels. It can be done
for git changes, it should still be possible for other changes.

I has been said many times that recruiting new people for sysadmins is
difficult for trust reasons, but I'm pretty sure that there are some people in
the community who can be trusted by sysadmin right now. In fact there are
already people managing some of the services, not all of them, so I don't see
why it can't be done for other services.
Or is the set of people who are potentially trusted by sysadmins really empty?


To be honest, the replies I've seen so far (which I'm nevertheless grateful
for) looks more like point to point replies dismissing the proposals. What I'd
like to see are more "yes, this can't be done this way BUT we may consider
this.". Please try to help each other to find the solutions, keeping in mind
that may not always fit your original plan.

-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Sun, Nov 10, 2019 at 12:20 AM Luigi Toscano  
> wrote:
>>
>> Ben Cooksley ha scritto:
>>> Hi all,
>>>
>>> When KDE committed to performing a migration to Git back in 2010, one
>>> of the things that was agreed at the time was that translators could
>>> remain on Subversion to avoid disrupting their workflows.
>>>
>>> This however has led to a certain amount of additional infrastructure
>>> which Sysadmin needs to continue to maintain.
>>>
>>> In recognition of the fact that with few exceptions, everything has
>>> now migrated from Subversion aside from Translations, i'd like to
>>> reduce the level of infrastructure supporting our Subversion
>>> repository to the bare minimum necessary.
>>>
>>> This would include the shutdown of WebSVN in particular, which when
>>> coupled with the shutdown of our two CGit instances would also allow
>>> for us to eliminate an entire virtual machine from our systems.
>>
>> As websvn has proven to be useful, would it help the sysadmin (pending
>> agreement with aacid and the other people with root access on rosetta) to 
>> move
>> websvn to rosetta and under localization team's responsibility?
> 
> Unfortunately Rosetta does not have the necessary free disk space, as
> the Subversion repository is approximately 80GB these days in size,
> and operating WebSVN requires a full copy of the Subversion repository
> locally in order to operate.

Can we extend rosetta's disk then, or add an external volume?

In case it's not clear, I'd like to do everything possible to have websvn
still up.

-- 
Luigi

Re: Sysadmin Load Reduction: Code Related Services

[Luigi Toscano]

Ben Cooksley ha scritto:
> Hi all,
> 
> In the category of code related services, Sysadmin currently supports
> a wide-ranging number of services (which makes sense given the nature
> of the community). Some of these however may no longer be in use or
> will be duplicative of other services following the transition to
> Gitlab.
> 
> In the category of duplicative, we have our two CGit instances at
> cgit.kde.org and packaging.neon.kde.org. Prior to Gitlab, these were
> justifiable as there was no other way of browsing scratch/clone
> repositories over the web.
> 
> With the migration to Gitlab however all repositories will become
> browsable through it, meaning it no longer makes sense to offer two
> browsers that provide the exact same information (with Gitlab having
> greater capabilities). I'd therefore like to shut both of these down
> once Code Hosting has transitioned to Gitlab.

Luckily we tried to use commits.kde.org as generic redirect. Will the generic
redirect commits.kde.org be updated to point to the proper repository? It may
be complicated if the new structure contains the namespaces for each
repository, but we need to keep it working.

> 
> In the category of no longer in use, we have the compatibility
> generator for the kde_projects.xml file. This was introduced when we
> shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> keeping services that needed to discover a list of KDE Projects
> functional.
> 
> As we've since migrated to using YAML files within the
> sysadmin/repo-metadata repository for both the CI System and
> kdesrc-build (and with LXR using kdesrc-build to do it's code
> checkouts) there shouldn't to my knowledge be anything still relying
> on this (aside from perhaps scripty).>
> I'd therefore like to shut this generator down as well, along with the
> compaibility redirector running at projects.kde.org (given that it has
> been some time since we were using that site, and many projects have
> moved around in the virtual structure since then, making the redirects
> it is able to offer useless)

Two points:
- scripty still uses the XML file and we may need some time to migrate.
- we may have a few links around which still points to projects.kde.org (for
example, the "Consistency" goal listed a few of them), so we may need to go
through all of them before doing that.
Do we have measures that shows how much projects.kde.org is hit by services
which are not scripty?

-- 
Luigi

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Luigi Toscano]

Ben Cooksley ha scritto:
> Hi all,
> 
> When KDE committed to performing a migration to Git back in 2010, one
> of the things that was agreed at the time was that translators could
> remain on Subversion to avoid disrupting their workflows.
> 
> This however has led to a certain amount of additional infrastructure
> which Sysadmin needs to continue to maintain.
> 
> In recognition of the fact that with few exceptions, everything has
> now migrated from Subversion aside from Translations, i'd like to
> reduce the level of infrastructure supporting our Subversion
> repository to the bare minimum necessary.
> 
> This would include the shutdown of WebSVN in particular, which when
> coupled with the shutdown of our two CGit instances would also allow
> for us to eliminate an entire virtual machine from our systems.

As websvn has proven to be useful, would it help the sysadmin (pending
agreement with aacid and the other people with root access on rosetta) to move
websvn to rosetta and under localization team's responsibility?

Ciao
-- 
Luigi

Re: Licensing policy and Apache 2.0

[Luigi Toscano]

Jonathan Riddell ha scritto:
> I'm not against this but the downsides are:
> -it's yet another licence so would add confusion
> -it's incompatible with the GPL 2 so there's an increased risk of incompatible
> licences interfering with each other
> 
> It doesn't seem to cover any use case that isn't covered by the other
> permissive licences, it's just a bit more explicit about some of the detail.
> Can you say why you think it's useful?

I don't have a specific answer; just consistency with other (python) libraries
around.

It is not compatible with the GPLv2, but it is fully compatible with GPLv3.
(moreover, it has a patent promise).

-- 
Luigi

Licensing policy and Apache 2.0

[Luigi Toscano]

Hi,

right now the licensing policy does not contain the Apache 2.0 license:
https://community.kde.org/Policies/Licensing_Policy

While it may not be really useful for C++ code, the Apache 2.0 license is more
extensively used by the Python community, and it may be useful for
infrastructure scripts. For example, I have in mind a few Python-based scripts
for the i18n infrastructure and it may be useful to use it.

I feel that adding Apache 2.0 to section 5 of the licensing policy would be
enough for this, but of course we may want to create a special section to
restrict its scope, if we want to avoid its usage in C++ code.

Of course it may be possible to avoid it and just use pure MIT or BSD when
GPL/LGPL are not used.

What do you think?

Ciao
-- 
Luigi

Re: Invent/gitlab, issues and bugzilla

[Luigi Toscano]

Bhushan Shah ha scritto:
> Everyone, let's take a step back.
> 
> Original discussion was, if project X can use gitlab issues instead of
> bugzilla? If the developers/maintainers prefer?
> 
> Potential arguments to which are either,
> 
> - No they can't because we forbid it in our manifesto or code of conduct
>   or policies
> - No they can't because it makes life of other developer harder
> - No they can't because it makes life of other user harder
> 
> As we stand neither of this arguments apply ... We have no written point
> in KDE manifesto which allows community to force a developer tool of
> their choice on new or existing project, as long as tool or service is
> hosted within KDE infrastructure and doesn't cost sysadmins or community
> resources/time maintaining that service. It is important have this
> freedom, otherwise next day someone can come up with idea that all
> projects should use cmake or autotools or qmake, because all of KDE
> community should be using same buildsystem.

Sorry, but We did exactly this. We all switched to git for code. We all
de-facto switched to CMake for Qt-based projects, whenever is possible. And
there are good reasons for that.

> 
> - Gitlab is hosted on KDE infrastructure and each KDE contributors can
>   access the service using their KDE identity account.
> - Gitlab service is/will be actively maintained by KDE sysadmin team and
>   using it as bugzilla is not going to cost KDE e.V. any extra money.
> 
> If developer/maintainer collectively thinks that using gitlab as bug
> tracker makes their life easier instead of depending on bugzilla I don't
> understand why other developers would have a problem with that? It's not
> making their life difficult at all if they want to contribute, as
> mentioned in earlier point Gitlab is accessible to all users and
> developers.

It is important for the rest of the community, as I mentioned earlier (see:
consistency, and tooling). That's it.

> As for users, let users decide? I mean we can't speak for all of our
> userbase confidently that they love bugzilla and will stop reporting
> bugs for other components if certain other project/application starts
> using Gitlab for bugtracking, can either of you?

Users don't decide where to report bugs: they follow the instructions (I can
report countless of request of "where can I report this").
Having two places makes things confusing.


> 
> On Wed, Jul 03, 2019 at 08:37:34PM +0200, Boudewijn Rempt wrote:
>> Besides, it's already too easy to make a bug report. Getting more bug
>> reports is not a priority for me; at this I would prefer to have less
>> interaction between developers and users than more, because we're
>> going crazy right now.
> 
> This is your personal opinion.
> 
>> And that's the important thing. Bugzilla is a developer tool, not a
>> user tool. We must have easy tools to triage, query, sort, modify sets
>> of reports. Bugzilla isn't perfect for that either, but the options
>> gitlab gives for handling issues are so limited.
> 
> If bugzilla is developer tool, gitlab is also developer tool, let
> developer or maintainer decide how to best use it.
> 
> On Thu, Jul 04, 2019 at 10:20:34AM +0200, Boudewijn Rempt wrote:
>> On the other hand, we also need to use tools that make our work
>> possible. Me being able to do my work, my developers being able to do
>> their work is also important. These tools are not for marketing, they
>> are for making the development process go better. And not just for
>> newcomers, but also for the people actually shouldering the load of
>> triaging ~150 reports a month.
> 
> If Kaidan, Calindori or Plasma Mobile uses the Gitlab for issue reporting
> because of either a) choice of maintainer or b) choice of specific
> sub-community, that decision doesn't affect krita, okular or other KDE
> applications.

It does, as a global community.

> 
>> I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
>> gitlab's issues feature is not powerful enough to handle the amound of
>> bug reports I have to handle. In other words, I cannot do my work with
>> gitlab's issues feature. It might look more modern, but it just
>> doesn't have the power. 
> 
> This is your personal opinion.

Just like yours.



> 
> On Thu, Jul 04, 2019 at 10:39:15AM +0200, Christoph Cullmann wrote:
>> In our company we multiple times reviewed bug trackers (for migrating
>> from Bugzilla), but none actually had a good enough feature set to be
>> considered, beside perhaps Jira (which is non-free/open).
>>
>> I would wait for the Bugzilla 6 release to judge if the UI arrives in
>> the 21th century before making any decisions what to use. Just that
>> GitLab is more modern doesn't give it all the features one needs.
> 
> This is your personal opinion.

Do you mean that you don't want to evaluate the tools? Interesting.

> 
> In general, I respect everyone's personal opinion that bugzilla at
> moment superior to the gitlab issues, but at same time I also want to
> 

Re: Invent/gitlab, issues and bugzilla

[Luigi Toscano]

Boudewijn Rempt ha scritto:
> On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote:
>> On 7/3/19 11:53 AM, Albert Astals Cid wrote:
>>> If the new is much better than the old, let's just remove the old.
>>>
>>> As said, having two things that do the same is just confusing for everyone.
>>
>> I would tend to agree, and having two is super confusing.
> 
> But are they the same things? I need both user reports and developer 
> tasks/projects. The only task-like system github offers is the issues system, 
> isn't it? 

Yes, but my point is that gitlab issues have been used also for bugs so far.


-- 
Luigi

Invent/gitlab, issues and bugzilla

[Luigi Toscano]

Hi,

one of the main point of the gitlab migration has been so far the replacement
for phabricator. We didn't discuss about bug tracking.

Despite this, I've seen a few projects using issues as replacement for bugzilla.


We can all debate which is better, whether bugzilla or the gitlab issues, but
please consider that:

- having to ways to report a bug makes like of everyone more complicated for
users reporting bug who need to find the proper place, and for bug triager

- drkonqi still continue to report to bugzilla. Future versions of drkonqi can
be fixed to support the new system and we would need also a proxy for older
versions of drkonqi, but until such thing exist, a migration is out of question.


My suggestion right now is to disable issues completely, or if they need to be
enable to allow us to replace phabricator tasks, then to reduce their scope to
this.

-- 
Luigi

Re: Testbed Discourse Server For Trial discuss.kde.org.uk

[Luigi Toscano]

Nate Graham ha scritto:
> On 6/29/19 4:04 PM, Thomas Pfeiffer wrote:
>> Hi Jonathan,
>> Thank you for setting this up!
>> I've recently had the opportunity to experience Discourse in action in
>> another community, and found it to fulfill most of the things we found
>> lacking in both of our current forum and mailing list software (which
>> makes sense given that they're both age-old and haven't seen much - if
>> any - exciting feature development in years).
>> So I (personally, not speaking for the board) would really like us to
>> test it out and see if we can replace first our forum and hopefully some
>> day Mailman with Discourse.
>> Thanks,
>> Thomas
>>
> 
> +1, I'm also quite in favor of this. Having used it in other communities, I
> find that it works well as a sort of half-forum-half-mailing-list tool that
> can succeed in replacing both.

I may have already asked this: do we have a plan to evaluate also hyperkitty
(mailman 3 frontend) before completely replacing also the mailing lists? It
provides a forum-like interface.

-- 
Luigi

Re: Licensing policy change proposal

[Luigi Toscano]

Mirko Boehm (KDE) ha scritto:

Hello,

On 28. Jan 2019, at 13:23, Krešimir Čohar > wrote:


I don't think there are any problems with using public domain images, and 
even if there were I'd rather view them as challenges to overcome than 
obstacles to avoid.


This is not necessarily a question of what we think. This is a question of 
what we as a community can and should distribute. For that, we need at least 
explicit permission from the author, as in a FOSS license. There has been a 
very long debate on the use of public domain works in FOSS, and the summary 
AFAIK is “it is complicated” and “it depends on the jurisdiction”. A great 
summary can be found here: https://opensource.org/node/878: "an open source 
user or developer cannot safely include public domain source code in a project."


But the same article says that CC0 was born to overcome the complexity of the 
definition of the public domain in different jurisdiction. It also says that 
CC0 was not OSI-approved, thought.


Ciao
--
Luigi

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Luigi Toscano]

Luigi Toscano ha scritto:

Andrew Crouthamel ha scritto:
I've been spending a lot of time browsing, searching, and filtering our bugs 
in Bugzilla. One of the areas I've found that could use improvement, are the 
NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting 
additional information or backtraces, never to be updated again. We have 
NEEDSINFO bugs dating back to 2009.


Hi,
the (semi)automated process which pings and then closes NEEDINFO bugs was 
implemented, but I've noticed another policy which was never discussed (as far 
as I know) here: bugs opened for a while

(sorry) ... are switched to NEEDINFO.



I disagree with this policy, and I'm not alone (at least another maintainer 
asked for his product to be excluded):
- not all projects distinguished between CONFIRMED and UNCONFIRMED (now 
REPORTED), so it's possible that a perfectly valid bug or request (especially 
requests) seems stale. You may say that it's easy to flip the status again. 
I'd say that it's a unneeded step.
- at most the script could add a new comment asking for updates, but not 
immediately change the status out of the blue.

- as mentioned, it was not discussed.

Please disable it for now, or just enable it for projects who explicitly wants 
it for now.



--
Luigi

Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Luigi Toscano]

Andrew Crouthamel ha scritto:
I've been spending a lot of time browsing, searching, and filtering our bugs 
in Bugzilla. One of the areas I've found that could use improvement, are the 
NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting 
additional information or backtraces, never to be updated again. We have 
NEEDSINFO bugs dating back to 2009.


Hi,
the (semi)automated process which pings and then closes NEEDINFO bugs was 
implemented, but I've noticed another policy which was never discussed (as far 
as I know) here: bugs opened for a while


I disagree with this policy, and I'm not alone (at least another maintainer 
asked for his product to be excluded):
- not all projects distinguished between CONFIRMED and UNCONFIRMED (now 
REPORTED), so it's possible that a perfectly valid bug or request (especially 
requests) seems stale. You may say that it's easy to flip the status again. 
I'd say that it's a unneeded step.
- at most the script could add a new comment asking for updates, but not 
immediately change the status out of the blue.

- as mentioned, it was not discussed.

Please disable it for now, or just enable it for projects who explicitly wants 
it for now.


--
Luigi

Re: Improving Bugzilla Status Names

[Luigi Toscano]

Kai Uwe Broulik ha scritto:

Hi,

 > Here is my follow-up change recommendation based on feedback and research:
 >
 > UNCONFIRMED -> REPORTED
 > WONTFIX -> INTENTIONAL
 > INVALID -> NOTABUG

one issue I'm having with "REPORTED" is that it shows up as "REPO" in the list 
and can easily be confused with "REOP" for "REOPENED". Perhaps we need 
something different for Reopened then.


If we rename also that, we would have two bug names diverging from the other 
bug trackers, instead of just one. Moreover I find that there is no much to 
discuss on the appropriateness of REOPENED.
I'd rather find an alternative for REPORTED, if this confusion is going to be 
an issue.


--
Luigi

Re: Improving Bugzilla Status Names

[Luigi Toscano]

Nate Graham ha scritto:

On 09/23/2018 03:40 AM, Elvis Angelaccio wrote:

On sabato 22 settembre 2018 17:31:31 CEST, Nate Graham wrote:


e.g. RESOLVED WONTFIX and RESOLVED INTENTIONAL both mean the same thing 
("We won't be implementing this").


I'm not sure how "intentional" mean the same thing as "will not fix".


RESOLVED WONTFIX begs the question: "why won't you fix it"? Also, some users 
would mentally add "are you lazy? do you hate me?" and become offended.


I'm sure that some users will challenge the reason of INTENTIONAL ("are you 
nut? This is not how it should work").


Regardless of the reason, a status is just the most concise summary. For any 
closing states, the developer should write down the reason in the last 
comment, so that users can check the explanation for it (and make a WONTFIX 
not scary, like any other final status).




There are a few reasons why a bug would previously have been closed as 
RESOLVED WONTFIX:


- Because the software has been designed this way on purpose, so a change is 
undesirable: REVOLVED INTENTIONAL covers this


- Because it is technically impossible to fix: essentially the same thing; 
software was designed in that way, so RESOLVED INTENTIONAL is still appropriate


So those have the same meaning.



- Because the developer just doesn't feel like doing the work: not a valid 
reason to close a bug; bug should stay open


- Because the developer wishes to spitefully punish the bug reporter for 
behaving badly in the ticket, and in the process hurts all KDE users who could 
benefit from a better resolution: not a valid reason to close a bug; bug 
should stay open


I think that in both cases the RESOLVED WONTFIX should not be used, and at the 
same time nothing prevents developers to use it just because it's called 
INTENTIONAL, which means a complete equivalence of the two states.


If the reason for this change is prevent the 4th case, I'm not sure it's going 
to help.




So I think REVOLVED INTENTIONAL covers all of the valid reasons to close a bug 
report that the developers will not or cannot fix.


At least, that's what makes sense to me.

I'm not specifically attached to this change, so *I'm fine with keeping it as 
it is.*


I would point out that the similar "Opinion" status on launchpad has been 
challenged:

https://help.launchpad.net/Bugs/Statuses
https://bugs.launchpad.net/launchpad/+bug/772954

I agree that this entire discussion was rushed out.

--
Luigi

Re: Call for contributors for Fixture [ Qt5 based raster graphics editor ]

[Luigi Toscano]

Andy B ha scritto:
Can you guys maybe now move this discussion to telegram or phabricator? It 
seems that there is good debate and good will.


I'm not sure why this discussion should be diverted from a mailing list to a 
messaging system (*) and a planning and development system like phabricator.


Maybe (just maybe) it can be be moved to a more appropriate mailing list.

(*) let's not use "telegram" as synonym for "messaging system", please.

--
Luigi

Re: pseudonymous contributions to KDE

[Luigi Toscano]

Jonathan Riddell ha scritto:

On Wed, Sep 19, 2018 at 06:38:15AM -0400, Adriaan de Groot wrote:

On Wednesday, September 19, 2018 6:02:22 AM EDT Luigi Toscano wrote:

Jonathan Riddell ha scritto:

On Tue, Sep 18, 2018 at 07:38:35PM +0200, Jos van den Oever wrote:

Can one sign a Fiduciary License Agreement under pseudonym?


Same as above on the whole.  At least in Scotland there's no
restrictions on what name you chose to use for any purpose as long as
it's not for fraud.


Can we talk to lawyers and other coding communities? This is not something
that can be decided just thinking about "more contributions".


The FLA is an agreement between a German organization (that is, the KDE e.V.)
and the licensor (that is, the contributor who is handing the fiduciary
license to the licensee). That makes Scottish norms irrelevant -- and part of
this discussion, too, since it's about what the *e.V.* will (or can) accept. I
don't know if the FLA contains, off-hand, choice-of-jurisdiction phrasing.
It's certainly something to discuss with one of our tame lawyers (who are not
our lawyers in a formal sense).


This question has two parts, code contributions and FLA.  Code
contributions are public and we could easily allow psudonames there
but not for FLA which is just a bit of paper in a filing cabinet
somewhere.  This would allow for privacy and German court happyness.


Not exactly, because the difficult case is handling license issues for people 
who did not sign the FLA.


Again, this requires input from lawyers.

--
Luigi

Re: pseudonymous contributions to KDE

[Luigi Toscano]

Christian Loosli ha scritto:

Am Mittwoch, 19. September 2018, 12:02:22 CEST schrieb Luigi Toscano:


Same as above on the whole.  At least in Scotland there's no
restrictions on what name you chose to use for any purpose as long as
it's not for fraud.  Obviously the harder it is to prove a name
matches to a real person the harder it would be to test in a
worst-case-scenario court case but I think limiting it would just
limit our contributions for no good reason.


The possibility of a court case (and all the complications related to
copyright laws) is a good enough reason.


I have seen at least 4 FOSS projects with the opposite problem:
a specific person using that info to harass people, including:

- calling them at their home
- slandering their name, including false accusations most horrible crimes
- calling their employers and families, trying to get them in trouble


That's very bad. But:


so I understand every person who prefers to work under a pseudonym and I think
we should not make this impossible.


Does it make impossible any future changes related to the software license 
(from a simple relicensing to handling legal actions)? If the answer is no, 
then it's sad but we can't fix the laws just by coding and sometimes even 
shouting (see the EU reform).


--
Luigi

Re: pseudonymous contributions to KDE

[Luigi Toscano]

Jonathan Riddell ha scritto:

On Tue, Sep 18, 2018 at 07:38:35PM +0200, Jos van den Oever wrote:

Hi all,

What is the KDE policy on accepting code contributions under pseudonym? I've
gotten review requests on Rust Qt Binding Generator under a pseudonym. Now I
wonder if I can accept the contribution. The contributor has, under pseudonym,
a KDE account.


I don't see why not, we are nerds and for whatever reason lots of
nerds like to use pseudonym, shutting that off would just limit our
contributions for no good reason.


Then what are other communities doing? The Linux kernel has a stricter policy 
(with Signed-off-by footer).





Can one sign a Fiduciary License Agreement under pseudonym?


Same as above on the whole.  At least in Scotland there's no
restrictions on what name you chose to use for any purpose as long as
it's not for fraud.  Obviously the harder it is to prove a name
matches to a real person the harder it would be to test in a
worst-case-scenario court case but I think limiting it would just
limit our contributions for no good reason.


The possibility of a court case (and all the complications related to 
copyright laws) is a good enough reason.


Can we talk to lawyers and other coding communities? This is not something 
that can be decided just thinking about "more contributions".


--
Luigi

Re: Closing NEEDSINFO bugs after 30 days

[Luigi Toscano]

Harald Sitter ha scritto:

On Tue, Sep 18, 2018 at 12:59 PM Boudewijn Rempt  wrote:


Would it also be possible to automatically remove the needinfo status if the
reporter adds a comment after it's set to needinfo?


Yes.




I know that this proposal was rejected in the past, but if the needinfo flag 
is used instead of a separate NEEDINFO status, the flag is removed 
automatically when the person set in the needinfo flag answers:


https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Needinfo

--
Luigi

Re: Deleting https://userbase.kde.org/Krita/Manual

[Luigi Toscano]

On Tuesday, 12 June 2018 05:51:08 CEST Yuri Chornoivan wrote:
> понеділок, 11 червня 2018 р. 23:00:55 EEST Boudewijn Rempt написано:
> > This version of Krita's manual is dead. It's outdated, it's not even
> > pushing up the daisies, it's been decomposed too much to aid any daisy in
> > its growth and flowering. How can we can completely eradicate it? I
> > haven't found a way myself...
> 
> Hi,
> 
> The correspondent rights are now given and you can delete the pages. Just
> click the gear button at the top left and choose "Delete". Or just tell me
> what to delete.

I'd suggest to set a link to the new documentation in place of the old page, 
so that the existing links can still have some meaning.

Ciao
-- 
Luigi

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Luigi Toscano]

Adriaan de Groot ha scritto:
> On Tuesday, 10 April 2018 19:18:07 CEST, Nate Graham wrote:
>> OPEN -> Nobody's looked at it yet
>> TRIAGED -> Somebody looked at it but couldn't reproduce it yet
>> CONFIRMED -> Somebody looked at it and was able to reproduce it
>>
> 
> Is bugzilla really that hard to configure with a workflow? I ran into this
> recently with the FreeBSD bugzilla as well, where I needed extra information
> and this might be encoded into some fields -- but not into the status field,
> which is infuriatingly "new", "open", "in progress", "closed".

You can, iirc. It's more a human problem with the policy.

http://bugzilla.readthedocs.io/en/latest/administering/workflow.html


See my previous attempt on this list:
https://mail.kde.org/pipermail/kde-community/2016q4/003262.html

-- 
Luigi

Re: do you need www.kde.org write access?

[Luigi Toscano]

Aleix Pol ha scritto:
> On Fri, Mar 9, 2018 at 5:57 PM, Ilya Bizyaev  wrote:
>>  On Thu, 08 Mar 2018 11:23:08 +0300 Sebastian Kügler 
>> wrote 
>>
>> That's part of what we need to review: is the new site missing relevant
>> things which need to be migrated? It's something we can surely fix.
>> --
>>
>> The part I am personally concerned about is translations. I see that
>> announcements got imported, but there seems to be no way to view
>> announcements in a different language.
>>
>> Compare:
>> https://www.kde.org/announcements/plasma-5.12.0.php?site_locale=ru
>> https://www-backstage.kde.org/2018/02/06/plasma-5-12-0/
>>
>> Will the translation history be preserved and used?
>>
>> Cheers,
>> Ilya.
>>
> 
> There's no intention to remove translations. Texts will possibly
> change, especially if the promo team starts working on the website
> again.
> If you really are concerned, I suggest you step forward and help make
> sure it's integrated as it should.

That's finally a news. Are there any details so far on how the translation
workflow will be implemented?

-- 
Luigi

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Luigi Toscano]

On Wednesday, 28 February 2018 10:32:58 CET Boudewijn Rempt wrote:
> On Wednesday, 28 February 2018 00:14:30 CET Luigi Toscano wrote:
> > On bugzilla.redhat.com some teams use the Triaged keyword. I think it
> > would
> > be a good solution.
> 
> I've been trying that, and it just doesn't work for me, like I said in my
> first mail to this thread. It doesn't work because it's a tag separate from
> the status of the report: tried-but-could-not-reproduce-yet is a state, part
> of the flowchart, not a tag. The state should change once the bug could be
> reproduced, or is resolved.

I disagree and I think it makes sense as keyword, as general attribute of the 
bug (something happened according a triaging process). It is a modifier of the 
"NEW"/initial state that is brought around later.

-- 
Luigi

Re: FOSDEM retrospective

[Luigi Toscano]

Nicolás Alvarez ha scritto:
> 2018-02-05 20:33 GMT-03:00 Luigi Toscano <luigi.tosc...@tiscali.it>:
>> And we can use also phabricator (again, only Akademy):
>> https://phabricator.kde.org/calendar/export/3/
> 
> It says you're the only one with permissions to access that link.
> 


Uh, right. But I should be able to share the URL for the dynamic ics:
https://phabricator.kde.org/calendar/export/ics/mw4fmpmomz5pom4hgyg2/events_meeting.ics

-- 
Luigi

Re: FOSDEM retrospective

[Luigi Toscano]

Albert Astals Cid ha scritto:
> El dimarts, 6 de febrer de 2018, a les 0:15:21 CET, Lays Rodrigues va 
> escriure:
>> Hello Adriann, thanks for the report!
>> We could have a calendar of events where KDE will attend, and work with
>> Promo before them to set up material and promo actions.
> 
> We already have such a calendar, it's just not filled in (except Akademy)
> 
> https://calendar.google.com/calendar/embed?src=mtlqg95e4gnoq8qjv0os91iro0%40group.calendar.google.com
> 

And we can use also phabricator (again, only Akademy):
https://phabricator.kde.org/calendar/export/3/

(even if there is an open discussion: https://phabricator.kde.org/T7835 )


-- 
Luigi

Re: bugzilla, it's products, how they relate to projects. it's a mess...

[Luigi Toscano]

On Wednesday, 31 January 2018 16:15:41 CET Boudewijn Rempt wrote:
> On Wednesday, 31 January 2018 15:44:01 CET Nate Graham wrote:
> > >> As Nate has now attained demigod status with his usability blog posts,
> > >> I
> > >> think it would be good to take advantage of all the positive attention
> > >> and tie it into one of the other goals "Streamlined onboarding of new
> > >> contributors". The point has to be hammered home: "If you love some
> > >> dev,
> > >> set them free of the burden of bug triage".
> > > 
> > > Yes, that would be very good!
> > 
> > Working on it now! "Demigod status," I like that...
> 
> And I've started a short how-to-triage-a-bug manual draft:
> 
> https://phabricator.kde.org/T7842

For the record, we have documentation about this. We just don't have an active 
BugSquad team around as it was before:

https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

https://community.kde.org/Bugsquad

-- 
Luigi

Re: Splitting Craft, move the recipes to GitHub

[Luigi Toscano]

On Wednesday, 23 August 2017 15:33:09 CEST Hannah von Reth wrote:
> Hi everyone,
> 
> We have been thinking about splitting the Craft recipes into a separate
> repository for some time now.
> To have a Craft core and the recipes separated would enable us to
> provide more stable user experience. It would allow us to use the latest
> recipes with the stable core.
> 
> At the same time Craft tries to get rid of the image as the KDE Windows
> build tool.
> 
> Craft offers recipes for many libraries and non KDE applications.
> Additionally Craft offers support for Mac, Linux and FreeBSD.
> 
> In order to reach more people we intend to move the recipes to GitHub to
> enable non KDE contributors to add their recipes.
> Craft would continue to be a KDE Project on the KDE infrastructure, only
> the recipes would move.

Does it mean that people who want to contribute to recipes for applications 
developed by KDE should go to github?


This is more or less the same as saying "so to get rid the image of kdelibs, 
let's put Frameworks on github only".


I'm a bit sad.


-- 
Luigi

Re: radical proposal: move IRC to Rocket.Chat

[Luigi Toscano]

While I generally agree with your feeling that the feeling for IRC was a bit 
negative, I disagree here:

Il 10 agosto 2017 22:34:19 EEST, Christian Loosli  ha scritto:

>
>If people want to switch themselves: already possible, with or without
>this 
>thread and the etherpad. 
>
>The original topic of this thread is _move_ to rocket, and the title of
>the 
>etherpad is to find an IM that suits people best. So either you want to
>
>switch, then the cornerns of the people mentioned are fully valid, or
>you 
>don't, then you already have everything and the whole thing is
>pointless  

The topic is what it is because of how it started but the etherpad is still 
useful. Even if more bridges are available, maybe it is possible to choose one 
of them as primary or preferred, where invest in terms of client or support on 
the server side or whatever. 

Ciao

-- 
Luigi

Re: radical proposal: move IRC to Rocket.Chat

[Luigi Toscano]

Il 10 agosto 2017 22:22:04 EEST, Thomas Pfeiffer  ha 
scritto:
>On Donnerstag, 10. August 2017 20:38:11 CEST Christian Loosli wrote:
>> Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas
>Pfeiffer:
>> > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli
>wrote:
>> > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan
>Riddell:
>> > > > LibreOffice are having a similar discussion
>> > > > 
>> > > >
>https://listarchives.libreoffice.org/global/projects/msg02257.html
>> > > > 
>> > > > They want to continue using IRC though which means
>fragmentation would
>> > > > continue.
>> > > 
>> > > Maybe someone should inform them that there are bridges available
>to
>> > > avoid
>> > > that.
>> > > 
>> > > But maybe they'd simply ignore that, multiple times, and go on,
>as some
>> > > people seem to do in this thread as well *shrug*
>> > 
>> > Who ignored the possibility of bridges?
>> 
>> Why are we still discussing, then? As I pointed out twice: bridges
>not only
>> exist, but they are already in place. So unless people want to get
>rid of
>> IRC (or one of the other protocols, for that), it is pointless to
>discuss
>> which client/protocol to take, since it already either is bridged or
>not
>> bridgeable yet, but soon to be.
>> And then the answer is clearly  "IRC plus bridge", and both this
>whole
>> thread and the etherpad can be abandoned.
>
>Erm... no. IRC is a "legacy option" for people who don't want to use
>other 
>protocols for whatever reason. That is perfectly fine for them, that's
>why 
>we're keeping it.
>
>However, if the people who _do_ want to use something more modern end
>up using 
>10 different things, then the benefits are practically non-existent.
>Most of 
>the nice features of modern protocols work only among those who use the
>same 
>one.
>
>Therefore, to get any benefit, we, the people who want something
>modern, have 
>to agree on one thing. You, the old-school IRC lovers, can feel free to
>
>completely ignore us while we search for something that checks all our 
>requirements, we bridge it to IRC, everybody is happy.
>Does that sound like a plan? 

I'm glad that this is the idea. But let me point out that in your original 
proposalof requirements:

https://mail.kde.org/pipermail/kde-community/2017q3/003693.html

the bridges are in the section "Nice-to-haves" and not "Must-have". I also find 
the description a bit too much on the negative side:

"For the transitional period or for people who just refuse to change their 
habits"

This is one of the reasons why there seems to be a "ditch IRC" idea. Happy to 
hear that it's not the general feeling.

Also:
>
>I, for one, did not chime into this discussion because I wanted to get
>rid of 
>IRC. I chimed in because I got the impression from some of the replies
>that 
>there would be no need to use anything other than IRC, because it has 
>everything we need.
>I still strongly disagree with that.

My impression is that everyone who advocated for IRC is saying: as long as it 
is bridged and functional I don't care about what other technologies can be 
used to access it, while I may disagree on the definition of obsolete.




-- 
Luigi

Re: github, phabricator: a new threadZ

[Luigi Toscano]

Il 10 agosto 2017 11:45:14 EEST, Harald Sitter  ha scritto:
>Seems to me y'all aren't appreciating that I am telling you my point
>of view. 


One thing is say "adding an easier workflow for scratch repo to our infra is 
much required for this and that", which I can agree too; another is going 
straight to something that seems more like to "ready to kill our infra anytime".

> I have created some 20 repos on github last year and 0
>scratch repos on our infrastructure. I thought you might want to know
>why. Feel free to find my reasons silly, that doesn't change them
>though.

I don't find your reasoning silly, as I wrote above. Hyperbole(s?) are fine but 
maybe distracting in an already complicated discussion.


-- 
Luigi

Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)

[Luigi Toscano]

Il 10 agosto 2017 10:24:08 EEST, Martin Steigerwald  ha 
scritto:
>Martin Klapetek - 09.08.17, 16:12:
>> > But KDE is not a tech startup. As people correctly wrote, KDE has a
>very
>> > long
>> > history and contributors of all age. I'd rather be that than one of
>the
>> > many
>> > tech startups with a bunch of little to no experience but fancy new
>chat
>> > systems, to be honest.  Do we really want and need to cater these
>mystical
>> > tweens so much?
>> 
>> Yes. Old contributors will slowly fade away for various
>> reasons, be it life, be it lack of energy, be it other commitments.
>> Who's going to pick all those projects up after them? I'd like
>> to think that young enthusiasts with lots of energy and potential,
>> exactly what those heroes starting the original KDE were.
>> And I think we should strive to attract younger talent that can
>> be in it for the long run.
>
>Well, I wonder since reading several posts here about one thing:
>
>To from reading this post and other posts I got the impression that is 
>absolutely needs to be black or white:
>
>*Either* IRC and nothing else *or* something new and nothing else.
>
>Seriously?
>
>I mean: Seriously?
>
>
>There has been almost completely unnoticed posts mentioning bridges. Is
>none 
>of this bridges capable to work well enough for KDE community use
>cases?

I see it differently; I see people wanting something that also works with IRC 
(so bridges, starting with the ones that already works) and people that don't 
want IRC even if it's working in the background without then having to care 
about it.


>
>Why do you see the need to exclude either one of the groups?

Exactly my point.


-- 
Luigi

Re: github, phabricator: a new threadZ

[Luigi Toscano]

Il 10 agosto 2017 10:02:43 EEST, Harald Sitter  ha scritto:
>I for one would pick the alternative which is not using our
>infrastructure and instead click two buttons so I don't have to file
>paperwork manually nor have to wait for said paperwork to get faxed to
>HQ for approval. i.e. not waiting trumps waiting in my world.
>

Nothing technically prevents this from implementing this in oir infrastructure, 
nor what Albert wrote hints at this: he just reported the current plan. Plan 
can be changed.

I don't understand the need of "let's trow everything out of.the window" 
instead of "let's extend what we have" (same goes for the proper IM discussion)

Let me requote:

>On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid 
>wrote:
>> That was not the plan, the plan (unless it has changed since last
>time i
>> asked) is to have a team of "trusted people" that can create repos on
>> phabricator, so basically you'd open a ticket and you'd get a repo
>created in
>> a matter of minutes, not automagic, but surely you can continue
>coding for 15
>> minutes while you wait for your repository to be created.
>>
>> Cheers,
>>   Albert


-- 
Luigi

Re: radical proposal: move IRC to Rocket.Chat

[Luigi Toscano]

Il 08 agosto 2017 19:09:28 CEST, Eike Hein <h...@kde.org> ha scritto:
>
>
>On 08/09/2017 01:16 AM, Luigi Toscano wrote:> We have an alternative
>already working, which bridges IRC (freenode.net and
>> OFTC): matrix.org.
>> I don't know how many times I should repeat this, but many people are
>already 
>> using successfully (I monitor few channels, for example).
>> 
>> So -1 for moving to Rocket.Chat.
>
>
>It could make sense to promote Rocket.Chat over Telegram though (more
>free).

I'm personally for ditching Telegram in favor of really FLOSS (and sane) 
alternatives. That said, if it's bridged to IRC as it happens now, I don't care 
much as long as the accessibility through IRC (and now matrix) is well visible. 
I would never promote Telegram standalone.

Can rocket.chat be bridged too? If not, promoting it would create another 
island.

Ciao

-- 
Luigi

Re: radical proposal: move IRC to Rocket.Chat

[Luigi Toscano]

On Tuesday, 8 August 2017 17:52:00 CEST Jonathan Riddell wrote:
> Like all sensible open source communities we use IRC lots for real
> time communication essential to making low bandwidth decisions in a
> reasonable timeframe as well as socialising.
> 
> 20 years ago IRC was cool but these days real-time communication in
> the non-geek world long since moved other places such as WhatsApp,
> Facebook Messenger which are infinately more user friendly than IRC.
> In the geek-world it has moved to Slack and Telegram. So KDE finds
> itself spread between three real time communication methods with IRC
> still the strongest but many new people reluctant to use it as scary
> and unfamiliar while Slack and Telegram smell of being proprietary and
> lacking some of the free-form nature of IRC.
> 
> So my radical proposal for today is to consider moving all our
> real-time communications wholesale to Rocket.Chat. Like Slack it takes
> much of it's basic setup from IRC with #channels that anyone can set
> up. Unlike Slack it's all free software and we can run our own
> servers.  Like Telegram it works on phones fine. Unlike IRC it
> supports media files and friendly user names.

We have an alternative already working, which bridges IRC (freenode.net and 
OFTC): matrix.org.
I don't know how many times I should repeat this, but many people are already 
using successfully (I monitor few channels, for example).

So -1 for moving to Rocket.Chat.

-- 
Luigi

Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Sat, Jul 29, 2017 at 11:33 PM, Luigi Toscano
> <luigi.tosc...@tiscali.it> wrote:
>> Ben Cooksley ha scritto:
>>
>>> I've checked and it appears that only a small handful of applications
>>> still use newstuff.kde.org:
>>> - KBlocks
>>> - KDiamond
>>> - KGoldRunner
>>> - Kigo
>>> - KSirk
>>> - KSnakeDuel
>>> - KSysguard
>>>
>>> These applications should all be ported to use store.kde.org.
>>
>> We have few days to fix most of them (the games part of Applications 17.08.0;
>> KSysguard is Plasma). Can you wait please few days so that we can fix them
>> properly (and compare the before/after)?
> 
> The web interface for newstuff.kde.org has been down for the past
> couple of months, so these applications should have been broken for a
> while now. We certainly can wait for a couple of days though.

Ben confirmed on IRC that the web server was up for few days by accident after
a system restart. So when I tested the affected games few days ago during
Akademy and everything worked, I thought that the issue was fixed.

I requested the new categories for the games, including few answer on how to
migrate the existing contents without contacting each of the old authors:
https://phabricator.kde.org/T6675

I didn't create it the request for KSysguard because I'm not sure about the
category, it's better if the Plasma team chimes in.

Ciao
-- 
Luigi

Re: Retirement of SVN Commitfilter and Legacy Get Hot New Stuff systems

[Luigi Toscano]

Ben Cooksley ha scritto:
> Hi all,
> 
> Last year sysadmin was given access to the system which hosts the SVN
> Commitfilter (which lived at commitfilter.kde.org) and the predecessor
> to the OCS network of sites (now store.kde.org).
> 
> Earlier this year we started having some issues with that system
> courtesy of some bots. As a consequence of this the web server
> component of the machine was disabled then to limit issues it was
> causing for the hoster.
> 
> Due to the age of the system and the limited use of the two services
> hosted on the system (with SVN Commitfilter having very limited
> application since our migration to Git) we've determined that the best
> course of action is to archive both services and shutdown the machine.

(I think that the answer is "no", but): does it affect that IRC notifications?

It's worth noting that when we will switch to Phabricator for handling SVN
too, we could build something around it instead of some custom code.

> I've checked and it appears that only a small handful of applications
> still use newstuff.kde.org:
> - KBlocks
> - KDiamond
> - KGoldRunner
> - Kigo
> - KSirk
> - KSnakeDuel
> - KSysguard
> 
> These applications should all be ported to use store.kde.org.

We have few days to fix most of them (the games part of Applications 17.08.0;
KSysguard is Plasma). Can you wait please few days so that we can fix them
properly (and compare the before/after)?

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

On Monday, 17 July 2017 18:01:39 CEST Martin Flöser wrote:
> Am 2017-07-17 17:47, schrieb Jonathan Riddell:
> > I propose to make this final if there's no further comments.
> 
> as I explained: I think the review process should be removed, playground
> should be removed.
> 
> There were both people supporting the idea and people being against.
> Given that I don't think there is a consensus yet.

That's true, but if the proposed image is a better representation of the 
status quo than the currrent image, it could at least be used in place of the 
old one, and the discussion can proceed.

-- 
Luigi

Re: latest draft for mission (and strategy)

[Luigi Toscano]

Alexander Neundorf ha scritto:
> On 2017 M07 5, Wed 15:05:26 CEST Clemens Toennies wrote:
>> On Jul 5, 2017 13:14, "Sebastian Kügler"  wrote:
>>> Should we make privacy our main focus for the next 5 years?
>>
>> How about Freedom?
> 
> The "KDE - Digital Freedom" is one of my favourite T-shirts...
> Still, there exists already a software organizatio which has freedom as its 
> main goal: GNU.
> So, I think that's too broad for KDE.
> 

On the other side, KDE e.V. is Associate Member of FSFE.

-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Martin Flöser ha scritto:
> Am 2017-07-04 13:20, schrieb Jonathan Riddell:
>> The applications lifecycle policy needs an update
>>
>> Is this a good current state of it or are there more stages?
>>
> 
> Hi all,
> 
> I'm now going to propose a rather radical change to the process:
> 
> 1. Remove extragear
> 2. Remove playground
> 3. Remove the 2 week Review process
> 
> Let me explain the reasoning.
> 
> [...]
Interesting, an annotation on this point:

> 
> Today I think there are way better things to measure the quality than a two
> week process on kde review:
> 
> * how many unit tests does a project have?
> * how large is the test coverage?
> * how often do tests fail on build.kde.org?
> * how often does the build fail on build.kde.org?
> * is it translated?
> * does it have appstream data?
> * is the code getting reviewed?
> * is the project a one person show?
> * ...
> 
> So instead of a one time review I would propose a continuous review of the
> projects and make it available in an easy accessible way so that users can
> also see the objective quality of the application. And yes that would mean
> that many long standing applications would have a way lower quality than the
> new kids on the block.
> 
> For KDE Applications, Plasma and Frameworks I expect to have additional rules
> for integration. Frameworks already has them, Plasma kind of has them, but I
> think they are not codified and KDE Applications could e.g. start with the
> current review process.
> 
> So to sum it up: I don't think there is a need for extragear and playground
> any more. When a project starts it should have the same rights and obligations
> as any other current extragear app. In addition we should come up with
> measurable quality facts and make them available to the community.

This is different from what Christian said (the "dumping ground is fine even
if some details are not relevant"). This process would make clear that not all
repositories are the same, and that's fine.

But please, if we end up going this way, make sure that we have the
measurement report/dashboards in place for all projects *before* changing the
workflow.

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Boudewijn Rempt ha scritto:
> On Wed, 5 Jul 2017, Martin Flöser wrote:
>> Extragear: to me extragear is a relict from the time of the big one KDE svn
>> trunk repository. There was "KDE" and everything else, aka. extragear. When I
>> started to compile KDE software it looked to me like something created from
>> the needs of SVN. A technical thing. Now we have git and we have split up all
>> those parts which used to be KDE, except for extragear. Where is the
>> difference between Krita (to my knowledge not part of extragear), 
> 
> It isn't -- for some reasons I don't exactly understand, it's still part of
> calligra in some kind of hierarchy, though not in the repo.

Clarification about this point: it was in a hierarchy because porting
(internal) the tool out of the hierarchy needs manpower which is not around,
so Krita needed a place, and it was easier to keep it under the "calligra"
namespace. That said, in the internal place where it is required, it can be
moved to extragear-graphics. Again, only important until some work is done.

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Harald Sitter ha scritto:
> On Wed, Jul 5, 2017 at 7:01 AM, Christian Mollekopf

>>From where I am standing we should have a stage before playground.
> Scratch repos if you will (although those are slated for deprecation
> without replacement). This addresses the code-dumping github-like use
> case, no tickets, little overhead. If it doesn't work out you throw it
> away. This gives us an actual playground: "I need no translations, no
> CI, no nothing, I am prototyping here" (think pre-alpha). From there
> it can proceed to playground (alpha stage). This is automatically a
> submission for continuous(?) casual review. It is at this point under
> joint ownership so we ought to assert our policies hence the casual
> review. Once ready (as determined by the authors) it moves to
> frameworks/plasma/applications.
> I understand this is a bit of a hippie workflow, but think about it
> this way: the reason we don't just review playground is that it's
> potentially little to no code and/or heavily rotating code, neither of
> which makes it easy to do a review. If the software is out of initial
> protoyping we have code to review and it's far less rotating already
> (the degree of rotation matters little, as the assumption continues to
> be that once we assert our policies they will get continuously
> implemented by the author). At the same time this removes almost all
> the policy overhead of moving from playground to the final
> destination. The code is already reviewed, all it takes is a ticket to
> become a proper application.
> 
> TLDR: instead of making people not get too comfortable in playground
> make them more likely to want to move to applications (by making that
> super easy)

My first question after reading is: what is the difference between
playground -> kdereview -> other
and
scratch -> playground -> other
?

Still a 2 phase process. Maybe the only change is that playground would be
less time limited than the current kdereview.
I would say that moving from scratch -> playground would be probably
announced, like the current move to kdereview; I only fear that a more
implicit (even if announced) call to review would be less effective than the
current one (with all its limitations).

-- 
Luigi
> 
> HS
> 

Re: Applications Lifecycle Policy

[Luigi Toscano]

Christian Mollekopf ha scritto:

> Overall I just find the cost/benefit factor in the beginning of a
> project not at all good when using KDE infrastructure.
> I have to request repos and can't just create them, I have to request
> tarballs to be uploaded instead of just uploading them, I have to apply
> for CI instead of just doing it, etc. Personally, if I was not already
> rooted in KDE I wouldn't bother and just use github. (I know that it may
> be that not all of those friction points are by design, but more by lack
> of manpower.)

You address few interesting point but I think that they are ortogonal to this
discussion. Or better, that they can be discussed and solved independently
without touching the application lifecycle.
This is for repository creation (which I think it may be also blocked until we
switch fully to phabricator, apart from the non-technical policy), more
automation in the upload, and the requirement about the CIs (which I
personally think should be enabled for every project).


> 
> Now that equation starts to change later in the project if you i.e. join
> regular releases, have translations etc. but initially it's IMO just
> bad. That's of course exactly the baseline/dumpingground argument;
> either you try to attract projects and thus lower the minimum bar as far
> as possible, or you have some requirements. I don't think a bunch of
> crappy repositories hurt a lot and could be kept in check IMO, so I
> would go for the former, allowing projects to easily evolve and i.e. at
> some stage decide to become part of an Applications release after
> passing review.
> If my project started on github though, and I consequently already setup
> distribution channels etc externally, then that barrier is way higher.

Being in a community has a cost, which is balanced by being in the community.

> 
> But yeah, I'd be fine with any random project coming on KDE
> infrastructure if it sees KDE as the place to be. Some might be shitty,
> some might be great, some might have translations, some might not, some
> might die after a couple of months, some might prosper for years. I
> think it would be great to have more diversity and I don't really think
> we have to protect the quality of anything and everything that is on KDE
> infrastructure, that's what i.e. Applications and Frameworks releases
> are good for.

We are doing is already, and there will always be a cost (even with
automation, I wouldn't open some process to people without a developer account).

-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Jonathan Riddell ha scritto:

> I used the Sanity Checklist I made for the releasing extragear page as
> the list of some stuff people will look at in kdereview
>  https://techbase.kde.org/ReleasingExtragearSoftware#Sanity_Checklist
> what else should go in here?  It doesn't require docbook docs, they
> seem to be out of fashion.

Can we make this point still valid? If you don't like docbook, fine, but docs
should be still a requirement (maybe not for KIOs, but apps should have docs).


-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Christian Mollekopf ha scritto:
> 
> 
> On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote:
>> Christian Mollekopf ha scritto:
>>> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
>>>> The applications lifecycle policy needs an update
>>>>
>>>> Is this a good current state of it or are there more stages?
>>>>
>>>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>>>>
>>>
>>> Looks good to me for what it currently is.
>>>
>>> In general I think:
>>> * it should be ok to release from playground for years, or even
>>> potentially forever.
>>
>> Even stable releases? I disagree.
>>
> 
> Yes. I realize that this would be a change from the current situation,
> but I don't think it would hurt.
> It would essentially allow applications to either get the extra quality
> badge or not as they see fit.

Just to stress again: I don't think it's about extra quality, but baseline
quality.

> 
>>> * going to extragear/applications should be an extra quality badge where
>>> you sign up for certain requirements (which is why I think it should be
>>> possible to release from extragear forever. Perhaps some project is just
>>> not interested in translations for instance...)
>>
>> I totally disagree. If an application is not interested in the
>> translations (or other "details" which should be level 0) and the 
>> maintainership does
>> not even agree to outsource the work for the maintainance of the
>> translations, I would question whether the application is fit for the KDE 
>> community at
>> all.
> 
> Ok, but I wouldn't. I think it could be perfectly viable for some
> application to say that i.e.
> because we only target the scientific community (I'm making some random
> example up),
> we just assume they speak english and don't care about the rest.
> 
> My point is not specifically about translations, it's about requirements
> in general and whether it
> makes sense to find a "one size fits all" barrier that all applications
> have to pass.
> 

I understood your point, but a review is about many things (starting from the
general test from someone else external to the project, to - say -
expectations in the code, to cmake structure if applicable,  to translations
(which are always fit so far). My point is don't assume that something is not
fit because there could not be "one size fits all"; some things may not fit
but let's find out after, not a priori.
(and we already lowered the requirements, see documentation).

>>
>>> * Abolishing the extragear/applications differentiation at this level
>>> would make more sense to me (extragear does have a second class feel to
>>> it), instead applications should just declare that they are part of the
>>> applications release. This would indeed also ease transitioning between
>>> releases and dealing with the versioning should be up to the maintainers
>>> (of course versions that go down are not at all something that should be
>>> accepted ever anywhere).
>>
>>
>> So basically change
>>
>> kdereview
>> -> KDE Applications
>> -> KDE Extragear
>> -> KDE Frameworks
>> -> KDE Plasma
>> (as mentioned by Jonathan, we are missing the last two in the graph)
>>
>> with something like
>>
>> kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications",
>> independent release schedule).
>>
>> That sound fine, with one caveat: without having the 4 entities in
>> separate nodes of the graph we can't describe the transition between 
>> modules. You
>> wrote that this would "ease transitioning", but I think that we may want to
>> capture for example the transition from "any" to Frameworks, which has 
>> specific
>> rules.
>> And so on.
> 
> What I meant to propose was more that instead of being initially in a
> temporary location,
> and then having to choose one of "proper" ones and go through review, we
> would instead
> start with a permanent location and then you "could" become part of a
> release with requirements
> and therefore review. In general I just think the barrier to release a
> project from KDE infrastructure
> should be lowered not raised.


This comes again from the diversity in view: for me the review, with all its
limits, it's the baseline.
As showed in the discussion, releasing from playground is not more complicated
than other type of releases. It's just when it becomes "too much" that people
start asking "why not go for a proper review". It's not different in my
opinion from new contributor submitting patches until someone see that it's
"too much" and start asking "why don't you get a proper account".

Unless... do you (generic) have specific cases when people could fear the
review? That's the part that I don't understand.
For example, would you (specific) have some reason to not have a review for
the 4 modules that were just reviewed for pim, up to Kube?

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Christian Mollekopf ha scritto:
> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
>> The applications lifecycle policy needs an update
>>
>> Is this a good current state of it or are there more stages?
>>
>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>>
> 
> Looks good to me for what it currently is.
> 
> In general I think:
> * it should be ok to release from playground for years, or even
> potentially forever.

Even stable releases? I disagree.

> * going to extragear/applications should be an extra quality badge where
> you sign up for certain requirements (which is why I think it should be
> possible to release from extragear forever. Perhaps some project is just
> not interested in translations for instance...)

I totally disagree. If an application is not interested in the translations
(or other "details" which should be level 0) and the maintainership does not
even agree to outsource the work for the maintainance of the translations, I
would question whether the application is fit for the KDE community at all.


> * Abolishing the extragear/applications differentiation at this level
> would make more sense to me (extragear does have a second class feel to
> it), instead applications should just declare that they are part of the
> applications release. This would indeed also ease transitioning between
> releases and dealing with the versioning should be up to the maintainers
> (of course versions that go down are not at all something that should be
> accepted ever anywhere).


So basically change

kdereview
-> KDE Applications
-> KDE Extragear
-> KDE Frameworks
-> KDE Plasma
(as mentioned by Jonathan, we are missing the last two in the graph)

with something like

kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", independent
release schedule).

That sound fine, with one caveat: without having the 4 entities in separate
nodes of the graph we can't describe the transition between modules. You wrote
that this would "ease transitioning", but I think that we may want to capture
for example the transition from "any" to Frameworks, which has specific rules.
And so on.

-- 
Luigi

Re: [kde-community] Re: Applications Lifecycle Policy

[Luigi Toscano]

On Tuesday, 4 July 2017 14:27:07 CEST Jonathan Riddell wrote:
> On Tue, Jul 04, 2017 at 02:24:30PM +0200, Luigi Toscano wrote:
> > Are we focusing on the graph for now, and then we can move to the content
> > of the page, or can we start the general discussion as well?
> 
> Go wild :)
> 

I think that we need to expand the step about moving to unmaintained. It's 
really rare that someone writes "I'm abandoning this", so we may want to find 
some other conditions.
For example, change of underlying Qt and program not ported? We have many 
applications like this in "extragear" (still kdelibs4).

-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote:
> The applications lifecycle policy needs an update
> 
> Is this a good current state of it or are there more stages?
> 
> https://community.kde.org/Policies/Application_Lifecycle/Draft

Are we focusing on the graph for now, and then we can move to the content of 
the page, or can we start the general discussion as well?

The proposed graph is fine by me, and it solves the issue with applications 
coming from the Incubation which ended into playground while they should have 
gone directly to kdereview.
I think that a separate "playground" has still value in defining some kind of 
line where the application has been released. "Extragear" here already means 
"whatever is released with its own release cycle not in the big bundles", as 
we basically officially removed that word from public usage.

-- 
Luigi

Re: KDE licence policy update

[Luigi Toscano]

Jonathan Riddell ha scritto:

> The main change is for docs and other non-code files to become
> CC-BY-SA 4.  This allows it to be converted to code (it's one-way
> compatible with LGPL 3) 
Do you have more details for this? I see contradicting information, it does
not seem to be totally future proof (even if I hope that we won't see a GPLv4
before my retirement, but... that would be too much I guess):
https://www.fsf.org/blogs/licensing/creative-commons-by-sa-4-0-declared-one-way-compatible-with-gnu-gpl-version-3
(hint about GPLv3 only)

https://www.gnu.org/licenses/license-compatibility.en.html -> "Unfortunately,
CC-BY-SA 4.0 does not permit relicensing to future GPL versions. What you
should do, when you relicense material under CC-BY-SA 4.0 to the GPL, is
specify yourself as a license version proxy to indicate whether future GPL
versions have been authorized for that material. If someday there is a GPL
version 4 and Creative Commons decides to allow relicensing from CC-BY-SA to
GPL version 4, you as proxy will be able to retroactively authorize use of
that relicensed material under GPL version 4. (Alternatively, you can ask the
authors of that material to give permission right away.)"

Can we setup a process so that we don't need to rework everything in the future?

-- 
Luigi

Re: KDE licence policy update

[Luigi Toscano]

On Friday, 10 February 2017 14:54:52 CET Jonathan Riddell wrote:
> I'd like to get back to my proposed update of the KDE licence policy
> 
> https://community.kde.org/Policies/Licensing_Policy/Draft
> 
> I got some comments from Matija Šuklje which I incorporated and it now
> includes a handy changelog.
> 
> [...]
> -Documentation to be CC-BY-SA 4

I stand by my previous position (have dual license FDL in its fully free 
version/dfsg version + CC-BY_SA 4) but if I'm the only one it means that we 
have only the painful way of finding contributors no more active for 10+ years 
and try to relicense. We seriously risk to lose a lot of documentation this 
way. 
Would we allowed to keep the documents with old license and apply this only to 
new one?


> The main change is for docs and other non-code files to become
> CC-BY-SA 4.  This [...] and allows us to share with other popular
> sources such as wikipedia.  

It does not change your proposal but this specific point is incorrect: 
Wikipedia is dual licensed even now: https://en.wikipedia.org/wiki/
Wikipedia:Copyrights

-- 
Luigi

Re: Kubuntu and other KDE distribution's use of KDE infrastructure

[Luigi Toscano]

Adriaan de Groot ha scritto:

> I don't think votes are the way to go, really. I'd much rather just get on 
> with it. For the FreeBSD project on KDE's phab, I didn't even think about it: 
> I'm a KDE person, I'm interested in delivering KDE software to a particular 
> group, and I do lots of things on KDE infrastructure for doing that delivery 
> (e.g. filing bugs, writing patches, blogging, running KDE CI for FreeBSD), 
> and 
> sysadmin suggested having a Phab project for it would be useful to group 
> things. Yeah, sure.
> 
> I don't see, given the *tiny* technical burden implied by the request in this 
> thread, why Kubuntu should be any different from FreeBSD.

There is a slight difference: FreeBSD (but the same can be said for Windows or
Android) is a completely different platform and the "FreeBSD" project/tag on
phabricator.kde.org can be used to identify which reviews and changes are
relevant for that port.
The fact that you can organize the tasks and review is a side effect of this
reason, and that's why I proposed the creation of the tag (as Community
Administrator, not exactly an official sysadmin :)

I think this is different from *ubuntu (and Fedora, Debian, Opensuse, Arch,
Gentoo, Chakra, Slackware, etc etc) which are GNU/Linux distributions, all
(with "minimal" differences) the same platform (and probably the most tested).

-- 
Luigi

Re: Changes to the bugzilla workflow: 2 proposals

[Luigi Toscano]

On Monday, 12 December 2016 19:34:55 CET Eike Hein wrote:
> On 12/12/2016 07:27 PM, Elvis Angelaccio wrote:
> > On Sun, Dec 11, 2016 at 10:35 PM, Luigi Toscano
> > 
> > <luigi.tosc...@tiscali.it> wrote:
> >> 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.> 
> > Don't we already have the ASSIGNED state? I just checked and I can
> > select it from the left dropdown menu.
> 
> Correct, we have that and use it quite a bit imho.

Oh, sorry, I did not check. It would be a matter of changing the policy then.

-- 
Luigi

Re: Fwd: Top 15 Mailinglists with messages in moderation

[Luigi Toscano]

Il 02 dicembre 2016 20:29:17 CET, Aaron Honeycutt  
ha scritto:
>I thought kde-telepathy was to replace kopete?

Yes and no. And right now kopete is alive.



-- 
Luigi

Re: Decommisioned from service: quickgit.kde.org

[Luigi Toscano]

Adriaan de Groot ha scritto:
> On Tuesday 15 November 2016 12:24:29 Elvis Angelaccio wrote:
>> On Tue, Nov 15, 2016 at 8:22 AM, Ben Cooksley  wrote:
>>> Hi all,
>>>
>>> Please note that we've now decommissioned quickgit.kde.org in favour
>>> of cgit.kde.org. This change has been done to eliminate some of the
>>> maintenance issues and bugs which were affecting us with the GitPHP
>>> software.
>>>
>>> You'll need to update your urls accordingly.
> 
> That includes a lot of items on techbase.k.o, community.k.o and the other 
> wikis; also lots of applications sites. It just looks really weird to have 
> the 
> "official" KDE wiki saying "get the source code here". I see it redirects 
> now, 
> that's an improvement.

If you want to be future-proof, please update the links using the general
redirector commits.kde.org, see:

https://techbase.kde.org/Projects/Documentation/KDE_(health_table)#Links_to_kde_repos


which should always point to the proper site.

Ciao
-- 
Luigi

Re: KDE Licensing Policy Updates

[Luigi Toscano]

On Friday, 23 September 2016 16:46:22 CEST Jonathan Riddell wrote:
> On Fri, Sep 23, 2016 at 06:41:57PM +0200, Riccardo Iaconelli wrote:
> > Hi all,
> > 
> > On 20 September 2016 at 19:04, Jonathan Riddell  wrote:
> > > Added:
> > > "Content on collaborative edited websites such as wikis must be
> > > licensed under the Creative Commons Attribution-Sharealike 4.0
> > > International."
> > > Rationale: we have no policy for wikis but they are very important to
> > > us especially with wikitoLearn so we should add one.  Our wikis are
> > > currently CC 3.0+FDL but we should consider moving to CC 4.0 (CC
> > > includes an or later so there's no difficultly in doing this).  FDL is
> > > unmaintained and not much used so we can drop this.
> > 
> > WikiToLearn is currently dual licensing CC-BY-SA 3.0 / GNU FDL and
> > we're considering just dropping FDL as it is quite cumbersome and we
> > don't really use it anyways.
> 
> Right, that's why I suggest dropping FDL usage across all wikis and new
> docs.

Still, as I mentioned, it would introduced problems if we move documentation 
forth and back from wikis to other formats, and also with mixing content from 
older documentation. I still don't buy the "cumbersome" argument, I don't 
think we use it the controversial parts like invariant section etc - do we?
Trying to to relicense the existing documentation from FDL to FDL+CC as a 
start would be the best thing, but I think it would be complicated.

-- 
Luigi

Re: Creating a map of KDE contributors?

[Luigi Toscano]

On Tuesday, 20 September 2016 13:42:35 CEST Thomas Pfeiffer wrote:
> Hi everyone,
> I recently realized that unless you ask fellow KDE contributors personally
> where they live, you don't really know where over the world (or even in
> your home country) KDE is spread.
> 
> [...]
> 
> So, two questions:
> 1. Does that make sense to you?

We had a "heat-map" of committers in the old commit-digest:
https://commit-digest.kde.org/issues/2014-11-16/
So yes, it makes sense.

Also, for example:
https://www.debian.org/devel/developers.loc

> 2. If yes: Does anyone know of a piece of code that allows people to enter
> their city of residence and then show people on a map (ideally as an OSM
> overlay), or could otherwise maybe create it?

If it's not for the fact that sysadmin want to replace identity, a custom 
field there with the city and/or coordinates and some script to grab them, 
convert into geojson, and it's really easy (read: few lines of code) to setup 
a map with leaflet.

http://leafletjs.com/examples/geojson.html

Ciao
-- 
Luigi

Re: [kde-community] KDE Sysadmin and GPG Encryption

[Luigi Toscano]

On Tuesday, 26 July 2016 19:25:25 CEST Boudhayan Gupta wrote:
> 2) GPG doesn't simply encrypt the email, but also digitally signs it.
> Signatures are required to prove the authenticity of the email, and to
> detect if it was tampered with. However, given our email
> infrastructure, a GPG signature is meaningless. Anyone can create a
> GPG key, encrypt the email and send it out. To trust the public key,
> it would have to be either (a) distributed in a trustable way, which
> brings us to the same sitation as the SSH host key, (b) signed by
> another trusted entity (a person), after a face-to-face meeting, or
> (c) signed by members of a web of trust (which recursively requires
> one of (a) and (b)). Given we live in such physically diverse location
> (in fact, Ben lives in New Zealand; meeting enough KDE contributors
> face to face willing to sign his key is prohibitvely time, effort and
> finance consuming). If you can't establish trust of a GPG public key,
> the signature is meaningless.

I strongly disagree with this. While it is complicated in Ben's case, we had 
GPG signing party at the past Akademy and we can rebuild the web of trust. 
Debian works like this. We can have one at the QtCon (with also people from 
other communities including FSFE). So *signing* the announcement emails should 
not be discouraged like it is in this email.

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

Re: [kde-community] Our new project metadata system

[Luigi Toscano]

On Thursday 31 of March 2016 14:29:19 Jaroslaw Staniek wrote:
> On 31 March 2016 at 14:18, Luigi Toscano <luigi.tosc...@tiscali.it> wrote:
> > On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote:
> > > On 31 March 2016 at 17:13, Luigi Toscano <luigi.tosc...@tiscali.it>
> > 
> > wrote:
> > > > Wait, no. The metadata there are outdated, the ones in project
> > > > repositories
> > > > have been updated _and_ translated in the meantime.
> > > 
> > > Where do I find them? I can't find anything in every project's repo
> 
> ​They're sometimes in /, sometimes in src/ and similar subdirs.​
> 
> 
> ​
> https://github.com/search?utf8=%E2%9C%93=org%3AKDE+.appdata.xml=Code;
> ref=searchresults (sorry but I probably can't search this way without github
> :/)

https://lxr.kde.org/search?_filestring=appdata.xml
https://lxr.kde.org/search?v=latest-qt4&_filestring=appdata.xml


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

Re: [kde-community] Our new project metadata system

[Luigi Toscano]

On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote:
> On 31 March 2016 at 17:13, Luigi Toscano <luigi.tosc...@tiscali.it> wrote:
> > Wait, no. The metadata there are outdated, the ones in project
> > repositories
> > have been updated _and_ translated in the meantime.
> 
> Where do I find them? I can't find anything in every project's repo
> 

Look for .appdata.xml, where  matches the name of the 
corresponding .desktop file.

Random examples:
https://quickgit.kde.org/?p=kig.git=blob=9daea7d0f9ba90571f0429cd5a4ed0de8d24df74=2f22efe4cb70960cf2362680783477ed44b2492e=org.kde.kig.appdata.xml
https://quickgit.kde.org/?p=yakuake.git=blob=68c7e41ff5a008067228e9ac871f3c53df3289d4=87f7321955c5787717e3dd8fe34ae673bc3eee83=data%2Forg.kde.yakuake.appdata.xml
https://quickgit.kde.org/?p=konsole.git=blob=e53e70ac827eb484a9fbf3b4ba27e677ee5f4489=6c4608b7038174310be18b8e903abd098006b01a=desktop%2Forg.kde.konsole.appdata.xml
https://quickgit.kde.org/?p=kdepim.git=blob=2f5e64206866a8c91b428220f29199bea9b0532b=eef4ef1d8717e7e2fa328dcd21e461dcf2f39ece=kmail%2Fdata%2Forg.kde.kmail.appdata.xml
https://quickgit.kde.org/?p=ark.git=blob=b1d4ad89ff6a8e3aeea0acc910371161c0bda091=f11ecbba02f72d478274cc93b7881a3bc45d19e3=app%2Forg.kde.ark.appdata.xml

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

Re: [kde-community] Our new project metadata system

[Luigi Toscano]

On Thursday 31 of March 2016 12:31:39 Olivier Churlaud wrote:
> Le 31/03/2016 12:07, kde-community-requ...@kde.org a écrit :
> > Message: 8
> > Date: Thu, 31 Mar 2016 12:06:50 +0200
> > From: Luigi Toscano<luigi.tosc...@tiscali.it>
> > To:kde-community@kde.org
> > Cc:kde-de...@kde.org, KDE Sysadmin Help Desk<sysad...@kde.org>
> > Subject: Re: [kde-community] Our new project metadata system
> > Message-ID:<5718636.mftrzcl...@whitebase.usersys.redhat.com>
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > On Thursday 31 of March 2016 13:55:03 Boudhayan Gupta wrote:
> >> >Hi all,
> >> >
> >> >Over the last few weekends we've been doing some spring-cleaning to
> >> >our infrastructure. You may have noticed that we've killed off
> >> >projects.kde.org, and we have new scripts that generate our
> >> >kde_projects.xml without having to depend on ChiliProject now. We're
> >> >also planning to deprecate kde_projects.xml itself, and to that effect
> >> >we've started setting up a JSON/REST API at
> >> >https://apps.kde.org/api/v1/.
> >> >
> >> >The same infrastructure that is used to generate data for our API and
> >> >the XML file can be used to generate a HTML website with landing pages
> >> >for our applications, and this is something we intend to do in the
> >> >coming months as a replacement for the outdated kde.org/applications
> >> >site. To achieve that, however, we're going to need some help from
> >> >you.
> >> >
> >> >Our project metadata is currently held in the sysadmin/repo-metadata
> >> >repository. We currently hold data about the project name, repository
> >> >and a one-line description of each project. We would like maintainers
> >> >and anyone who can help to provide us with three things for every
> >> >project - a*description.md*  file with a bigger description of each
> >> >project that appears on the website, and for applications with a GUI,
> >> >a*screenshot.png*  file with a screenshot of the app and two icons (a
> >> >256 * 256 px icon.png and a 512 * 512px icon_2x.png).
> > 
> > I don't think we need to do this; we have AppStream metadata.
> > 
> > Long time ago it was in fact discussed how to not duplicate the
> > information
> > between the json on the website and the AppStream metadata. There was some
> > idea on how to generate one from the other. Check this old thread on
> > kde-core- devel, from November 2013 ("Adopting AppData in KDE?
> > http://marc.info/?l=kde-core-devel=138348776618380=2
> > http://marc.info/?l=kde-core-devel=138349411519937=2
> > 
> > And also, more recent:
> > https://mail.kde.org/pipermail/kde-community/2015q4/002132.html
> > 
> > Now, whether we like them or not, those metadata are already available and
> > going to stay. I don't think we want to duplicate again the same set of
> > data for the website.
> > 
> > I would say then to use them for the website, adding the missing files in
> > the process (most of applications are already covered).
> > 
> > Ciao
> > -- Luigi
> 
> Hi,
> 
> During the CERN Sprint we worked with Alex Merry on something similar,
> without knowing you were doing the same. Our idea is to have all
> metadata to generate a comprehensive api.kde.org.
> 
> You can see the notes here: https://notes.kde.org/p/apidox (please do
> not edit, even if I have a copy). I'm currently working on the the
> script that could generate the doxygen documentation from this, before
> releasing the proposition.
> 
> These "config.apidox"  files should just add infos that are not in
> "metadata.yaml". Maybe we should work together to have one global
> system, that can be used by everyone?
> 
> If it's not related to the topic, then sorry for the noise :S

I think it's different: you are talking about generating api.kde.org (and 
maybe, if I remember the past discussion, the entire techbase). This is about 
the project pages for kde.org and, more generally, the metadata for each 
application/library/git repository.

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

Re: [kde-community] What is a GitHub pull request exactly?

[Luigi Toscano]

Riccardo Iaconelli ha scritto:
> On Sunday, September 20, 2015 12:26:41 PM Sune Vuorela wrote:
>> Free software needs free tools.
> 
> I am sorry, but sadly this is not the state of the art. KDE has been created 
> with many non free tools and currently co-exists in many non-free 
> environments. We can either decide to live with it and improve the situation 
> little by little or put our heads in the sand, build walls around us and 
> pretend the rest of the world doesn't exist.

But we replaced them as soon as we could.

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

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

[Luigi Toscano]

Il 19 settembre 2015 12:00:11 CEST, Vishesh Handa  ha scritto:
> On Sat, Sep 19, 2015 at 11:44 AM, Luca Beltrame 
> wrote:
> >
> > And besides... hasn't the BitKeeper story taught us *anything*?
> >
> 
> I don't know about you guys, but it has taught me that we can be
> pragmatic and use proprietary software when the need arises.


There is a big FLOSS project I spend my daily work for, called OpenStack. Given 
its target, contributions comre from companies and certainly normal users are 
not too interested about it and even more about how it is developed. Despite 
this, it has a strong manifesto with interesting values:
https://wiki.openstack.org/wiki/Open

and that extends to the infrastructure too. Leaving aside the usage of 
launchpad for bugs (there is a replacement which is advanced state of 
development), guess what? Infra team has an own git, contributions go to the 
internal gerrit. Github is just a mirror and I didn't hear anyone screaming or 
complaining about loss of contributions.

Now, if they can do that, why can't we do it?

Ciao

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

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

[Luigi Toscano]

Kevin Krammer ha scritto:
> On Saturday, 2015-09-19, 12:29:31, Vishesh Handa wrote:
>> On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić  wrote:
>>> alternatives. Just as they do not have access to my personal inbox
>>>
 where much corresponse often happens, and patches are discussed.
>>>
>>> Not sure that this is a statement you want to advertise, since it
>>> implies that the development happens behind the closed doors. (yes, we
>>> all do that sometimes, but is should not be a part of our workflow,
>>> and not something we should be proud of)
>>>
>>> Now, with GitHub, it would not be exactly 'development behind the
>>> closed doors' but for a lot of us it would be basically the same. As
>>> Martin mentioned, this would be hidden from his eyes since he has no
>>> intention to follow development on GitHub.
>>
>> Some development does happen behind closed doors. Someone sends me a
>> patch, I commit it, and then point them towards reviewboard for the
>> next time. Ditto with bugs actually. I get reports via IRC, emails,
>> Google+ and even FB (once). If it is minor I act on it, if it isn't I
>> point the user towards bugzilla or just file a bug myself so that I
>> don't forget.
> 
> Right, this is also my understanding of what is proposed.
> 
> If you work on a project where you can push without review, it really doesn't 
> matter how you arrived at the commit, you would have pushed your own version 
> without review as well.
> 
> If you work on a project where you have to go through review, then again, it 
> really doesn't matter how the commit has been created, it is still being 
> reviewed.
> The only difference is that the submitter of the review request is not the 
> author of the commit.

But that's not using the pull request. Such workflow would mean that the pull
request is not accepted anyway, but the code is pushed through the
infrastructure and not trough Github interface.

Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please
explain exactly what is the meaning of "use Github"? Do we all agree that in
any way pull requests will never be merged directly through Github interface?

I still think that an automated bot should invite people in pull requests to
submit proper reviews, but it's important to clarify this point.

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

Re: [kde-community] Kdetoys

[Luigi Toscano]

Jeremy Whiting ha scritto:
 Hello all,
 
 tldr, should we kill kdetoys?
 
 As Applications 15.08 has been released I thought I'd take a look at
 which of our applications still need to be ported to Qt5/kf5. I did a
 diff of what we released in the 15.08 release vs what is already kf5
 based and got this result: https://paste.kde.org/prbvha5kh#line-13 --
 paste should stay for a year. Items with + are not Qt5/kf5 based yet
 or weren't in the 15.08 release. Christoph Feck has a more detailed
 list that includes Extragear, but isn't organized by KDE Module here:
 http://developer.kde.org/~cfeck/portingstatus.html .

Historical note: when kdetoys programs were migrated from SVN to GIT and split
(two years ago), the second part of the plan was to kill the module, move amor
to kdegames, ktux to kdeartwork and kteatime in kdeutils.

 I took a quick stab at porting amor to Qt5/kf5 and it shouldn't be too
 hard, but the question is should it be ported at all? The previous
 maintainer hasn't touched it in quite some time. The code is X11
 specific, and the whole concept won't work on Wayland anyway because
 windows don't know about each other and can't position themselves.

No real opinion.

 
 KTux has been ported to Qt5/kf5 but I don't see any way in plasma 5 to
 make it the screensaver. We only support images in the lock screen and
 kwin will only support the greeter used in
 plasma-workspace/ksmserver/screenlocker so if you run it it shows a
 nice window of tux flying around, but I don't think that's useful in
 today's screensaver less world somehow.

That's not true, we support animated wallpapers as screenlockers and we should
provide more documentation on how to create them. When I pinged Andrius
Štikonas, who did the port, he said that he could try to see if ktux can be
changed into an animated wallpaper (with no guarantees due to other duties).
He just finished the port, give him some time... or at least please ask him.


 
 KTeatime may still be useful, but if we are cleaning out kdetoys,
 maybe it should be moved to kdeutils so it isn't the lone application
 in a module?

kdeutils is the natural choice (see above).

 
 I'll ask sysadmin to make the above moves unless anyone objects within
 a couple of weeks. I would put ktux and amor into unmaintained (or
 playground? not sure which is more suitable) and stop releasing them
 in 15.12 and move kteatime to kdeutils.

Just please check about ktux first.

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

Re: [kde-community] Renaming KScreenGenie

[Luigi Toscano]

Jaroslaw Staniek ha scritto:
 On 24 August 2015 at 15:53, Martin Klapetek martin.klape...@gmail.com wrote:
 On Mon, Aug 24, 2015 at 9:24 AM, Boudhayan Gupta bgu...@kde.org wrote:

 On 24 August 2015 at 18:45, Martin Klapetek martin.klape...@gmail.com
 wrote:
 KSnapshot2.

 One of the points brought up was that KDE Applications are moving away
 from using a K-prefixed name, so I want to ride that bandwagon.


 My other suggestion would then be Snapshot. Keeps it simple and
 recognizable,
 kinda tied to KSnapshot even, no need for the fancy/cryptic names, I'd say.

 
 +1
 
 If KSnapshot is going to be abandoned why to loose the great privilege
 to use the Snapshot name.

If there are other Snapshot applications around, it's a no-go.

Ciao
-- 
Luigi

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

Re: [kde-community] Renaming KScreenGenie

[Luigi Toscano]

Ivan Čukić ha scritto:
 +1 for snapshot
 
 It is a part of Plasma workspace (and possibly other friendly
 workspaces), so I don't even see it as a problem if other applications
 with the same name exist (the only thing I've checked is that debian
 has no package named 'snapshot').

It's not part of Plasma (no need to be).

 
 If other projects can take names like Music, etc. i do not see why
 this would not be acceptable.

It does not mean we should follow (I personally don't like that pattern for
names).

Ciao
-- 
Luigi

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

Re: [kde-community] Updating TechBase Getting_Started pages

[Luigi Toscano]

On Monday 17 of August 2015 09:53:58 John Layt wrote:
 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.

Is it really s/removed/moved/, right? We already have name-spaced historical 
information around (for example
https://techbase.kde.org/Development/Architecture/KDE4 ) so I guess it would 
be just an addition to them.

Ciao
-- 
Luigi

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

Re: [kde-community] Work on Krusader new release

[Luigi Toscano]

On Wednesday 24 of June 2015 11:17:46 Laszlo Papp wrote:
 On Wed, Jun 24, 2015 at 11:06 AM, Luigi Toscano luigi.tosc...@tiscali.it

   So if you want to help us, please join krusader-de...@googlegroups.com
   mailing list and send your proposals.
  
  (and move the site too
 
 Why move the site? What exactly is wrong with a KDE project having its own
 site (like Krita)?
I thought that we discussed this many times. 
https://manifesto.kde.org/commitments.html

Online services associated with the project are either hosted on KDE 
infrastructure or have an action plan that ensures continuity which is 
approved by the KDE system administration team


For the record:
$ host www.krita.org
www.krita.org is an alias for silk.kde.org.
silk.kde.org has address 5.9.99.187
silk.kde.org has IPv6 address 2a01:4f8:162:31a2::3
silk.kde.org mail is handled by 10 postbox.kde.org.
$ host 5.9.99.187 
187.99.9.5.in-addr.arpa domain name pointer silk.kde.org.

http://quickgit.kde.org/?p=websites%2Fkrita-org-theme.git

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

Re: [kde-community] retiring unmaintained modules?

[Luigi Toscano]

Myriam Schweingruber ha scritto:


Last time I was trying to close the kmail 1 bugs as unmaintained, asking
people to reopen if it stilkl applies to kmail2 I was shouted at and
told that somebody has to check if that still applies to Kmail2 before
closing, go figure! I just fear that with 880 open reports this is never
going to happen...


It was me who complained, the maintainer complained as well, and it was 
about wishlist only, not other kind of bugs. Are we talking about all 
bugs including wishlist here?


Ciao
--
Luigi

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

Re: [kde-community] retiring unmaintained modules?

[Luigi Toscano]

Boudewijn Rempt ha scritto:

I guess we should also be really careful, as you said some software is
done
and the fact that it didn't get any development doesn't mean it should be
killed.


Of course. But kmail (not kmail2) is _dead_. It's bugs should be closed.


I would ask Laurent first. He said in the past that the UI part of 
kmail2 is really close to kmail1. Are those bugs real bugs and not 
wishlists, right?


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

Re: [kde-community] Proposal One: KDE (Core) Apps and Suites

[Luigi Toscano]

On Friday 02 of May 2014 19:53:47 Jos Poortvliet wrote:
  * we know there's a release every month. That might seem more often than
 now, but honestly - we DO have releases *multiple times* per month already.

Not at the same rate as it will go, I think: one thing is to release (these 
days) 4.11.something for workspace + 4.12.something (already stable) + 
4.13.something, another thing is to have full mix-and-matched releases also of 
big stuff. I think it means a neverending run.

Ciao
-- 
Luigi


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

Re: [kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5

[Luigi Toscano]

Adriaan de Groot wrote:
 Note also that we *have* some kinds of metapackages already defined. Thery're 
 on our website, at http://www.kde.org/applications/ . You'll note that the 
 list of applications in graphics doesn't coincide with the repositories, 
 and 
 does include digiKam, because that's a useful application for doing (some 
 kinds of) graphics work.

They are not metapackages, imho: those are simple the packages from the same
category (graphics, in this case) from SC and extragear.

Categories can stay, I think; the definition of metapackages is orthogonal and
can use the input from packagers.

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

Re: [kde-community] Applications in KDE Generation 5

[Luigi Toscano]

John Layt wrote:
 One other thing I would do is change our app lifecycle slightly.  I'd
 introduce a new status of Deprecated that lies between Released and
 Unmaintained, for apps like Kopete and KPPP that are no longer
 relevant for most people or are being replaced, but may still have
 limited use and so need to be kept alive for a while.  I'd envision a
 new lifecycle metadata attribute that looks something like
 Experimental - Incubator - Stable - Deprecated - Unmaintained,
 with only Stable apps eligible to be included in the regular
 Applications release cycle.

Just my 2 cents here: I would be careful with this kind of lifecycle. An
application with low activity (almost unmaintained) can be still stable for a
long time, given our committment to binary compatibility. This is true
especially for small applications, but it is something that should be 
considered.

Also, I would be careful to use the word deprecated for applications like
Kopete, where Ktp has not covered all the functionalities (yet); also Kopete
receives changes/fixes. This is for the 4.x world, at least (if Kopete is not
ported to 5 the problem is solved, but otherwise the problem still holds).

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