Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> On Sunday January 29 2017 08:32:21 Ben Cooksley wrote:
>
> Hi,

Hi Rene,

>
> >From this point forward, communities should be moving away from
>>Reviewboard to Phabricator for conducting code review. Sysadmin will
>>be announcing a timeline for the shutdown of Reviewboard in the near
>>future.
>
> I hope that shutdown doesn't mean complete disconnect; it would probably be a 
> loss of as-yet unknown importance if all code reviews become unavailable.
>
> I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, but 
> RB had its advantages too which could be why it's still being used (quite a 
> lot, as far as I can see) and hasn't been integrated with KDE's own IDE yet.

It will be a complete shutdown of Reviewboard - we'll be archiving it
in the event for some reason it becomes necessary to access the data
it stores.

In most cases mailing lists should have the history of reviews in
their archives, so those will continue to be accessible through list
archives in the long run.


>
> R.

Cheers,
Ben

Re: Phabricator differential is not good - WAS - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Mon, Feb 6, 2017 at 8:39 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dilluns, 6 de febrer de 2017, a les 8:18:04 CET, Ben Cooksley va escriure:
>> On Sun, Feb 5, 2017 at 6:24 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > El dissabte, 4 de febrer de 2017, a les 12:44:54 CET, Ben Cooksley va
>> >
>> > escriure:
>> >> On Sat, Feb 4, 2017 at 11:41 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> >> > El divendres, 3 de febrer de 2017, a les 21:06:08 CET, Ben Cooksley va
>> >> >
>> >> > escriure:
>> >> >> On Fri, Feb 3, 2017 at 12:18 PM, Albert Astals Cid <aa...@kde.org>
> wrote:
>> >> >> > El diumenge, 29 de gener de 2017, a les 8:32:21 CET, Ben Cooksley va
>> >> >
>> >> > escriure:
>> >> >> >> Hi everyone,
>> >> >> >>
>> >> >> >> We've just completed the registration of all mainline repositories
>> >> >> >> (not including Websites or Sysadmin namespaced ones) on
>> >> >> >> Phabricator.
>> >> >> >> Thanks go to Luigi Toscano for providing significant assistance
>> >> >> >> with
>> >> >> >> this process.
>> >> >> >>
>> >> >> >> From this point forward, communities should be moving away from
>> >> >> >> Reviewboard to Phabricator for conducting code review.
>> >> >> >
>> >> >> > I just created first patch with the phabricator web interface.
>> >> >> >
>> >> >> > Found one minor and one major problem.
>> >> >> >
>> >> >> > Minor problem:
>> >> >> >  * You can't update the diff before creating a "Revision", so if you
>> >> >> >  realize
>> >> >> >
>> >> >> > your diff was wrong, back luck, you either leave the diff floating
>> >> >> > in
>> >> >> > the
>> >> >> > limbo or you create the Revision and the update the diff, showing
>> >> >> > the
>> >> >> > world
>> >> >> > your mistake for no reason
>> >> >> > https://phabricator.kde.org/D4422?vs=10881=10882
>> >> >>
>> >> >> Interesting. It might be worth asking upstream about that.
>> >> >>
>> >> >> > Major problem:
>> >> >> >  * It doesn't show context
>> >> >> >
>> >> >> > https://phabricator.kde.org/D4422
>> >> >> >
>> >> >> > "Context not available." is terrible, how is one supposed to review
>> >> >> > without
>> >> >> > being able to read the rest of the code?
>> >> >> >
>> >> >> > This is a deal breaker for me.
>> >> >>
>> >> >> Please see https://secure.phabricator.com/T5029
>> >> >
>> >> > As said on IRC, the fact that this has been open for almost 3 years is
>> >> > more a concern than a relief.
>> >>
>> >> I've inquired with upstream, and they've indicated that at the moment
>> >> T5029 isn't on their roadmap for implementation (although T5000 and
>> >> T182 are).
>> >>
>> >> Their target audience is primarily corporate development workflows,
>> >> for which requiring use of Arcanist isn't an issue.
>> >>
>> >> >> This only occurs when patches are uploaded from the web interface and
>> >> >> the patch in question has minimal context.
>> >> >> At this time Phabricator is not able to automatically resolve context
>> >> >> using markers in the patch (there are certain complexities involved
>> >> >> for some SCMs, particularly for SVN - which Phabricator supports)
>> >> >>
>> >> >> The fix for this is to either:
>> >> >> a) Use Arcanist, the recommended tool for working with Phabricator
>> >> >> (this is no different to rb-tools for Reviewboard)
>> >> >
>> >> > This is not ok, the web interface for reviewboard was as good as
>> >> > rb-tools
>> >> > (i guess tbh i never used them) and "forcing" the use of a weird tool
>> >> > noone has heard of is not a good way to attract new contributors
>> >>
>> >> New contributors who aren't willing to install Arcanist can use diff
>> >> -U99 I would imagine?
>> >
>> > Yes, If there's an easy way for them to know they should (which afaics is
>> > not right now).
>>
>> Okay, we'll look into adding a message box or something there
>> explaining the need to use diff -U99.
>
> FWIW i thought that diff -U99 would give you the same behaviour that when
> using arc (somehow i thought phabricator was not very smart and needed more
> lines to actually match the patch against the whole file).
>
> But no, using diff -U99 only gives you more lines because you used -U99, but
> you can't still expand the whole file like when using arc.

Are you essentially saying that the migration cannot proceed, because
Phabricator doesn't know how to expand patches?

I'd suggest using "diff -U9" or some other massively
long number, if having the full file available is a hard requirement.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Regards,
>> Ben
>>
>> >> > Cheers,
>> >> >
>> >> >   Albert
>> >>
>> >> Regards,
>> >> Ben
>
>

Re: Phabricator differential is not good - WAS - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Sun, Feb 5, 2017 at 6:24 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dissabte, 4 de febrer de 2017, a les 12:44:54 CET, Ben Cooksley va
> escriure:
>> On Sat, Feb 4, 2017 at 11:41 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > El divendres, 3 de febrer de 2017, a les 21:06:08 CET, Ben Cooksley va
>> >
>> > escriure:
>> >> On Fri, Feb 3, 2017 at 12:18 PM, Albert Astals Cid <aa...@kde.org> wrote:
>> >> > El diumenge, 29 de gener de 2017, a les 8:32:21 CET, Ben Cooksley va
>> >
>> > escriure:
>> >> >> Hi everyone,
>> >> >>
>> >> >> We've just completed the registration of all mainline repositories
>> >> >> (not including Websites or Sysadmin namespaced ones) on Phabricator.
>> >> >> Thanks go to Luigi Toscano for providing significant assistance with
>> >> >> this process.
>> >> >>
>> >> >> From this point forward, communities should be moving away from
>> >> >> Reviewboard to Phabricator for conducting code review.
>> >> >
>> >> > I just created first patch with the phabricator web interface.
>> >> >
>> >> > Found one minor and one major problem.
>> >> >
>> >> > Minor problem:
>> >> >  * You can't update the diff before creating a "Revision", so if you
>> >> >  realize
>> >> >
>> >> > your diff was wrong, back luck, you either leave the diff floating in
>> >> > the
>> >> > limbo or you create the Revision and the update the diff, showing the
>> >> > world
>> >> > your mistake for no reason
>> >> > https://phabricator.kde.org/D4422?vs=10881=10882
>> >>
>> >> Interesting. It might be worth asking upstream about that.
>> >>
>> >> > Major problem:
>> >> >  * It doesn't show context
>> >> >
>> >> > https://phabricator.kde.org/D4422
>> >> >
>> >> > "Context not available." is terrible, how is one supposed to review
>> >> > without
>> >> > being able to read the rest of the code?
>> >> >
>> >> > This is a deal breaker for me.
>> >>
>> >> Please see https://secure.phabricator.com/T5029
>> >
>> > As said on IRC, the fact that this has been open for almost 3 years is
>> > more a concern than a relief.
>>
>> I've inquired with upstream, and they've indicated that at the moment
>> T5029 isn't on their roadmap for implementation (although T5000 and
>> T182 are).
>>
>> Their target audience is primarily corporate development workflows,
>> for which requiring use of Arcanist isn't an issue.
>>
>> >> This only occurs when patches are uploaded from the web interface and
>> >> the patch in question has minimal context.
>> >> At this time Phabricator is not able to automatically resolve context
>> >> using markers in the patch (there are certain complexities involved
>> >> for some SCMs, particularly for SVN - which Phabricator supports)
>> >>
>> >> The fix for this is to either:
>> >> a) Use Arcanist, the recommended tool for working with Phabricator
>> >> (this is no different to rb-tools for Reviewboard)
>> >
>> > This is not ok, the web interface for reviewboard was as good as rb-tools
>> > (i guess tbh i never used them) and "forcing" the use of a weird tool
>> > noone has heard of is not a good way to attract new contributors
>>
>> New contributors who aren't willing to install Arcanist can use diff
>> -U99 I would imagine?
>
> Yes, If there's an easy way for them to know they should (which afaics is not
> right now).

Okay, we'll look into adding a message box or something there
explaining the need to use diff -U99.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Regards,
>> Ben
>
>

Re: Finding contributor email is imposible - was - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Wed, Feb 8, 2017 at 4:03 AM, Fredrik Höglund <fred...@kde.org> wrote:
> On Monday 06 February 2017, Albert Astals Cid wrote:
>> El diumenge, 29 de gener de 2017, a les 8:32:21 CET, Ben Cooksley va 
>> escriure:
>> > Hi everyone,
>> >
>> > From this point forward, communities should be moving away from
>> > Reviewboard to Phabricator for conducting code review. Sysadmin will
>> > be announcing a timeline for the shutdown of Reviewboard in the near
>> > future.
>>
>> Today i wanted to commit https://phabricator.kde.org/D4432 since the person
>> that opened it does not have a developer account.
>>
>> Easy peasy, it's just a line, i download the patch and then
>>
>> git commit --author ...
>>
>> and what, it says "Authored by rikmills" that's probably not the guys name,
>> but i can click on the name and on https://phabricator.kde.org/p/rikmills/ i
>> learn he is Rik Mills, good.
>>
>> $ git commit --author=="Rik Mills"
>> fatal: --author 'Rik Mills' is not 'Name ' and matches no existing
>> author
>>
>> ouch, so i need his email, where do i get it?
>>
>> Nowhere it seems.
>>
>> I resorted to searching for it in identity.kde.org but i think that i can 
>> only
>> do that because i have some special power over there that allows me to see
>> everyone's email, and even if everyone can, it's very cumbsersome, and
>> probably what i would end up doing is asking in Differential, the author 
>> would
>> have to answer, potentially either him or me forgetting about it.
>>
>> On reviewboard it was as simple as going to
>> https://git.reviewboard.kde.org/users/rikmills/ (that i just realized i could
>> have used instead of identity :D but it's going away so it's not a solution
>> either).
>
> This is the wrong solution.  Phabricator should provide the patch in a format
> that you can apply to the repository with git am -s , and get the
> original commit message, date and author.
>
> You should never have to enter the author or commit message yourself
> when you are committing something for someone else.

Phabricator also supports Subversion and Mercurial repositories, along
with reviews for which a repository is not set.
It's also debatable which fields from the review should end up in the
commit message.

>
> Fredrik
>

Regards,
Ben

Re: Finding contributor email is imposible - was - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Tue, Feb 7, 2017 at 3:30 PM, Michael Pyne <mp...@kde.org> wrote:
> On Mon, Feb 06, 2017 at 11:35:15PM +0100, Albert Astals Cid wrote:
>> El diumenge, 29 de gener de 2017, a les 8:32:21 CET, Ben Cooksley va 
>> escriure:
>> > Hi everyone,
>> >
>> > From this point forward, communities should be moving away from
>> > Reviewboard to Phabricator for conducting code review. Sysadmin will
>> > be announcing a timeline for the shutdown of Reviewboard in the near
>> > future.
>>
>> Today i wanted to commit https://phabricator.kde.org/D4432 since the person
>> that opened it does not have a developer account.
>>  
>>
>> ouch, so i need his email, where do i get it?
>>
>> Nowhere it seems.
>>
>> I resorted to searching for it in identity.kde.org but i think that i can 
>> only
>> do that because i have some special power over there that allows me to see
>> everyone's email, and even if everyone can, it's very cumbsersome, and
>> probably what i would end up doing is asking in Differential, the author 
>> would
>> have to answer, potentially either him or me forgetting about it.

Hi all,

In relation to this issue please continue this at
https://phabricator.kde.org/T5242
If we could keep the discussion in a single place that would be appreciated.

>
> In fairness to Phabricator there's been times where I've needed
> developer contact info *without* having a RR available.  In the "good
> old days" we'd just use the kde-common/accounts file to lookup the
> developer's id and corresponding email address, and that worked fine.

The kde-common/accounts file is still being maintained, however
Sysadmin does intend to disconnect Subversion usernames from
everything else, to avoid the arguments over usernames we have with
some people.

>
> So I think Identity (and in general whatever our KDE organizational
> directory solution happens to be) is the proper solution -- although it
> shouldn't need superpowers to actually see those identities.  And of
> course, there's no reason not to also show the email in Phabricator,
> which would be more helpful and developer-friendly.

We'll probably only be able to address this when the replacement to
Identity is built, as existing users accepted a privacy policy which
stated we wouldn't publish their details.

We'll have to be careful how this is done however, knowing the privacy
activists we have lurking around.

Sysadmin has received many requests in the past to have Bugzilla
accounts removed because "you're exposing my email address" even
though the site says in a massive font that your email address will be
made public when your register.

>
> Regards,
>  - Michael Pyne

Regards,
Ben

Re: Phabricator differential is not good - WAS - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Sat, Feb 4, 2017 at 1:15 PM, Kai Uwe Broulik  wrote:
>> This is not ok, the web interface for reviewboard was as good as rb-tools (I 
>> guess tbh i never used them) and "forcing" the use of a weird tool noone has 
>> heard of is not a good way to attract new contributors
>
> Agreed. Especially since arc is some mental php script that randomly amends 
> wrong revisions and/or adds files deliberately left unstaged.

Faults with Arcanist should be reported to upstream, at
https://secure.phabricator.com/
Some of the issues you are seeing could be edge cases which Arcanist
is not handling properly.

Please make sure you have updated to the latest versions of Arcanist
and libphutil before you do so.

>
> As for the context I usually end up uploading diffs with -U99 but that's not 
> ideal and it had never been an issue with ReviewBoard.
>
> ‎I also find the way to access revision patchset diffs cumbersome. The fact 
> that online comments aren't versioned and stick around even if the diff 
> changed significantly in later iterations is quite annoying. They also don't 
> provide code snippets in the list of comments, you always have to jump to the 
> specific line to see what's up there.

The request for code snippets in the comments area would be a feature
request - which should be filed with upstream.

In relation to versioning, I can see your point, however I can also
see the rationale behind retaining them until they've been resolved.
This is a behavioural difference between Phabricator and Reviewboard.
You are welcome to discuss the issue with upstream.

>
> The repository search when uploading a diff is also pretty dumb, always 
> defaulting to the least sensible option: Querying for "plasma workspace" 
> automatically chooses Plasma Workspace Wallpapers, "kio" ends up with KIO 
> AudioCD or Gopher...

There are upcoming changes to Differential and Diffusion which may
affect this. I do know that there have been some changes to search and
typeaheads within Phabricator recently.

See https://secure.phabricator.com/T12010 for more details on the
changes which they'll be undertaking over the next few months.

We've yet to deploy any of those changes, but will probably do so
fairly soon. There are some significant infrastructural changes to
Differential which will form part of the changes, and which could
possibly resolve the minor issue Albert pointed out in the first mail
of this thread.

>
> Nevertheless I got quite used to Phabricator, at least Differential, and 
> don't really miss RB especially since it got painfully slow ever since a 
> gazillion Frameworks repositories were created. In conjunction with Plasma 
> 5.9's drag and drop notification feature and Spectacle creating illustrated 
> revisions is a breeze.

Thanks for the positive feedback.

Cheers,
Ben

Re: Differential commit log keyword is uncomfortable - WAS - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Sun, Feb 5, 2017 at 6:30 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El diumenge, 29 de gener de 2017, a les 8:32:21 CET, Ben Cooksley va escriure:
>> Hi everyone,
>>
>> We've just completed the registration of all mainline repositories
>> (not including Websites or Sysadmin namespaced ones) on Phabricator.
>> Thanks go to Luigi Toscano for providing significant assistance with
>> this process.
>>
>> From this point forward, communities should be moving away from
>> Reviewboard to Phabricator for conducting code review.
>
> https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages
>
> Differential Revision: https://phabricator.kde.org/D
>
> can we get something much shorter like
>
> DIFFERENTIAL: D
> or even
> DIFFERENTIAL: 
> ?

This hook is provided by Phabricator upstream, and is processed by
Phabricator itself, not our code.

At the moment we're taking the line that to protect our ability to
continue to maintain Phabricator in an orderly fashion, we'll be
making very little if any changes to Phabricator. I'd therefore rather
not have to make this change. Please be aware that upstream is making
changes in a rapid manner, so even small changes can quickly become a
support burden.

Changing it would also break compatibility with Arcanist, which
automatically inserts this line when it's used.

I'll also note that Differential Revision: *MUST* be the last line in
a commit message, otherwise it won't trigger.

>
> I guess making both work should not be hard.
>
> The fact that you have to write "Differential Revision:" vs REVIEW: CCMAIL: 
> BUG: etc is quite "strange"
>
> Also neededing to include the full url is not very comfortable when writing.

If you are referencing Phabricator tasks in a commit message you can
write either "Ref Txxx" or "Fixes Txxx" which is the equivalent hook
for those. So long as it's on it's own line, it can appear anywhere in
a commit message.

>
> Does anyone have love for the current syntax?
>
> Cheers,
>   Albert

Regards,
Ben

Re: CI trouble

[Ben Cooksley]

On Sun, Feb 5, 2017 at 8:45 AM, Nicolás Alvarez
 wrote:
> 2017-02-04 16:19 GMT-03:00 David Faure :
>> Today the CI seems capricious ;)
>>
>> - build.kde.org was down for a bit
>
> Yep, Jenkins ran out of memory in the JVM. Restarted a while ago.
>
>> - DNS problems in 
>> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kparts%20master%20kf5-qt5/409/console
>
> Bleh, no idea why this could be. I would have just triggered a
> rebuild, but there is one queued already.
>
>> - "QXcbConnection: Could not connect to display :99" problems in many cases 
>> like 
>> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kguiaddons%20master%20kf5-qt5/133/PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/kwordwraptest/
>
> One possible reason is that Xvfb from a previous build didn't quit, or
> quit but left a lock behind. However, Ben didn't find any stale locks
> in either build node. Still investigating...

>From what I can tell nothing is wrong - I'm not sure why this
happened. My only guess is there was a stale lock or something along
those lines and it's ended up being automatically cleaned up.

>
> --
> Nicolás

Cheers,
Ben

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Thu, Feb 2, 2017 at 11:51 PM, Harald Sitter <sit...@kde.org> wrote:
> On Thu, Feb 2, 2017 at 10:31 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>> On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano <luigi.tosc...@tiscali.it> 
>> wrote:
>>> Il 02.02.2017 10:09 Ben Cooksley ha scritto:
>>>
>>>> Hi all,
>>>>
>>>> As a starting point: keeping the software itself running is a
>>>> non-starting option from my perspective. It's going to be shutdown.
>>>> This is purely to reduce the amount of maintenance effort we have to
>>>> expend in keeping our systems running.
>>>
>>>
>>> Sorry Ben, but this is not the solution. See below.
>>>
>>>> There is an enormous amount of software and other systems deployed on
>>>> our infrastructure, and the value of continuing to maintain software,
>>>> including associated security updates, major upgrades to ensure we're
>>>> able to continue running it on modern distributions, etc for something
>>>> which is no longer in active use is questionable at best. Bitrot and
>>>> decay is almost guaranteed to erode the value of it as a historical
>>>> archive in the long run in any case.
>>>>
>>>> For those who dismiss decay as an issue - problems with previous
>>>> Reviewboard upgrades not taking cleanly have resulted in some reviews
>>>> being damaged, causing their diffs to become unavailable. These sorts
>>>> of problems do happen.
>>>
>>>
>>> If it is a resource problem, it can be addressed elsewhere as well. The e.V.
>>> can hire people.
>>>
>>>> Whether some kind of read only archive is retained is another topic
>>>> altogether.
>>>>
>>>> Reviewboard has a WebAPI which should be usable by anyone interested
>>>> to extract all the information regarding reviews, including their
>>>> comments and the diff itself. This could be used to create a static
>>>> snapshot of each review.
>>>
>>>
>>> Here I disagree, I think it is exactly the same issue. Without a read only
>>> archive, easily accessibile like the current reviewboard (for which a static
>>> copy will be the best solution), we need to keep the site up and it is not
>>> thinkable that anyone would go and extract single reviews. It should be
>>> available for all the content.
>>
>> The above point was giving an indication of how exactly someone with a
>> vested interest in creating a read only archive would go about it.
>> Whilst I haven't checked, I would imagine API exists to retrieve the
>> list of reviews (although it's an incrementing number, with a large
>> gap between the last number of SVN reviews and the first of the Git
>> reviews)
>>
>> This isn't a task which has to be done by Sysadmin - the Reviewboard
>> WebAPI is accessible (within reasonable usage of course) to anyone
>> with an Identity account. To be honest it would be better that it be
>> done by someone who works with the reviews, as they'll be more aware
>> of the issues surrounding various forms of presentation (threading,
>> etc) that needs to be taken care of.
>
> Come shutdown day, disable login and then dump the website with wget
> or something alike. Someone who's complaining can write a script so
> sysadmins don't have to spend time on this ...
>
> Here's your starting point
> wget --mirror --convert-links --backup-converted --adjust-extension
> --page-requisites https://git.reviewboard.kde.org
>
> Then use that to replace the php version. The builtin search won't
> work but such is life.

Reviewboard is a Python application :)

>
> http://i.imgur.com/A9z0RYJ.png

Interesting, I would have assumed that due to all the AJAX it uses
that a wget mirror wouldn't work...
We've used that a few times to shutdown things like old Akademy sites,
so if it works that's fine with me.

Cheers,
Ben

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On 1/02/2017 10:38 PM, "René J.V. Bertin" <rjvber...@gmail.com> wrote:

On Wednesday February 1 2017 22:16:50 Ben Cooksley wrote:

>We'd still have to keep the software running, and up to date (to avoid
>it becoming a security risk).

Running yes, but if log-in is disabled at the core and not linked to the
central LDAP service or whatever it is you use, what significant security
risk could it pose?
I don't have the impression the software has been upgraded that frequently
but I haven't been monitoring that either.


It gets upgraded, particularly when there is a security advisory. Most
Reviewboard updates don't make user visible changes though - they're minor
bug fix updates.

Reviewboard would still be running on the server - and all the issues that
come with that.


>I'd prefer to optimise our resources towards keeping what we are
>actively using in the best condition, rather than having to remain
>concerned with keeping legacy systems running for purely archival
>purposes.
>
>We have a significant amount of systems already (and associated
>technical debt in some instances). Let's not make the problem any
>worse please.

I guess it depends on the importance you attach on being able to retrieve
things from revision and review histories. That's not to say it should be
kept around online forever, but I'd say 2 years is a reasonable time to
keep providing read-only access before archiving and taking everything
offline for good.
I'd offer to help during that period but without any experience with the
associated kind of sysadminship I'm not convinced that would be of much
value.

I take it you investigated whether there is any existing way to transfer
existing records from ReviewBoard to Phabricator? That would make the whole
issue moot.


Migrating things, particularly line by line comments, was too difficult
compared to the benefit provided.


R.


Regards,
Ben

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On 2/02/2017 12:41 AM, "Luigi Toscano"  wrote:

On Wednesday, 1 February 2017 10:31:44 CET Francis Herne wrote:
> Sorry, forgot to reply-all and only sent to kdevelop-devel...
>
> -
>
> Hi,
>
> First off, there's a lot of postponed, or at least possibly-useful,
> work on ReviewBoard which would be lost. Some of this is from newish
> contributors who might be discouraged - e.g. the author of
> https://git.reviewboard.kde.org/r/129589/ mentioned on IRC the other
> day that he's hoping to complete it at some point.


I think that we need some cleanup on the old reviews (Albert Astal Cid
started
some time ago) and more important strongly tell new users (and old users) to
use Phabricator. I don't think that anyone wants to lose the work, but if a
review has not been touched in a few months maybe it's time to see it is
still
interesting.
If we start doing this now (or yesterday), the flow of new patches in
reviewboard should decrease quickly.


Getting everyone to shift over was the whole point of this thread. No new
reviews should be opened on ReviewBoard, and existing ones shouldnt take
more than a few weeks to clear.

Anything older than that usually won't apply to the code anymore.



> For already-committed work:
>
> Even if the mail-archiving infrastructure was in a useful state, this
> would be inconvenient - there are more than a *thousand* REVIEW: tags in
> kdev* project commits, plus several comments with "see ".
>
> Many mailing lists aren't logged at all, there's no internal
> search with only patchy Google indexing, and 'browsing' the archive
> means clicking through arbitrarily-grouped mails by date with minimal
> threading. That's not merely inconvenient, it's going to cause a
> catastrophic loss of information.

I agree as well that the review information should be kept online.

--
Luigi


Regards,
Ben

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Wed, Feb 1, 2017 at 9:48 PM, Milian Wolff <m...@milianw.de> wrote:
> On Tuesday, January 31, 2017 7:56:52 PM CET Ben Cooksley wrote:
>> On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin <rjvber...@gmail.com>
> wrote:
>> > On Sunday January 29 2017 08:32:21 Ben Cooksley wrote:
>> >
>> > Hi,
>>
>> Hi Rene,
>>
>> > >From this point forward, communities should be moving away from
>> >>
>> >>Reviewboard to Phabricator for conducting code review. Sysadmin will
>> >>be announcing a timeline for the shutdown of Reviewboard in the near
>> >>future.
>> >>
>> > I hope that shutdown doesn't mean complete disconnect; it would probably
>> > be a loss of as-yet unknown importance if all code reviews become
>> > unavailable.
>> >
>> > I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile,
>> > but RB had its advantages too which could be why it's still being used
>> > (quite a lot, as far as I can see) and hasn't been integrated with KDE's
>> > own IDE yet.
>>
>> It will be a complete shutdown of Reviewboard - we'll be archiving it
>> in the event for some reason it becomes necessary to access the data
>> it stores.
>
> This is a *very* bad idea!
>
> - Quite some commits will lose some extended history from the review comments
> - What about the not-yet-merged changes?

There will sufficient time between now and when the shutdown is
actually actioned during which it's expected any remaining reviews can
either be finished off, or moved to Phabricator (As said in my
original mail, we'll be publishing a timeline for this - which will
have stages where no new reviews can be opened, etc)

>
> If at all possible, please find a way to keep this site alive in a read-only
> mode.
>
>> In most cases mailing lists should have the history of reviews in
>> their archives, so those will continue to be accessible through list
>> archives in the long run.
>
> And how do you find the corresponding mail archive thread based on a
> reviewboard URL? Will there be auto-forwarding in-place?

There won't be any auto-forwarding - we'll be removing the subdomains
completely.
>
> Bye
>
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

Cheers,
Ben

Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

Hi everyone,

We've just completed the registration of all mainline repositories
(not including Websites or Sysadmin namespaced ones) on Phabricator.
Thanks go to Luigi Toscano for providing significant assistance with
this process.

>From this point forward, communities should be moving away from
Reviewboard to Phabricator for conducting code review. Sysadmin will
be announcing a timeline for the shutdown of Reviewboard in the near
future.

Projects which haven't yet looked into Phabricator, including getting
things like mailing list notifications and projects setup should do so
as soon as practical.

As part of the registration process, Sysadmin tagged repositories,
associating them to Projects. These tags show what a repository is
associated with and it's status.

This includes things like whether development is currently active (the
Historical Archival and Up For Adoption tags), which release unit it
is part of (KDE Applications, Frameworks, etc) and the general
development effort it is associated with.

It would be appreciated if everyone could please check their
repositories to ensure they've been tagged correctly. Adjustments can
either be sent as replies to this email (include sysadmin@ in CC
please) or by asking a member of the Community Admins project on
Phabricator to make the change for you.

Thanks,
Ben Cooksley
KDE Sysadmin

Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

Hi everyone,

We've just completed the registration of all mainline repositories
(not including Websites or Sysadmin namespaced ones) on Phabricator.
Thanks go to Luigi Toscano for providing significant assistance with
this process.

>From this point forward, communities should be moving away from
Reviewboard to Phabricator for conducting code review. Sysadmin will
be announcing a timeline for the shutdown of Reviewboard in the near
future.

Projects which haven't yet looked into Phabricator, including getting
things like mailing list notifications and projects setup should do so
as soon as practical.

As part of the registration process, Sysadmin tagged repositories,
associating them to Projects. These tags show what a repository is
associated with and it's status.

This includes things like whether development is currently active (the
Historical Archival and Up For Adoption tags), which release unit it
is part of (KDE Applications, Frameworks, etc) and the general
development effort it is associated with.

It would be appreciated if everyone could please check their
repositories to ensure they've been tagged correctly. Adjustments can
either be sent as replies to this email (include sysadmin@ in CC
please) or by asking a member of the Community Admins project on
Phabricator to make the change for you.

Thanks,
Ben Cooksley
KDE Sysadmin

Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

Hi everyone,

We've just completed the registration of all mainline repositories
(not including Websites or Sysadmin namespaced ones) on Phabricator.
Thanks go to Luigi Toscano for providing significant assistance with
this process.

>From this point forward, communities should be moving away from
Reviewboard to Phabricator for conducting code review. Sysadmin will
be announcing a timeline for the shutdown of Reviewboard in the near
future.

Projects which haven't yet looked into Phabricator, including getting
things like mailing list notifications and projects setup should do so
as soon as practical.

As part of the registration process, Sysadmin tagged repositories,
associating them to Projects. These tags show what a repository is
associated with and it's status.

This includes things like whether development is currently active (the
Historical Archival and Up For Adoption tags), which release unit it
is part of (KDE Applications, Frameworks, etc) and the general
development effort it is associated with.

It would be appreciated if everyone could please check their
repositories to ensure they've been tagged correctly. Adjustments can
either be sent as replies to this email (include sysadmin@ in CC
please) or by asking a member of the Community Admins project on
Phabricator to make the change for you.

Thanks,
Ben Cooksley
KDE Sysadmin

Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

Hi everyone,

We've just completed the registration of all mainline repositories
(not including Websites or Sysadmin namespaced ones) on Phabricator.
Thanks go to Luigi Toscano for providing significant assistance with
this process.

>From this point forward, communities should be moving away from
Reviewboard to Phabricator for conducting code review. Sysadmin will
be announcing a timeline for the shutdown of Reviewboard in the near
future.

Projects which haven't yet looked into Phabricator, including getting
things like mailing list notifications and projects setup should do so
as soon as practical.

As part of the registration process, Sysadmin tagged repositories,
associating them to Projects. These tags show what a repository is
associated with and it's status.

This includes things like whether development is currently active (the
Historical Archival and Up For Adoption tags), which release unit it
is part of (KDE Applications, Frameworks, etc) and the general
development effort it is associated with.

It would be appreciated if everyone could please check their
repositories to ensure they've been tagged correctly. Adjustments can
either be sent as replies to this email (include sysadmin@ in CC
please) or by asking a member of the Community Admins project on
Phabricator to make the change for you.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Screenshot hosting repo (e.g. for Appstream)

[Ben Cooksley]

On Sun, Jan 22, 2017 at 8:08 AM, Elvis Angelaccio
 wrote:
> On Tue, Nov 29, 2016 at 9:55 AM, Harald Sitter  wrote:
>> Hey,
>>
>> We have just finished sorting out a centralized screenshot repo. This
>> repo should be used for promotional screenshots of KDE software.
>> Specifically, when using screenshots for appstream data you should put
>> your screenshots in there and reference them via
>> https://cdn.kde.org/screenshots/
>>
>> git clone kde:websites/product-screenshots
>> https://phabricator.kde.org/source/websites-product-screenshots/
>>
>> Mind the readme.
>
> Hi,
> if I try to push to this repo I get the following error:
>
> FATAL: W any websites/product-screenshots elvisangelaccio DENIED by fallthru
>
> Looking at "ssh g...@git.kde.org info" it seems this repo doesn't have
> write access for normal users, unlike websites/planet-kde-org.
> Could we change this? I don't think we want a sysadmin ticket just for
> uploading a screenshot.

As this seems reasonable enough, i've now made this the case.

>
> Cheers,
> Elvis
>
>>
>> HS

Cheers,
Ben

Project Releases: Infrastructure Migration

[Ben Cooksley]

Hi everyone,

To allow for Sysadmin to migrate the primary host for download.kde.org
and files.kde.org to another server (with significantly more disk
space) we'll need to make both of those read only for a period of time
this weekend.

During this period, it will not be possible to add/remove files to
those trees - which means projects will not be able to make releases.

To the knowledge of Sysadmin, this does not affect the release of any
project, however anyone who had plans should please contact us
immediately.

Regards,
Ben Cooksley
KDE Sysadmin

Project Releases: Infrastructure Migration

[Ben Cooksley]

Hi everyone,

To allow for Sysadmin to migrate the primary host for download.kde.org
and files.kde.org to another server (with significantly more disk
space) we'll need to make both of those read only for a period of time
this weekend.

During this period, it will not be possible to add/remove files to
those trees - which means projects will not be able to make releases.

To the knowledge of Sysadmin, this does not affect the release of any
project, however anyone who had plans should please contact us
immediately.

Regards,
Ben Cooksley
KDE Sysadmin

Phabricator updated

[Ben Cooksley]

Hi all,

Over the weekend we've updated our Phabricator instance to the latest
stable version. This has brought in a few changes which you may wish
to check out - including the ability to customise the global home menu
and setup a favourites menu for yourself to access frequently used
functions.

As the global items setup by Sysadmin cannot be overridden by users,
i've only setup a very basic set of items for everyone to use.

For those who use Arcanist, now would be a good time for you to ensure
you are running the latest stable version as well. For those not using
Arcanist, please note that usage is strongly encouraged.

Regards,
Ben

Migration of Download Infrastructure: Please check your applications

[Ben Cooksley]

Hi all,

Sysadmin have now completed the migration of our file distribution
systems, download.kde.org and files.kde.org, to a new server. During
this migration we also enabled mandatory https for both.

Because QNetworkAccessManager does not follow redirects by default (at
least in a significant number of versions of Qt - I seem to recall
this may have been changed at some point), we advise everyone to
please check their applications to ensure that anything which
interacts with download.kde.org or files.kde.org still operates
correctly.

Should your application be negatively impacted by this, please
implement support for handling redirects in the appropriate place,
then let us know so we can consider options for keeping your
applications functional.

Regards,
Ben

Migration of Download Infrastructure: Please check your applications

[Ben Cooksley]

Hi all,

Sysadmin have now completed the migration of our file distribution
systems, download.kde.org and files.kde.org, to a new server. During
this migration we also enabled mandatory https for both.

Because QNetworkAccessManager does not follow redirects by default (at
least in a significant number of versions of Qt - I seem to recall
this may have been changed at some point), we advise everyone to
please check their applications to ensure that anything which
interacts with download.kde.org or files.kde.org still operates
correctly.

Should your application be negatively impacted by this, please
implement support for handling redirects in the appropriate place,
then let us know so we can consider options for keeping your
applications functional.

Regards,
Ben

Migration of Download Infrastructure: Please check your applications

[Ben Cooksley]

Hi all,

Sysadmin have now completed the migration of our file distribution
systems, download.kde.org and files.kde.org, to a new server. During
this migration we also enabled mandatory https for both.

Because QNetworkAccessManager does not follow redirects by default (at
least in a significant number of versions of Qt - I seem to recall
this may have been changed at some point), we advise everyone to
please check their applications to ensure that anything which
interacts with download.kde.org or files.kde.org still operates
correctly.

Should your application be negatively impacted by this, please
implement support for handling redirects in the appropriate place,
then let us know so we can consider options for keeping your
applications functional.

Regards,
Ben

Communication with Phabricator upstream

[Ben Cooksley]

Hi all,

To help simplify things for Phabricator upstream, they've asked that
only a couple of people bring things to their attention (including
filing tasks). This helps them with figuring out our priorities as a
project in regards to usage of Phabricator.

Please therefore file all issues / etc you hit regarding Phabricator
on our own instance, tagging them with the project "Phabricator".

At the moment i'm the one liasing with them primarily, although i'll
be looking to bring one or two others on board soonish.

Thanks,
Ben

Communication with Phabricator upstream

[Ben Cooksley]

Hi all,

To help simplify things for Phabricator upstream, they've asked that
only a couple of people bring things to their attention (including
filing tasks). This helps them with figuring out our priorities as a
project in regards to usage of Phabricator.

Please therefore file all issues / etc you hit regarding Phabricator
on our own instance, tagging them with the project "Phabricator".

At the moment i'm the one liasing with them primarily, although i'll
be looking to bring one or two others on board soonish.

Thanks,
Ben

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 19, 2017 at 6:29 AM, Eike Hein  wrote:
>
>
> On 01/17/2017 11:46 PM, Adriaan de Groot wrote:
>> But CI has a really important function: it shows us the health of the sources
>> for everything; and that's something the release team needs, and the whole
>> community can be interested in. So "opting out" of CI deprives us of a good
>> view of the state of our software products.
>
> Agreed. But under the proposed document, you can essentially only
> opt out by behaving so badly that sysadmin sees no choice but to
> kick you out, and it labels that as "rude". I think it also
> communicates why we care about CI (e.g. as regression catcher).

Indeed, that has basically been the case.

>
> This thread has slowed down now - there's been no strong objections
> raised to the current version of the doc. If everyone is happy with
> it, I propose we start linking it from the /Policies/ main page by
> start of February and try to live with it.
>
> As for the current situation with xkbcommon, it happened before
> we sat down to write this, and I'd say we don't try to shoehorn
> it into the framework after the fact. AIUI it sysadmin/packagers
> are working to procure the needed dependency, so we'll let them
> do so ...

It's already been fixed - by having the CI build libxkbcommon. It was
also required to build an updated version of xorg-macros upon which
that depended.
Libraries that depend on KWindowSystem will have the self-built
libxkbcommon made available to them.

Implementing this also required changes to the general CI
infrastructure for all jobs, to handhold Autotools based builds. We
did something similar for CMake already.

>
>
> Cheers,
> Eike
>

Regards,
Ben

[Differential] [Updated] D4201: Make it possible to lower KCrash to tier 1

[Ben Cooksley]

bcooksley updated the test plan for this revision.

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D4201

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #frameworks, dfaure
Cc: anthonyfieroni, graesslin

[sysadmin/ci-master-config] /: Revert "Disable new_delete_type_mismatch ASAN checks, due to defective Qt code."

[Ben Cooksley]

Git commit 74fecfd9f4dd09e21531cc5378d2f8dd55b0df35 by Ben Cooksley.
Committed on 16/08/2016 at 00:41.
Pushed by bcooksley into branch 'master'.

Revert "Disable new_delete_type_mismatch ASAN checks, due to defective Qt code."

This reverts commit 8bdb20f0189da74e9875be45822e7f9aa872543e.

CCMAIL: kde-devel@kde.org

M  +1-1base.groovy

http://commits.kde.org/sysadmin/ci-master-config/74fecfd9f4dd09e21531cc5378d2f8dd55b0df35

diff --git a/base.groovy b/base.groovy
index e925073..9b0cb30 100644
--- a/base.groovy
+++ b/base.groovy
@@ -366,7 +366,7 @@ while(projects.hasNext()) {
environmentVariables {
env('JENKINS_SLAVE_HOME', 
'/home/jenkins/scripts')
env('JENKINS_TEST_HOME', '/home/jenkins')
-   env('ASAN_OPTIONS', 
'detect_leaks=0:new_delete_type_mismatch=0')
+   env('ASAN_OPTIONS', 'detect_leaks=0')
env('XDG_CONFIG_DIRS', 
'/etc/xdg/xdg-plasma:/etc/xdg:/usr/share/:${JENKINS_TEST_HOME}/.qttest/config')
env('XDG_DATA_DIRS', 
'/usr:/usr/share:${JENKINS_TEST_HOME}/.local/share')
env('XDG_DATA_HOME', 
'${JENKINS_TEST_HOME}/.qttest/share:${JENKINS_TEST_HOME}/.local/share') 
   

Re: Re-enable new_delete_type_mismatch in ASAN?

[Ben Cooksley]

On Tue, Aug 16, 2016 at 9:34 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dijous, 4 d’agost de 2016, a les 19:40:14 CEST, Ben Cooksley va escriure:
>> On Thu, Aug 4, 2016 at 9:52 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > We disabled the new_delete_type_mismatch ASAN check a while ago because Qt
>> > was at fault and creating "false positives" in our code.
>> >
>> > Since then the Qt code has been fixed (i think), so should we re-enable
>> > the
>> > check?
>>
>> We currently run Qt 5.6 and 5.7 on the CI system, using Git revisions
>> 6fbf179f7396cf544dd7c204b619dc3552e2bfb0 and
>> 447361eb68a7c9c5b5e0985157c39da1e9924d43 respectively.
>>
>> Do these revisions contain the needed fixes?
>
> From what i can see yes, it seems it does.
>
> Can you please enable it and see if it is good? (Hopefully no regression in
> their or our side was added?).

I've now done so.

>
> Cheers,
>   Albert

Thanks,
Ben

>
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Regards,
>> Ben
>
>

Re: Differential e-mail subject re-arrangement

[Ben Cooksley]

On Thu, Mar 2, 2017 at 10:08 AM, Dominik Haumann  wrote:
> Hi,

Hi all,

>
> On Wed, Mar 1, 2017 at 4:16 PM, David Faure  wrote:
>> On mercredi 1 mars 2017 13:35:47 CET Kevin Funk wrote:
>>> On Tuesday, 28 February 2017 21:31:44 CET Michael Pyne wrote:
>>> > On Tue, Feb 28, 2017 at 08:38:12PM +0100, Ivan Čukić wrote:
>>> > > >   [Differential] D4508: Plasma controls based on QtQuickControls2
>>> > > >   [Commented On]> >
>>> > > >
>>> > > > I personally find that having a "vertical" line in which all the
>>> > > > subjects of the differential emails start makes it much easier to
>>> > > > read.>
>>> > >
>>> > > +1 I'd even shorten The 'Differential' part of it to just 'Diff'.
>>> >
>>> > Agreed to both.
>>>
>>> +1
>>
>> Yes, totally, and I would even like the repo name to be added...
>>
>> But
>>
>> https://secure.phabricator.com/D9342 "Make Differential email subject more
>> configurable.", ABANDONED.
>>
>> https://secure.phabricator.com/T5244 "Allow email subjects and bodies to be
>> more customizable", CLOSED, WONTFIX.
>>
>> https://secure.phabricator.com/T10283 "improve differential emails, 
>> optimizing
>> for efficiency", Open, for a year.
>>
>> and my own request, https://secure.phabricator.com/T10874, Open, for almost a
>> year.
>>
>> Why did we pick a tool where upstream consistently refuses to make any 
>> changes
>> that would actually make sense? :(
>>
>> (see also https://phabricator.kde.org/T5437, "arcanist: option to ignore
>> untracked files")

I'd like to start by pointing out the following document which
upstream works by for functionality changes:
https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Note that T5244 being rejected is completely understandable from a
functionality point of view. For the record, Reviewboard is the same
in this manner (it doesn't permit mail customisation from the Admin
interface either, it requires code changes).

In regards to the way email subjects are treated, I've now customised
the metamta.differential.subject-prefix preference on our installation
to be blank, to the "[Differential]" part should no longer be present.

I have also changed the default for metamta.vary-subjects, which is a
per user setting. Anyone who likes the line count changed indicators
should open https://phabricator.kde.org/settings/, Open Email Format,
and change "Vary Subjects" to Enabled.

>
> This is unfortunate: I have the *feeling* that the automatically
> generated mails contain a lot of noise. I would appreciated to reduce
> the contents to a minimum. For instance, imo the commit mails on
> kde-commits are just perfect.
>
> With respect to the Differential subjects, I would prefer:
> [ktexteditor] D1234: Change this and that... bla bla
>
> Currently, the string "[Differential]" is 100% noise, it provides zero
> information, since the D1234 already tells me this is a patch.
> Also, I don't need any "[Updated]", or "[Request, 56 lines]" in the subject.
>
> Similarly, since the repository is ideally already in the subject, I
> don't want this to be bold and big again stretched over 3 lines in the
> email contents. The same holds for the branch, it should be in the
> subject, e.g. [ktexteditor/some_branch_name].
>
> Reviewboard was much better here.
>
> KDE is traditionally always very strong technically. We need to keep
> this strength also in our infrastructure: Provide exactly the info
> that is required, up to the point, and not more. This is essential to
> getting work done quickly. The Phab generated mails are step backward
> here, imho :-) Would be awesome if this could be improved.

We'd need a strong use case to explain to upstream why repository
should be in the Subject, and then removed from the Email.
The above is mostly (from what I can tell at least) a case of personal
preference, so isn't something we'll be able to get upstream support
for.

>
> Best regards,
> Dominik

Regards,
Ben

Re: Various CI build failures

[Ben Cooksley]

On Thu, Sep 1, 2016 at 10:57 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dimecres, 31 d’agost de 2016, a les 20:48:31 CEST, Ben Cooksley va
> escriure:
>> On Wed, Aug 31, 2016 at 9:15 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > El dimarts, 30 d’agost de 2016, a les 21:52:58 CEST, Ben Cooksley va
> escriure:
>> >> Hi all,
>> >>
>> >> The following projects currently fail to build on the CI system - can
>> >> the respective devels please investigate and fix?
>> >>
>> >> - Minuet: You are depending on a version of Qt which is not available
>> >> in stable releases at this time. Please restore compatibility with Qt
>> >> 5.6.x.
>> >
>> > As far as i know that's unfixable, Minuet uses QtQuickControls 2 that is
>> > simply not available in Qt 5.6
>> >
>> > Can we maybe somehow disable the CI job for the time being?
>>
>> This could be accomplished through one of two ways:
>>
>> 1) Delete the stable branch for Minuet from logical-module-structure,
>> which would also remove it from kdesrc-build and LXR (I think)
>> 2) Remove it from the CI's list of enabled projects, which would
>> remove Minuet from the CI system completely.
>>
>> Neither is a particularly great option
>> Thoughts?
>
> Just leave the stable job failing as it is now?

Guess it will have to be...

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Cheers,
>> Ben
>
>

Re: Various CI build failures

[Ben Cooksley]

On Wed, Aug 31, 2016 at 11:49 PM, Michael Palimaka
<kensing...@gentoo.org> wrote:
> On 30/08/16 19:52, Ben Cooksley wrote:
>> Additionally, would anyone mind if CI coverage were dropped for the 
>> following:
>>
>> - libechonest Qt 5 branches
>
> I can't speak on behalf of whoever maintains this, but the Echo Nest API
> has been shutdown for some months now so I doubt coverage of this
> library would be missed.

Hi Michael,

Thanks for that info - I concur with you there and have now disabled
it's Qt 5 coverage.

Regards,
Ben

Re: Various CI build failures

[Ben Cooksley]

On Wed, Aug 31, 2016 at 9:15 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dimarts, 30 d’agost de 2016, a les 21:52:58 CEST, Ben Cooksley va escriure:
>> Hi all,
>>
>> The following projects currently fail to build on the CI system - can
>> the respective devels please investigate and fix?
>>
>> - Minuet: You are depending on a version of Qt which is not available
>> in stable releases at this time. Please restore compatibility with Qt
>> 5.6.x.
>
> As far as i know that's unfixable, Minuet uses QtQuickControls 2 that is
> simply not available in Qt 5.6
>
> Can we maybe somehow disable the CI job for the time being?

This could be accomplished through one of two ways:

1) Delete the stable branch for Minuet from logical-module-structure,
which would also remove it from kdesrc-build and LXR (I think)
2) Remove it from the CI's list of enabled projects, which would
remove Minuet from the CI system completely.

Neither is a particularly great option
Thoughts?

>
> Cheers,
>   Albert

Cheers,
Ben

Various CI build failures

[Ben Cooksley]

Hi all,

The following projects currently fail to build on the CI system - can
the respective devels please investigate and fix?

- GCompris: Tries to use a CMake feature which the version on the CI
system does not support. Please restore compatibility with earlier
CMake versions (the CI system is not that old)

- Plasma SDK: Your dependency metadata is out of date - please update it.

- Smb4k: Your CMake version check is too aggressive, please restore
compatibility.

- KsCD: Appears to have identical development and stable branches for
KF5 which looks like a port in progress. Please remove the
non-released stable branch from the metadata.

- KIO GDrive: You appear to be missing dependencies for your build,
please file a sysadmin request to have that dependency made available.

- KMouth: Qt Text To Speech - does anyone know when this becomes available?

- Minuet: You are depending on a version of Qt which is not available
in stable releases at this time. Please restore compatibility with Qt
5.6.x.

Additionally, would anyone mind if CI coverage were dropped for the following:

- Apper Qt 4 branches
- Kolor Manager (all versions)
- libechonest Qt 5 branches
- libqgit2 Qt 4 branches
- Plasma Mediacenter Qt 4 branches
- telepathy-logger-qt Qt 4 branches

Cheers,
Ben

Re: Outstanding umbrello tarball move request

[Ben Cooksley]

On Tue, Aug 30, 2016 at 4:22 PM, Ralf Habacker  wrote:
> Hi,

Hi Ralf,

>
> a few weeks ago, KDE sysadmin requests has been switched to
> phabricator.  After that I filed a tar ball move request for umbrello
> for windows 2.19.3 release (https://phabricator.kde.org/T3391) which has
> been released one day later.  The following tar ball move request for
> umbrello 2.20.0 (https://phabricator.kde.org/T3455) has not been
> released for two weeks now.
>
> Does anyone have an idea what's going wrong ?

The task you entered was filed incorrectly - we never even saw it.
Additionally, you've emailed kde-devel@kde.org rather than
sysad...@kde.org, so I only saw this because i'm a subscriber. Chances
are at least one of the sysadmins isn't subscribed to this list.

Phabricator tracks much more than Sysadmin tasks, so you have to tag
them with #Sysadmin if creating tasks through the normal "Create
Tasks" form.
For this reason, and to allow for private tasks to be entered, there
is a "New Sysadmin Request" form which will set everything up
appropriately which we recommend people use instead.

I've now added the Sysadmin project to the task, so it'll be queued up
to be actioned when someone is next available.

>
> Regards
>
>  Ralf
>

Cheers,
Ben

Re: Various CI build failures

[Ben Cooksley]

On Tue, Aug 30, 2016 at 9:56 PM, Bhushan Shah <bhus...@gmail.com> wrote:
> Hello Ben,
>
> On Tue, Aug 30, 2016 at 3:22 PM, Ben Cooksley <bcooks...@kde.org> wrote:
>> - Plasma Mediacenter Qt 4 branches
>
> I am fine with this.

Thanks, i've now actioned it.

>
> --
> Bhushan Shah
>
> http://blog.bshah.in
> IRC Nick : bshah on Freenode

Cheers,
Ben

Phabricator move and update

[Ben Cooksley]

Hi all,

Overnight Sysadmin has moved Phabricator from it's previous host to
it's new, permanent home. At the same time we also updated to the
latest stable version of Phabricator.

As a consequence of this update, previously undiscovered and unindexed
commits are now being indexed by Phabricator. Depending on your email
settings this may result in you having received a flood of emails for
prior commits you have made to repositories which are currently
recorded in Phabricator.

Going forward we'll be adjusting the default settings of users to not
send email for your own actions (the current upstream default) and
will probably reset everyone's preferences in this matter to ensure it
doesn't happen again.

Our apologies for any inconvenience caused by the migration or update.

If you experience any issues or problems with Phabricator post
migration, please let us know.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Wanted To Contribute In KDE

[Ben Cooksley]

Hi Lydia,

Rishi had earlier emailed me/Sysadmin and as part of that I sent him
some information on a task we'd like to accomplish as part of our
Phabricator migration.
I've yet to hear back how things are going though.

Cheers,
Ben

Re: kdereview

[Ben Cooksley]

On Fri, Sep 30, 2016 at 11:27 AM, Albert Astals Cid  wrote:
> El dimecres, 21 de setembre de 2016, a les 11:01:18 CEST, Allen Winter va
> escriure:
>> kwave is now moved to kdemultimedia.
>
> Why did that happen?

It was moved at the request of it's maintainer and Allen.

>
> Did i miss the emails to k-c-d about reviewing it?

I've just searched my mail - you didn't miss it. When the repository
was moved to KDE Review the Sysadmin ticket would have expressly
requested that the review process on kde-core-devel be started by the
maintainer now that we'd processed the move. It appears that didn't
happen.

Thoughts on what should be done in regards to KWave here?

>
> Cheers,
>   Albert

Cheers,
Ben

>
>> No response from anyone else.
>>
>> I suggest we remove bodega-client, kdev-perforce, kdots, kor and kpeg from
>> kde_projects.xml and virtually move them into scratch.
>>
>> On Sunday, September 18, 2016 12:08:41 PM Allen Winter wrote:
>> > Howdy,
>> >
>> > there's some stuff that's been in kdereview for a long time.
>> >
>> > according to kde_projects.xml, the kdereview programs are:
>> >   bodega-client (at least since Dec 2013)
>> >   kdev-perforce
>> >   kdots (at least since Nov 2015)
>> >   kor (at least since Oct 2014)
>> >   kpeg
>> >   kwave
>> >
>> > some of these (eg kwave) are actively developed.
>> >
>> > Can the owners of these please move them to a final location,
>> > clean them out, or let me know if they are really still under review?
>> >
>> > And by "move" I mean change their virtual location according to
>> > kde_projects or whatever "moving" means these days.
>> >
>> > -Allen
>
>

New project moved to review

[Ben Cooksley]

Hi all,

At the request of Elvis Angelaccio sysadmin has moved kio-gdrive to KDE Review.

Regards,
Ben Cooksley
KDE Sysadmin

[sysadmin/repo-metadata] projects/kdereview: Move kdb, kreport and kproperty to KDE Review as requested.

[Ben Cooksley]

Git commit fe1e155a099a56b44f216190c8bd6c2353631e95 by Ben Cooksley.
Committed on 07/10/2016 at 18:46.
Pushed by bcooksley into branch 'master'.

Move kdb, kreport and kproperty to KDE Review as requested.
CCMAIL: kde-core-devel@kde.org
Fixes T3957

R  +0-0projects/kdereview/kdb/i18n.json [from: 
projects/playground/libs/kdb/i18n.json - 100% similarity]
R  +1-1projects/kdereview/kdb/metadata.yaml [from: 
projects/playground/libs/kdb/metadata.yaml - 089% similarity]
R  +0-0projects/kdereview/kproperty/i18n.json [from: 
projects/playground/libs/kproperty/i18n.json - 100% similarity]
R  +1-1projects/kdereview/kproperty/metadata.yaml [from: 
projects/playground/libs/kproperty/metadata.yaml - 088% similarity]
R  +0-0projects/kdereview/kreport/i18n.json [from: 
projects/playground/libs/kreport/i18n.json - 100% similarity]
R  +1-1projects/kdereview/kreport/metadata.yaml [from: 
projects/playground/libs/kreport/metadata.yaml - 088% similarity]

http://commits.kde.org/sysadmin/repo-metadata/fe1e155a099a56b44f216190c8bd6c2353631e95

diff --git a/projects/playground/libs/kdb/i18n.json 
b/projects/kdereview/kdb/i18n.json
similarity index 100%
rename from projects/playground/libs/kdb/i18n.json
rename to projects/kdereview/kdb/i18n.json
diff --git a/projects/playground/libs/kdb/metadata.yaml 
b/projects/kdereview/kdb/metadata.yaml
similarity index 89%
rename from projects/playground/libs/kdb/metadata.yaml
rename to projects/kdereview/kdb/metadata.yaml
index d1ecb2d..a31249e 100644
--- a/projects/playground/libs/kdb/metadata.yaml
+++ b/projects/kdereview/kdb/metadata.yaml
@@ -7,7 +7,7 @@ members:
 - displayname: "Jaros\u0142aw Staniek"
   username: staniek
 name: KDb
-projectpath: playground/libs/kdb
+projectpath: kdereview/kdb
 repoactive: true
 repopath: kdb
 type: project
diff --git a/projects/playground/libs/kproperty/i18n.json 
b/projects/kdereview/kproperty/i18n.json
similarity index 100%
rename from projects/playground/libs/kproperty/i18n.json
rename to projects/kdereview/kproperty/i18n.json
diff --git a/projects/playground/libs/kproperty/metadata.yaml 
b/projects/kdereview/kproperty/metadata.yaml
similarity index 88%
rename from projects/playground/libs/kproperty/metadata.yaml
rename to projects/kdereview/kproperty/metadata.yaml
index 65a3151..89bbcac 100644
--- a/projects/playground/libs/kproperty/metadata.yaml
+++ b/projects/kdereview/kproperty/metadata.yaml
@@ -8,7 +8,7 @@ members:
 - displayname: "Jaros\u0142aw Staniek"
   username: staniek
 name: KProperty
-projectpath: playground/libs/kproperty
+projectpath: kdereview/kproperty
 repoactive: true
 repopath: kproperty
 type: project
diff --git a/projects/playground/libs/kreport/i18n.json 
b/projects/kdereview/kreport/i18n.json
similarity index 100%
rename from projects/playground/libs/kreport/i18n.json
rename to projects/kdereview/kreport/i18n.json
diff --git a/projects/playground/libs/kreport/metadata.yaml 
b/projects/kdereview/kreport/metadata.yaml
similarity index 88%
rename from projects/playground/libs/kreport/metadata.yaml
rename to projects/kdereview/kreport/metadata.yaml
index 4124635..207b455 100644
--- a/projects/playground/libs/kreport/metadata.yaml
+++ b/projects/kdereview/kreport/metadata.yaml
@@ -7,7 +7,7 @@ members:
 - displayname: "Jaros\u0142aw Staniek"
   username: staniek
 name: KReport
-projectpath: playground/libs/kreport
+projectpath: kdereview/kreport
 repoactive: true
 repopath: kreport
 type: project

Moved to KDE Review: KDb, KReport, KProperty

[Ben Cooksley]

Hi all,

Just a heads up that at the request of Jaroslaw Staniek, Sysadmin has
moved the following repositories to KDE Review:

- KDb (kdb)
- KReport (kreport)
- KProperty (kproperty)

>From my understanding these are used as part of Kexi.

Regards,
Ben

ECM Breakage: Compilation failure for GCC

[Ben Cooksley]

Hi all,

It appears that commit 4b8e8dcc8856d8f438860783e7641d02d1c05630 to ECM
broke the whole CI system for all Qt 5 / Frameworks builds.

I've therefore reverted it.

Regards,
Ben Cooksley
KDE Sysadmin

ECM Breakage: Compilation failure for GCC

[Ben Cooksley]

Hi all,

It appears that commit 4b8e8dcc8856d8f438860783e7641d02d1c05630 to ECM
broke the whole CI system for all Qt 5 / Frameworks builds.

I've therefore reverted it.

Regards,
Ben Cooksley
KDE Sysadmin

[sysadmin/repo-metadata] projects/kde/kdemultimedia/kwave: Move KWave to kde/kdemultimedia as requested.

[Ben Cooksley]

Git commit 40d2107dbe1a958a58bbcb314ab30c42e2b28e05 by Ben Cooksley.
Committed on 21/09/2016 at 08:34.
Pushed by bcooksley into branch 'master'.

Move KWave to kde/kdemultimedia as requested.
CCMAIL: release-t...@kde.org
CCMAIL: kde-core-devel@kde.org
CCMAIL: thomas.eschenbac...@gmx.de
CCMAIL: allen.d.win...@gmail.com

R  +0-0projects/kde/kdemultimedia/kwave/i18n.json [from: 
projects/kdereview/kwave/i18n.json - 100% similarity]
R  +1-1projects/kde/kdemultimedia/kwave/metadata.yaml [from: 
projects/kdereview/kwave/metadata.yaml - 096% similarity]

http://commits.kde.org/sysadmin/repo-metadata/40d2107dbe1a958a58bbcb314ab30c42e2b28e05

diff --git a/projects/kdereview/kwave/i18n.json 
b/projects/kde/kdemultimedia/kwave/i18n.json
similarity index 100%
rename from projects/kdereview/kwave/i18n.json
rename to projects/kde/kdemultimedia/kwave/i18n.json
diff --git a/projects/kdereview/kwave/metadata.yaml 
b/projects/kde/kdemultimedia/kwave/metadata.yaml
similarity index 96%
rename from projects/kdereview/kwave/metadata.yaml
rename to projects/kde/kdemultimedia/kwave/metadata.yaml
index c56fe6e..4625e32 100644
--- a/projects/kdereview/kwave/metadata.yaml
+++ b/projects/kde/kdemultimedia/kwave/metadata.yaml
@@ -35,7 +35,7 @@ members:
 - displayname: Helio Castro
   username: helio
 name: Kwave
-projectpath: kdereview/kwave
+projectpath: kde/kdemultimedia/kwave
 repoactive: true
 repopath: kwave
 type: module

Re: KDE.org Modernization

[Ben Cooksley]

On Wed, Sep 28, 2016 at 3:00 AM, aayush arora  wrote:
> Hi all,

Hi Lays, Aayush,

>  Thanks, Lays Rodrigues.
>  I am Aayush Arora, I am doing front-end development from past three years.
> I have worked with Fossasia as a Google Summer of Code student this year. I
> will suggest making kde.org completely responsive that supports all
> platforms. Kde.org seems to be a representation of KDE data. Hence, I can
> suggest working with Angular.js to make it a Single Page Application which
> will be fast as compared to the current website ( without reloading of pages
> ) , also using Bootstrap ( Responsive Web design framework) can help to
> complete the work easily.
> I will love to be a part of this, developers who maintain kde.org can help
> and provide suggestions.

Can I suggest raising this on kde-...@kde.org?
I think there were a couple of people (Ingo? Jens? Oliver?) who had
made discussions around this already.

There may have been a session at Akademy/QtCon about this, although
i'm not sure if that ended up happening.

> Thanks

Cheers,
Ben

>
> Aayush Arora
> Google Summer Of Code 2016, Fossasia
> B.tech , Information Technology
> JSS ACADEMY OF TECHNICAL EDUCATION ,NOIDA
> Linkedin , Github
>
> On Tue, Sep 27, 2016 at 6:56 PM, Lays Rodrigues
>  wrote:
>>
>> Hello guys, everything ok?
>> Last night I tried to read the KDE dot story about the KDE Advisor Board
>> on my smartphone and was very hard since kde.org isn't friend mobile.
>> For me, the KDE pages look like too static, and a dynamism could be a good
>> way to present KDE and make easy the life of the people that access the site
>> to find the information that they need.
>> A few weeks ago an ex GSoC student from Fossassia, Aayush Arora, reached
>> me out on facebook and asked me how he could contribute to KDE, and his
>> skills are with web development.
>> I'm a newbie in web development, so I don't know how hard would be to make
>> this port to a modern website for KDE, or even if the community would be
>> opened to it.
>> So that is the why that I'm writing this email =D
>> What do you think? People that works on the kde.org could give their
>> opinions?
>> It's just an idea...
>> --
>> Lays Rodrigues
>> Software Developer at KDE
>> Computer Science Student at Federal Fluminense University
>> laysrodriguesdev.wordpress.com
>> Telegram: @lays147
>> IRC: lays147
>> Phone: +55 22 999899467
>
>

Re: kdereview

[Ben Cooksley]

On Wed, Sep 28, 2016 at 9:06 AM, Allen Winter  wrote:
> On Tuesday, September 27, 2016 09:20:32 PM Burkhard Lück wrote:
>> Am Mittwoch, 21. September 2016, 11:01:18 CEST schrieb Allen Winter:
>> > I suggest we remove bodega-client, kdev-perforce, kdots, kor and kpeg from
>> > kde_projects.xml and virtually move them into scratch.
>>
>> Any objections to move bodega-client, kdev-perforce, kdots, kor and kpeg to
>> unmaintained?
>>
> kdev-perforce should be moved into kdevplatform or kdevelop/plugins or 
> somesuch.
> I asked Ben to do that last week.  Not sure if that has been done yet.

I haven't moved it, as I was under the impression the repository was
defacto dead, as it's code had been merged into kdevplatform.
Not sure if the repository was going to be mothballed or deleted once
KDevPlatform 5.1 was released though.

>
> I have heard nothing about bodega-client, kdots, kor, kpeg since my initial 
> inquiry.
>

Cheers,
Ben

Re: kdereview

[Ben Cooksley]

On Sat, Oct 1, 2016 at 10:49 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El divendres, 30 de setembre de 2016, a les 21:17:56 CEST, Ben Cooksley va
> escriure:
>> On Fri, Sep 30, 2016 at 11:27 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > El dimecres, 21 de setembre de 2016, a les 11:01:18 CEST, Allen Winter va
>> >
>> > escriure:
>> >> kwave is now moved to kdemultimedia.
>> >
>> > Why did that happen?
>>
>> It was moved at the request of it's maintainer and Allen.
>>
>> > Did i miss the emails to k-c-d about reviewing it?
>>
>> I've just searched my mail - you didn't miss it. When the repository
>> was moved to KDE Review the Sysadmin ticket would have expressly
>> requested that the review process on kde-core-devel be started by the
>> maintainer now that we'd processed the move. It appears that didn't
>> happen.
>>
>> Thoughts on what should be done in regards to KWave here?
>
> Following the rules strictly I'd say to move it back to kdereview until we do
> the usual steps, i.e. email to k-c-d and the module list and get the review.
>
> Now, moving stuff around is a bit of a pain, so if Thomas can get those emails
> sent *NOW* I guess we can do the discussion with the kwave repo still in the
> kdemultimedia location and if nothing critical is found we save ourselves
> moving things back and forth.

I've not seen the email, so i've now pushed KWave back into review.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Cheers,
>> Ben
>>
>> >> No response from anyone else.
>> >>
>> >> I suggest we remove bodega-client, kdev-perforce, kdots, kor and kpeg
>> >> from
>> >> kde_projects.xml and virtually move them into scratch.
>> >>
>> >> On Sunday, September 18, 2016 12:08:41 PM Allen Winter wrote:
>> >> > Howdy,
>> >> >
>> >> > there's some stuff that's been in kdereview for a long time.
>> >> >
>> >> > according to kde_projects.xml, the kdereview programs are:
>> >> >   bodega-client (at least since Dec 2013)
>> >> >   kdev-perforce
>> >> >   kdots (at least since Nov 2015)
>> >> >   kor (at least since Oct 2014)
>> >> >   kpeg
>> >> >   kwave
>> >> >
>> >> > some of these (eg kwave) are actively developed.
>> >> >
>> >> > Can the owners of these please move them to a final location,
>> >> > clean them out, or let me know if they are really still under review?
>> >> >
>> >> > And by "move" I mean change their virtual location according to
>> >> > kde_projects or whatever "moving" means these days.
>> >> >
>> >> > -Allen
>
>

Re: Bugzilla Update: Antispam modification deployed

[Ben Cooksley]

On Thu, Oct 27, 2016 at 3:52 AM, Marco Martin <notm...@gmail.com> wrote:
> On Wed, Oct 26, 2016 at 9:42 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>> Hi all,
>>
>> As some of you will already be aware, Bugzilla has recently been
>> experiencing some issues with spam - courtesy of the same group that
>> were previously attacking our Wikis and Forums.
>>
>> I've now deployed antispam countermeasures on Bugzilla, which should
>> mitigate many forms of the spam which were previously affecting us.
>>
>> If you see any instances of legitimate comments being blocked, please
>> let us know.
>
> Hi Ben,

Hi Marco,

> thanks for taking care of this.
> However, had a couple of problems with the new bugzilla upgrade:
> tried to use the BUG: git hook to close a bug, but it neither closed
> the bug nor posted the comment.
> then tried to manually post a comment with a link to the commit.
> I guess the scary looking url
> (http://commits.kde.org/plasma-workspace/274752cda7e723ee21386bb642499a1244223409)
> triggered the antispam, as that comment gets blocked

Thanks for the report.

Those two issues were related - i've now adjusted the filter to be a
little less aggressive.

>
> --
> Marco Martin

Cheers,
Ben

Bugzilla upgraded

[Ben Cooksley]

Hi all,

The production instance of bugs.kde.org has now been upgraded with the
latest Bugzilla.
Thanks to everyone who tested the instance at bugstest.kde.org.

If there are any issues, please let one of us know.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Dropping kdelibs4-based applications in KDE Applications 17.12

[Ben Cooksley]

On Tue, Nov 15, 2016 at 11:27 AM, Albert Astals Cid  wrote:
> El divendres, 11 de novembre de 2016, a les 18:24:42 CET, Christoph Feck va
> escriure:
>> On 11.11.2016 16:45, Dominik Haumann wrote:
>> > On Thu, Nov 10, 2016 at 11:42 PM, Albert Astals Cid  wrote:
>> >> Hi, my proposal would be to make KDE Applications 17.08 the last release
>> >> we
>> >> accept applications based on kdelibs4, that means people have a year
>> >> until KDE Applications 17.12 to port the applications from the list
>> >> below to KF5.
>> >>
>> >> The ones that aren't ported we would just drop to unmaintained or if they
>> >> have an active developer team that somehow doesn't want to move to KF5
>> >> they could move to "extreagear".
>>
>> Will we still release the KDE4 platform for not-yet-ported extragear
>> applications (Amarok etc.) with 17.12?
>>
>> If we stop releasing it, then we should also move all unported
>> applications to 'unmaintained'. Any developer willing to port can
>> surrect it from there.
>
> I personally think that's a bit extreme tbh, if a group of developers are
> stubbornly fixated in developing for kdelibs4 and not KF5 I don't see why we
> should not let them do the releases if they want to.
>
> But this seems a bit hypothetical, I *hope* any actively maintained
> "extregear" app will be KF5-based in a year :)

>From my perspective, i'd like to drop CI support for Qt 4 based code
as soon as possible. Keeping it alive requires a whole additional set
of jobs and associated infrastructure, for something which receives
little development attention (comparatively).

Chances are we'll have to keep this support alive until Applications
17.08 is released, at which point I think we should drop it
completely, even if Extragear projects continue to use KDE 4 / Qt 4
based sources.

>
> Cheers,
>   Albert

Regards,
Ben

Re: Dropping kdelibs4-based applications in KDE Applications 17.12

[Ben Cooksley]

On Tue, Nov 15, 2016 at 11:27 AM, Albert Astals Cid  wrote:
> El divendres, 11 de novembre de 2016, a les 18:24:42 CET, Christoph Feck va
> escriure:
>> On 11.11.2016 16:45, Dominik Haumann wrote:
>> > On Thu, Nov 10, 2016 at 11:42 PM, Albert Astals Cid  wrote:
>> >> Hi, my proposal would be to make KDE Applications 17.08 the last release
>> >> we
>> >> accept applications based on kdelibs4, that means people have a year
>> >> until KDE Applications 17.12 to port the applications from the list
>> >> below to KF5.
>> >>
>> >> The ones that aren't ported we would just drop to unmaintained or if they
>> >> have an active developer team that somehow doesn't want to move to KF5
>> >> they could move to "extreagear".
>>
>> Will we still release the KDE4 platform for not-yet-ported extragear
>> applications (Amarok etc.) with 17.12?
>>
>> If we stop releasing it, then we should also move all unported
>> applications to 'unmaintained'. Any developer willing to port can
>> surrect it from there.
>
> I personally think that's a bit extreme tbh, if a group of developers are
> stubbornly fixated in developing for kdelibs4 and not KF5 I don't see why we
> should not let them do the releases if they want to.
>
> But this seems a bit hypothetical, I *hope* any actively maintained
> "extregear" app will be KF5-based in a year :)

>From my perspective, i'd like to drop CI support for Qt 4 based code
as soon as possible. Keeping it alive requires a whole additional set
of jobs and associated infrastructure, for something which receives
little development attention (comparatively).

Chances are we'll have to keep this support alive until Applications
17.08 is released, at which point I think we should drop it
completely, even if Extragear projects continue to use KDE 4 / Qt 4
based sources.

>
> Cheers,
>   Albert

Regards,
Ben

Discontinuing Qt mirror

[Ben Cooksley]

Hi all,

For sometime now, Sysadmin has maintained a mirror of Qt on
anongit.kde.org. It has been some time now however since Qt's
infrastructure was hosted on the partly unreliable Gitorious systems,
and therefore the need for the mirror has passed.

Therefore we'd like to discontinue the mirror - in part because
Phabricator does not support directories for repositories, and
requires everything be at top level. This is a distinction which is
totally incompatible with Qt's tooling if my understanding is correct.

If anyone has any objection please let us know.

Regards,
Ben Cooksley
KDE Sysadmin

Discontinuing repository tarballs

[Ben Cooksley]

HI all,

As of late Sysadmin has been assessing what components of our
infrastructure are in active use and should be maintained going
forward.

As part of this it has come to our attention that the repository
tarballs offered by our anongit network (tar.gz files of our
repositories essentially) are effectively unused - with only 19 hits
being received by one mirror in the space of a week.

These tarballs are generated by cronjob once per week, and are
effectively a duplicate copy of the repositories which must be held by
each anongit. Removing them will reduce the resources needed and
maintenance complexity involved to operate an anongit mirror, as well
as reducing load on the main git.kde.org server which generates the
tarballs.

If anyone has any objection please let us know.

Regards,
Ben Cooksley
KDE Sysadmin

Please cleanup your scratch and clone repositories

[Ben Cooksley]

Hi all,

To help Sysadmin assess how these types of repositories would be used
under Phabricator, it would be appreciated if everyone could please
cleanup the scratch and clone repositories they're no longer using and
have no need to keep.

You can get a list of repositories you have by visiting
https://cgit.kde.org/ or by running the below command and filtering
appropriately using your favourite tools.

ssh g...@git.kde.org info

Once you've determined the repositories to remove, they can be removed
by running the following two commands:

ssh g...@git.kde.org D unlock scratch/username/reponame
ssh g...@git.kde.org D rm scratch/username/reponame

Please note that the trailing .git should not be included, otherwise
the system will not accept your request. You can substitute
scratch/... for clones/... as appropriate here.

Thanks in advance for removing unused repos!

Regards,
Ben Cooksley
KDE Sysadmin

Re: Discontinuing repository tarballs

[Ben Cooksley]

On Thu, Nov 24, 2016 at 8:41 PM, Ben Cooksley <bcooks...@kde.org> wrote:
> On Thu, Nov 24, 2016 at 2:30 PM, Michael Pyne <mp...@purinchu.net> wrote:
>> On Wed, Nov 23, 2016 at 08:17:29PM +1300, Ben Cooksley wrote:
>>> HI all,
>>>
>>> As of late Sysadmin has been assessing what components of our
>>> infrastructure are in active use and should be maintained going
>>> forward.
>>>
>>> As part of this it has come to our attention that the repository
>>> tarballs offered by our anongit network (tar.gz files of our
>>> repositories essentially) are effectively unused - with only 19 hits
>>> being received by one mirror in the space of a week.
>>
>> Not an objection, but the low usage may be due to the use of tarball
>> repo snapshots being disabled in kdesrc-build for a few months now.
>>
>> Of course, kdesrc-build was using the snapshots by default out of an
>> effort to be gentler to KDE source code repositories, so if it's easier
>> for you all to forgo the snapshots entirely then I'm fully supportive.

Hi all,

>
> It's definitely easier on the servers disks I think :)
> The anongit servers haven't had any issues with load as far as I can
> remember, so I think it's safe in this case for kdesrc-build to use
> normal git:// or https:// clones.
>
> If nobody objects in the next 24 hours i'd like to go ahead with
> discontinuing the tarballs.

As previously announced i've now begun the process of discontinuing
the generation and distribution of the tarballs.
Many thanks to those who responded to this thread.

>
>>
>> Regards,
>>  - Michael Pyne
>
> Cheers,
> Ben

Regards,
Ben Cooksley

Please cleanup your scratch and clone repositories

[Ben Cooksley]

Hi all,

To help Sysadmin assess how these types of repositories would be used
under Phabricator, it would be appreciated if everyone could please
cleanup the scratch and clone repositories they're no longer using and
have no need to keep.

You can get a list of repositories you have by visiting
https://cgit.kde.org/ or by running the below command and filtering
appropriately using your favourite tools.

ssh g...@git.kde.org info

Once you've determined the repositories to remove, they can be removed
by running the following two commands:

ssh g...@git.kde.org D unlock scratch/username/reponame
ssh g...@git.kde.org D rm scratch/username/reponame

Please note that the trailing .git should not be included, otherwise
the system will not accept your request. You can substitute
scratch/... for clones/... as appropriate here.

Thanks in advance for removing unused repos!

Regards,
Ben Cooksley
KDE Sysadmin

Please cleanup your scratch and clone repositories

[Ben Cooksley]

Hi all,

To help Sysadmin assess how these types of repositories would be used
under Phabricator, it would be appreciated if everyone could please
cleanup the scratch and clone repositories they're no longer using and
have no need to keep.

You can get a list of repositories you have by visiting
https://cgit.kde.org/ or by running the below command and filtering
appropriately using your favourite tools.

ssh g...@git.kde.org info

Once you've determined the repositories to remove, they can be removed
by running the following two commands:

ssh g...@git.kde.org D unlock scratch/username/reponame
ssh g...@git.kde.org D rm scratch/username/reponame

Please note that the trailing .git should not be included, otherwise
the system will not accept your request. You can substitute
scratch/... for clones/... as appropriate here.

Thanks in advance for removing unused repos!

Regards,
Ben Cooksley
KDE Sysadmin

Re: api.kde.org not generated

[Ben Cooksley]

On Sat, Nov 26, 2016 at 10:51 AM, Olivier Churlaud  wrote:
> Hi,

Hi Oliver,

>
> I just realized that api.kde.org was not generated since the 18th (one week).
> I just wanted to say that it is known and currently under investigation. I'll
> fix this as soon as I can (before Monday anyway)

This was due to a system migration by the hoster of Zivo, as part of
this migration the system was temporarily split between two different
physical hosts for the duration of the migration. To minimize the risk
of changes being lost, cron was disabled during this migration, which
is why the API documentation was not regenerated.

As of an hour or so ago we were confident the migration had been fully
completed and that the new host system for Zivo was stable and
completely operational, so have now switched to using the new host
exclusively. Cron has been re-enabled as a result.

>
> @Ben:  I would be happy to discuss if an email alert could be set from the
> server to be aware of problems without checking everyday the logs. I'm quite
> busy with IRL issues and cannot spend too much time otherwise.

Something along these lines can probably be arranged - please contact
me off list to arrange this.

>
> Cheers,
> Olivier

Cheers,
Ben

Re: Discontinuing repository tarballs

[Ben Cooksley]

On Thu, Nov 24, 2016 at 2:30 PM, Michael Pyne <mp...@purinchu.net> wrote:
> On Wed, Nov 23, 2016 at 08:17:29PM +1300, Ben Cooksley wrote:
>> HI all,
>>
>> As of late Sysadmin has been assessing what components of our
>> infrastructure are in active use and should be maintained going
>> forward.
>>
>> As part of this it has come to our attention that the repository
>> tarballs offered by our anongit network (tar.gz files of our
>> repositories essentially) are effectively unused - with only 19 hits
>> being received by one mirror in the space of a week.
>
> Not an objection, but the low usage may be due to the use of tarball
> repo snapshots being disabled in kdesrc-build for a few months now.
>
> Of course, kdesrc-build was using the snapshots by default out of an
> effort to be gentler to KDE source code repositories, so if it's easier
> for you all to forgo the snapshots entirely then I'm fully supportive.

It's definitely easier on the servers disks I think :)
The anongit servers haven't had any issues with load as far as I can
remember, so I think it's safe in this case for kdesrc-build to use
normal git:// or https:// clones.

If nobody objects in the next 24 hours i'd like to go ahead with
discontinuing the tarballs.

>
> Regards,
>  - Michael Pyne

Cheers,
Ben

Bugzilla Update: Antispam modification deployed

[Ben Cooksley]

Hi all,

As some of you will already be aware, Bugzilla has recently been
experiencing some issues with spam - courtesy of the same group that
were previously attacking our Wikis and Forums.

I've now deployed antispam countermeasures on Bugzilla, which should
mitigate many forms of the spam which were previously affecting us.

If you see any instances of legitimate comments being blocked, please
let us know.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Please cleanup your scratch and clone repositories

[Ben Cooksley]

On Sat, Nov 26, 2016 at 7:53 AM, Ben Cooksley <bcooks...@kde.org> wrote:
> Hi all,

Hi all,

>
> To help Sysadmin assess how these types of repositories would be used
> under Phabricator, it would be appreciated if everyone could please
> cleanup the scratch and clone repositories they're no longer using and
> have no need to keep.
>
> You can get a list of repositories you have by visiting
> https://cgit.kde.org/ or by running the below command and filtering
> appropriately using your favourite tools.
>
> ssh g...@git.kde.org info
>
> Once you've determined the repositories to remove, they can be removed
> by running the following two commands:
>
> ssh g...@git.kde.org D unlock scratch/username/reponame
> ssh g...@git.kde.org D rm scratch/username/reponame
>
> Please note that the trailing .git should not be included, otherwise
> the system will not accept your request. You can substitute
> scratch/... for clones/... as appropriate here.
>
> Thanks in advance for removing unused repos!

We've had good progress so far in cleaning up unused repositories -
i'd estimate good 50 or so repositories have been cleaned up.
For those who haven't yet checked their personal clones and scratch
repositories it would be appreciated if you could do so.

>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Thanks,
Ben Cooksley

Re: Please cleanup your scratch and clone repositories

[Ben Cooksley]

On Sat, Nov 26, 2016 at 7:53 AM, Ben Cooksley <bcooks...@kde.org> wrote:
> Hi all,

Hi all,

>
> To help Sysadmin assess how these types of repositories would be used
> under Phabricator, it would be appreciated if everyone could please
> cleanup the scratch and clone repositories they're no longer using and
> have no need to keep.
>
> You can get a list of repositories you have by visiting
> https://cgit.kde.org/ or by running the below command and filtering
> appropriately using your favourite tools.
>
> ssh g...@git.kde.org info
>
> Once you've determined the repositories to remove, they can be removed
> by running the following two commands:
>
> ssh g...@git.kde.org D unlock scratch/username/reponame
> ssh g...@git.kde.org D rm scratch/username/reponame
>
> Please note that the trailing .git should not be included, otherwise
> the system will not accept your request. You can substitute
> scratch/... for clones/... as appropriate here.
>
> Thanks in advance for removing unused repos!

We've had good progress so far in cleaning up unused repositories -
i'd estimate good 50 or so repositories have been cleaned up.
For those who haven't yet checked their personal clones and scratch
repositories it would be appreciated if you could do so.

>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Thanks,
Ben Cooksley

Re: Please cleanup your scratch and clone repositories

[Ben Cooksley]

On Sat, Nov 26, 2016 at 7:53 AM, Ben Cooksley <bcooks...@kde.org> wrote:
> Hi all,

Hi all,

>
> To help Sysadmin assess how these types of repositories would be used
> under Phabricator, it would be appreciated if everyone could please
> cleanup the scratch and clone repositories they're no longer using and
> have no need to keep.
>
> You can get a list of repositories you have by visiting
> https://cgit.kde.org/ or by running the below command and filtering
> appropriately using your favourite tools.
>
> ssh g...@git.kde.org info
>
> Once you've determined the repositories to remove, they can be removed
> by running the following two commands:
>
> ssh g...@git.kde.org D unlock scratch/username/reponame
> ssh g...@git.kde.org D rm scratch/username/reponame
>
> Please note that the trailing .git should not be included, otherwise
> the system will not accept your request. You can substitute
> scratch/... for clones/... as appropriate here.
>
> Thanks in advance for removing unused repos!

We've had good progress so far in cleaning up unused repositories -
i'd estimate good 50 or so repositories have been cleaned up.
For those who haven't yet checked their personal clones and scratch
repositories it would be appreciated if you could do so.

>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Thanks,
Ben Cooksley

Re: Jenkins-kde-ci: frameworkintegration master stable-kf5-qt5 » Linux,gcc - Build # 334 - Still Failing!

[Ben Cooksley]

On Fri, Dec 16, 2016 at 3:46 AM, Aleix Pol <aleix...@kde.org> wrote:
> On Thu, Dec 15, 2016 at 7:19 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>>
>> On Thu, Dec 15, 2016 at 7:16 PM,  <no-re...@kde.org> wrote:
>> >
>> > GENERAL INFO
>> >
>> > BUILD FAILURE
>> > Build URL: 
>> > https://build.kde.org/job/frameworkintegration%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/334/
>> > Project: PLATFORM=Linux,compiler=gcc
>> > Date of build: Thu, 15 Dec 2016 06:14:40 +
>> > Build duration: 23 sec
>>
>> It would appear that Commit d5652726b30c14033cddd757242db703576b1e95
>> introduced a dependency on KNewStuff, but this dependency has not been
>> declared in the build metadata...
>>
>> >
>> > CHANGE SET
>> > No changes
>>
>> Cheers,
>> Ben
>
>
> Should be fixed:
> https://commits.kde.org/kde-build-metadata/a322bb20d90c05e610443d774bc9634e6f2ab7ef

Many thanks.

>
> Aleix

Cheers,
Ben

Re: Jenkins-kde-ci: frameworkintegration master stable-kf5-qt5 » Linux,gcc - Build # 334 - Still Failing!

[Ben Cooksley]

On Thu, Dec 15, 2016 at 7:16 PM,   wrote:
>
> GENERAL INFO
>
> BUILD FAILURE
> Build URL: 
> https://build.kde.org/job/frameworkintegration%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/334/
> Project: PLATFORM=Linux,compiler=gcc
> Date of build: Thu, 15 Dec 2016 06:14:40 +
> Build duration: 23 sec

It would appear that Commit d5652726b30c14033cddd757242db703576b1e95
introduced a dependency on KNewStuff, but this dependency has not been
declared in the build metadata...

>
> CHANGE SET
> No changes

Cheers,
Ben

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 12, 2017 at 3:23 AM, Scarlett Clark
 wrote:
>
>
> On Wed, Jan 11, 2017 at 4:40 AM, Jan Kundrát  wrote:
>>
>> On středa 11. ledna 2017 6:57:50 CET, Martin Gräßlin wrote:
>>>
>>> That doesn't work. Such inflexibility take away the advantage of having a
>>> CI.
>>
>>
>> What base system(s) do you prefer to target as a developer, Martin?
>>
>> A CI system can have different sets of base images for different projects
>> (and different branches, etc). Something along these lines:
>>
>> - KF5 might care a bit about slow-moving distributions such as RHEL7
>> (well, except for a requirement on Qt 5.6)
>>
>> - Plasma LTS might want to target versions of faster-moving distros which
>> were around at a time of their release. Say, Fedora 24? Ubuntu 16.04 LTS?
>>
>> - The master branches of Plasma might want to get rid of the legacy
>> workarounds. Can we use the latest Fedora with aggressive backports of
>> rawhide packages upon request for this?
>>
>> - Various applications within KDE might have completely different
>> requiremens. Some "leaf" applications might want to target slow-moving
>> distributions with their ancient Qt.
>>
>> So this incomplete set of requirements probably translates to four base
>> images. I'm using a RPM-centric terminology and picking these distros
>> because of my professional background with these systems:
>>
>> 1) CentOS 7 with Qt 5.6 from EPEL and installed devtoolset
>> 2) Ubuntu 16.04 LTS with a distro Qt (that is 5.5)
>> 3) latest Fedora with Qt from git and an unspecified number of packages
>> from rawhide
>> 4) Debian Jessie with a system Qt 5.3
>>
>> Each project in KDE can then choose whether they care about these
>> individual base images (subject to the availability of dependencies, of
>> course -- if KF5 don't care about Jessie and Qt 5.3, no project which uses
>> any KF5 can possibly opt in to support that configuration for obvious
>> reasons). By default, all projects get just 3) for the "latest and greatest"
>> and for minimal wasted manpower.
>>
>> With my (non-KDE) sysadmin hat on, I believe that the infrastructure
>> should be provided as a service offering for developers. It is the
>> developer's job to produce working code which is packageable. I don't think
>> it's a developer's job to make a CI's sysadmin life uneventful, though.
>> Perhaps the architecture outlined above can help achieve these goals with
>> minimal manpower?
>
>
> This seems like a good idea to me. I have always thought we should have more
> than one distro image. I will even take the responsibility of maintaining
> them.

Until our recent move towards Products / Tracks this hasn't even been
something we could even think about due to the nature of how
dependencies were resolved.
In theory, with a bit of manoeuvring it can theoretically be done. The
hard part will be any dependencies which traverse the Product boundary
more than once.

> Scarlett
>

Cheers,
Ben

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

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 12, 2017 at 4:54 AM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-01-11 10:46, schrieb Ben Cooksley:
>>
>> On Wed, Jan 11, 2017 at 6:57 PM, Martin Gräßlin <mgraess...@kde.org>
>> wrote:
>>>
>>>
>>>
>>> Am 10. Januar 2017 22:42:35 MEZ schrieb Ben Cooksley <bcooks...@kde.org>:
>>>>
>>>> On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraess...@kde.org>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf
>>>>
>>>> <neund...@kde.org>:
>>>>>>
>>>>>> On 2017 M01 6, Fri 22:39:22 CET Ben Cooksley wrote:
>>>>>>>
>>>>>>> See my notes above re. why tying this to the dependency freeze date
>>>>>>
>>>>>> is
>>>>>>>
>>>>>>> a bad idea and won't really work.
>>>>>>>
>>>>>>> Given that we potentially have to take into account Qt version
>>>>
>>>> bumps
>>>>>>>
>>>>>>> and base system rebuilds - i'll give a timeline of 1 month's
>>>>
>>>> advance
>>>>>>>
>>>>>>> notice (this is an absolute worst case scenario time). In most
>>>>>>> instances we can turn things around in much shorter time (about a
>>>>>>> week), especially where it's just a case of installing an already
>>>>>>> available package / adding a PPA/Equivalent Repository.
>>>>>>>
>>>>>>> The significant variation in time above is why I don't want to
>>>>>>> actually specify a time frame which is set in stone. Some things
>>>>
>>>> are
>>>>>>>
>>>>>>> just easier to provide / upgrade than others.
>>>>>>
>>>>>>
>>>>>> how about some simple rule like "new dependencies every first of the
>>>>>> month",
>>>>>> and 1 week notice. For the developer this would mean in the worst
>>>>
>>>> case
>>>>>>
>>>>>> 5 weeks
>>>>>> waiting, which is probably quite a lot.
>>>>>> E.g. if you need a new dependency, and announce it let's say January
>>>>>> 6th,
>>>>>> you'll get it February 1st.
>>>>>> If you announce it January 29th, you get it March 1st.
>>>>>
>>>>>
>>>>> In general I like the more formal approach to dependency handling.
>>>>>
>>>>> This concrete proposal is in my opinion to restrictive to developers
>>>>
>>>> - in case of plasma it could mean only one date per release schedule.
>>>>>
>>>>> That's difficult to plan and makes it easy for devs to miss. If for
>>>>
>>>> whatever reason you cannot push that one day you have to wait a
>>>> complete release cycle.
>>>>>
>>>>>
>>>>> And I don't see how this addresses the problem of CI needs time. As
>>>>
>>>> Ben told us one week might not be enough.
>>>>>
>>>>>
>>>>> It can address the problem for distro consumers, but for developers
>>>>
>>>> on older distros it wouldn't help either.
>>>>
>>>> Can we have a proposal from your side then Martin?
>>>>
>>>> As i've said previously, what i'm asking for here is fundamentally
>>>> incompatible with integration into a release schedule, as dependencies
>>>> can be bumped at essentially any time from the point of a version
>>>> being released (the unfreeze) to the point dependencies are frozen in
>>>> the lead up to a release. The advance notice i've asked for needs to
>>>> be given before said bump actually happens.
>>>>
>>>> Note that the amount of notice needed is very dependent on the nature
>>>> of the bump - some bumps could be sorted in 24 hours... while others
>>>> require extensive planning and need weeks.
>>>
>>>
>>> Honestly, that is an inflexibility I cannot work with. I don't see how I
>>> as a dev can
>>> plan to upgrade a dependency if all we get is something between a day and
>>> months.
>>> Please remember that our release sche

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Sat, Jan 14, 2017 at 11:42 PM, Kai-Uwe  wrote:
> Am 14.01.2017 um 08:29 schrieb Martin Gräßlin:
>> Am 14. Januar 2017 00:58:55 MEZ schrieb Kevin Kofler 
>> :
>>> The common case is that the new library version is used for an API
>>> addition,
>>> and that reverting the dependency bump in the application will
>>> necessarily
>>> also revert the application code using the new library API (because
>>> otherwise it won't build) and restore the known state from the previous
>>> release of the application. (This can reintroduce bugs, but only ones
>>> which
>>> were already in the previous release.) As I understand it, this is
>>> exactly
>>> the situation we are in with KWin and xkbcommon now
>>
>> And you understand KWin? You know why it was added and how many follow up 
>> changes depend on it?
>>
>> Then you know more than I do! Over the last week's the input code got 
>> refactored and is still being refactored. Good luck getting this reverted 
>> without breaking other things.
>>
>> That's the point where I do heavily disagree with your thinking. You have no 
>> idea about the software in question. And you cannot have it. So trust the 
>> people knowing it!
>
> Modifications of distributors can be seen for various projects in the
> past and today. You both appear to have reached a point beyond
> consensus. I think this is respectable. The actual thread shows how much
> at least one party is strongly distracted from feeling well with the
> situation. At least I read it from your emails.
>
> The perhaps simplest thing for the upstream maintainer, would be to
> request the distributor to call his version of the software a __fork__.
> That should typically cover slightly renaming, to make the fork
> distinguishable for end users, take over responsibility for bug reports
> and do separate maintenance. That constellation might help, to not be
> bound and in conflict around the issue until it is resolved. (A later
> reunification can be requested any time one party wishes. A parallel
> reasonably minor modified version of the original can still be shipped
> with a suitable distribution version and cooperation can easier happen
> with that.)
>
> Just an idea to concentrate on more productive things for the joy of coding.

Please split that off into a separate thread, it's totally separate to
this matter and is dragging it very quickly in totally-off-topic
territory.

>
> Kai-Uwe

Thanks

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Sat, Jan 14, 2017 at 5:23 AM, Martin Gräßlin  wrote:
> Am 2017-01-13 13:21, schrieb Eike Hein:
>>
>> Ok, here we go. My draft of a formal policy for dep changes and the CI:
>>
>> https://community.kde.org/Policies/Dependency_Changes_and_CI
>>
>> Compared to my earlier email, this draft contains some hard deadlines
>> and an attempt to specify failure modes if the deadlines are not met.
>>
>> Please chime in with suggestions for how the text needs to be refined
>> and expanded to meet your and our needs. Updated versions of specific
>> paragraphs are the preferred format for doing so: The thread so far
>> has shown that free-form conversation is prone to mudslinging, so
>> let's try to keep to the lingo fo a formal, dry document.
>
>
> Thanks for stepping up to write this!
>
> A few notes from my side:
>
> * "Subscribing the sysadmin team to these code reviews is mandatory." - How?
> What are the team names one has to add as reviewers?
>
> * This drastically changes the way KDE works. It requires mandatory code
> review and gives kind of veto power to sysadmins. It's something the larger
> KDE community might need to discuss as it removes one of the core principles
> of KDE that anybody can commit to anything and code review is only optional.

That's what this thread is -> no further comment required.

>
> * Related to this: a month blocking on formal process is too long. If a
> maintainer doesn't respond in two weeks but another team member accepted the
> patch, it should also go in.
>
> * I would like to see a link to where developers can check whether a
> dependency is available. Reasoning: I want to check whether it's a
> no-brainer to not have to add sysadmins if it's already available. E.g. if I
> add a new dep in KWin, which is already used by Krita I wouldn't know that
> and ask sysadmins. That would be a waste of sysadmin's time.

For Linux at least, a search on the front page of build.kde.org for
the phrase "create_" will show you the jobs which manufacture the
Docker Images in which the builds are conducted.
Maintaining a listing elsewhere is prone to being out of date.

>
> * I would like to add another exception: last minute dependency requests
> prior to a feature freeze should be allowed under certain conditions even if
> sysadmins had not two weeks to respond. Reasoning: shit happens ;-)

Sorry, but a carve out like that is bound to leave us in the situation
we're currently in, where the CI maintainers have to sort things out
after the damage has been done.
That's exactly what this policy is supposed to prevent.

I'm in total opposition to this exception request.

>
> Cheers
> Martin

Regards,
Ben

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraess...@kde.org> wrote:
>
>
> Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf <neund...@kde.org>:
>>On 2017 M01 6, Fri 22:39:22 CET Ben Cooksley wrote:
>>> See my notes above re. why tying this to the dependency freeze date
>>is
>>> a bad idea and won't really work.
>>>
>>> Given that we potentially have to take into account Qt version bumps
>>> and base system rebuilds - i'll give a timeline of 1 month's advance
>>> notice (this is an absolute worst case scenario time). In most
>>> instances we can turn things around in much shorter time (about a
>>> week), especially where it's just a case of installing an already
>>> available package / adding a PPA/Equivalent Repository.
>>>
>>> The significant variation in time above is why I don't want to
>>> actually specify a time frame which is set in stone. Some things are
>>> just easier to provide / upgrade than others.
>>
>>how about some simple rule like "new dependencies every first of the
>>month",
>>and 1 week notice. For the developer this would mean in the worst case
>>5 weeks
>>waiting, which is probably quite a lot.
>>E.g. if you need a new dependency, and announce it let's say January
>>6th,
>>you'll get it February 1st.
>>If you announce it January 29th, you get it March 1st.
>
> In general I like the more formal approach to dependency handling.
>
> This concrete proposal is in my opinion to restrictive to developers - in 
> case of plasma it could mean only one date per release schedule.
> That's difficult to plan and makes it easy for devs to miss. If for whatever 
> reason you cannot push that one day you have to wait a complete release cycle.
>
> And I don't see how this addresses the problem of CI needs time. As Ben told 
> us one week might not be enough.
>
> It can address the problem for distro consumers, but for developers on older 
> distros it wouldn't help either.

Can we have a proposal from your side then Martin?

As i've said previously, what i'm asking for here is fundamentally
incompatible with integration into a release schedule, as dependencies
can be bumped at essentially any time from the point of a version
being released (the unfreeze) to the point dependencies are frozen in
the lead up to a release. The advance notice i've asked for needs to
be given before said bump actually happens.

Note that the amount of notice needed is very dependent on the nature
of the bump - some bumps could be sorted in 24 hours... while others
require extensive planning and need weeks.

>
> Cheers
> Martin

Regards,
Ben

>>
>>Of course such the numbers (weeks) are arbitrarily chosen and could be
>>different.
>>
>>I guess something like this would be convenient for "consumers" of the
>>sources.
>>
>>Alex

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 13, 2017 at 7:39 PM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-01-13 03:10, schrieb Michael Pyne:
>>
>> On Thu, Jan 12, 2017 at 05:02:40PM +0100, Martin Gräßlin wrote:
>>>
>>> Am 2017-01-12 08:32, schrieb Ben Cooksley:
>>> > It would probably be a good idea to announce it for other developers
>>> > to know about as well so they can sort their systems out.
>>>
>>> that's what we have code review for :-)
>>
>>
>> No, code review isn't for every developer to review every single patch
>> that comes across just to see if it introduces a dependency bump.  The
>> cyclomatic complexity of that kind of review graph would be quite
>> extreme ;).
>
>
> I'm sure every member of a team knows how to inform the team. For Plasma
> it would be code review. For other teams it might be a different way.

Please remember that your software is built by others outside the Plasma team.
Just letting the members of the Plasma team know isn't very considerate to them.

>
> Cheers
> Martin

Regards,
Ben

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Wed, Jan 11, 2017 at 6:57 PM, Martin Gräßlin <mgraess...@kde.org> wrote:
>
>
> Am 10. Januar 2017 22:42:35 MEZ schrieb Ben Cooksley <bcooks...@kde.org>:
>>On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraess...@kde.org>
>>wrote:
>>>
>>>
>>> Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf
>><neund...@kde.org>:
>>>>On 2017 M01 6, Fri 22:39:22 CET Ben Cooksley wrote:
>>>>> See my notes above re. why tying this to the dependency freeze date
>>>>is
>>>>> a bad idea and won't really work.
>>>>>
>>>>> Given that we potentially have to take into account Qt version
>>bumps
>>>>> and base system rebuilds - i'll give a timeline of 1 month's
>>advance
>>>>> notice (this is an absolute worst case scenario time). In most
>>>>> instances we can turn things around in much shorter time (about a
>>>>> week), especially where it's just a case of installing an already
>>>>> available package / adding a PPA/Equivalent Repository.
>>>>>
>>>>> The significant variation in time above is why I don't want to
>>>>> actually specify a time frame which is set in stone. Some things
>>are
>>>>> just easier to provide / upgrade than others.
>>>>
>>>>how about some simple rule like "new dependencies every first of the
>>>>month",
>>>>and 1 week notice. For the developer this would mean in the worst
>>case
>>>>5 weeks
>>>>waiting, which is probably quite a lot.
>>>>E.g. if you need a new dependency, and announce it let's say January
>>>>6th,
>>>>you'll get it February 1st.
>>>>If you announce it January 29th, you get it March 1st.
>>>
>>> In general I like the more formal approach to dependency handling.
>>>
>>> This concrete proposal is in my opinion to restrictive to developers
>>- in case of plasma it could mean only one date per release schedule.
>>> That's difficult to plan and makes it easy for devs to miss. If for
>>whatever reason you cannot push that one day you have to wait a
>>complete release cycle.
>>>
>>> And I don't see how this addresses the problem of CI needs time. As
>>Ben told us one week might not be enough.
>>>
>>> It can address the problem for distro consumers, but for developers
>>on older distros it wouldn't help either.
>>
>>Can we have a proposal from your side then Martin?
>>
>>As i've said previously, what i'm asking for here is fundamentally
>>incompatible with integration into a release schedule, as dependencies
>>can be bumped at essentially any time from the point of a version
>>being released (the unfreeze) to the point dependencies are frozen in
>>the lead up to a release. The advance notice i've asked for needs to
>>be given before said bump actually happens.
>>
>>Note that the amount of notice needed is very dependent on the nature
>>of the bump - some bumps could be sorted in 24 hours... while others
>>require extensive planning and need weeks.
>
> Honestly, that is an inflexibility I cannot work with. I don't see how I as a 
> dev can
> plan to upgrade a dependency if all we get is something between a day and 
> months.
> Please remember that our release schedule is only about 3 months. With the
> requirements presented here it means I have to announce in the last release 
> cycle that I want to upgrade a dependency.

I'm sorry but that is how it is - we're providing CI to the entire of
KDE, covering Frameworks, Applications and Extragear - in addition to
Plasma.
Jenkins currently has ~1300 jobs loaded into it - so KWin is a
miniscule blip in comparison, considering it makes up only 2 of those
jobs.

This makes any change in the base platform a complex one - requiring a
full rebuild of everything (takes more than a day last time we did it
- and that's not taking into account the current Jenga tower state of
the dependency tree for some parts of KDE). This is where the "weeks"
part I mentioned above comes in - as depending on what you are after
we may have to replace the system base. That isn't something we can
just do at a drop of a hat because you've decided to bump dependencies
on something, and it isn't something I can predict with any certainty
either.

How difficult a dependency bump or introduction is to accommodate very
much depends on the availability of supplementary repositories (PPAs),
the difficulty of building it ourselves (bear in mind this has a
corresponding maintenance cost as well) and the ABI impact

[sysadmin/repo-metadata] projects/frameworks/prison: Move Prison to Frameworks.

[Ben Cooksley]

Git commit 53be28ae533973c04e381b314e4030af4157427e by Ben Cooksley.
Committed on 03/12/2016 at 10:40.
Pushed by bcooksley into branch 'master'.

Move Prison to Frameworks.
Last minute moves just before a release aren't ideal...
CCMAIL: release-t...@kde.org
CCMAIL: kde-frameworks-devel@kde.org
Ref T4801

R  +0-0projects/frameworks/prison/i18n.json [from: 
projects/kdesupport/prison/i18n.json - 100% similarity]
R  +1-1projects/frameworks/prison/metadata.yaml [from: 
projects/kdesupport/prison/metadata.yaml - 090% similarity]

https://commits.kde.org/sysadmin/repo-metadata/53be28ae533973c04e381b314e4030af4157427e

diff --git a/projects/kdesupport/prison/i18n.json 
b/projects/frameworks/prison/i18n.json
similarity index 100%
rename from projects/kdesupport/prison/i18n.json
rename to projects/frameworks/prison/i18n.json
diff --git a/projects/kdesupport/prison/metadata.yaml 
b/projects/frameworks/prison/metadata.yaml
similarity index 90%
rename from projects/kdesupport/prison/metadata.yaml
rename to projects/frameworks/prison/metadata.yaml
index 82f53ae..a9676f1 100644
--- a/projects/kdesupport/prison/metadata.yaml
+++ b/projects/frameworks/prison/metadata.yaml
@@ -6,7 +6,7 @@ members:
 - displayname: Sune Vuorela
   username: sune
 name: Barcode library
-projectpath: kdesupport/prison
+projectpath: frameworks/prison
 repoactive: true
 repopath: prison
 type: module

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 6, 2017 at 9:52 PM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-01-06 05:57, schrieb Ben Cooksley:
>>
>> On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin <mgraess...@kde.org>
>> wrote:
>>>
>>> Am 2017-01-05 11:20, schrieb Ben Cooksley:
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
>>>> <pri...@martin-graesslin.com> wrote:
>>>>>
>>>>>
>>>>> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> It seems that my previous vocal complaints about system level /
>>>>>> serious impact dependency bumps on the CI system have gone completely
>>>>>> unnoticed by (some) members of our Community.
>>>>>>
>>>>>> This was demonstrated earlier this week when components of Plasma
>>>>>> bumped their version requirements for XKBCommon and Appstream-Qt -
>>>>>> without even a thought about notifying Sysadmin or checking which
>>>>>> version the CI had, until their builds broke.
>>>>>>
>>>>>> Neither of these is easy to fix at this stage, as the system base is
>>>>>> now too old to receive updates such as these. Base upgrades require a
>>>>>> full rebuild of everything on the CI system, and usually involve
>>>>>> significant additional churn and is a process that must be done
>>>>>> roughly twice a year, depending on dependency bump demands.
>>>>>>
>>>>>> Does anyone have any suggestions as to how we may avoid this in the
>>>>>> future?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I have a few questions here:
>>>>>
>>>>> 1) Where is this requirement to check with sysadmins codified? So far I
>>>>> was
>>>>> only aware of dependency freeze.
>>>>
>>>>
>>>>
>>>> It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
>>>> Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
>>>> whole of PIM broke when they started using QtWebEngine. That was
>>>> around March/April 2016, my mail archives can't seem to find the exact
>>>> thread though.
>>>
>>>
>>>
>>> I'm sorry Ben, but I fear "sending out a mail about an issue with PIM"
>>> doesn't
>>> qualify as codifying it. Given what we have it looks like this did not
>>> reach
>>> the
>>> target audience. And neither will this thread.
>>
>>
>> Uhm, it was far more than a single email. It was quite the thread, and
>> if memory serves was on at least one of the mailing lists this thread
>> was on.
>> One of the key things that came out of that thread was to ask for
>> things to be bumped well in advance if a newer version is needed.
>>
>> I'm disappointed that you think that email threads have insufficient
>> reach given it's one of our communities principal means of
>> communication.
>
>
> Email threads don't work to codify such requirements. What we need is
> something like an "announce new dependency to sysadmin freeze" prior to
> the dependency freeze in the release schedule. That's what I mean with
> codifying it. We need to have it in a way where devs actually check.
> It needs to be part of the process. An old email thread cannot be part of
> the process.

Announcing new dependencies to Sysadmin as part of a release schedule
doesn't really work... because dependencies can be bumped at any time
(as long as a dependency freeze is not in effect for a project). Also,
CI builds for far more than just Plasma, including for software that
doesn't have a formal release schedule, including software in
Extragear. CI also doesn't really care for release schedules at all,
it just builds the latest state of the repository.

If you want to specify a time it has to be X before the commits
introducing the dependency land.

>
>>
>>>
>>> This needs to change the process, the way KDE develops software. It needs
>>> to
>>> be
>>> listed in the release schedule (is not, I checked), maybe reviews need to
>>> be
>>> acked by release managers, etc.
>>
>>
>> It seems to be part of the process for many others already, so not
>> sure what needs to change. The gpgme transition went 

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 6, 2017 at 9:52 PM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-01-06 05:57, schrieb Ben Cooksley:
>>
>> On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin <mgraess...@kde.org>
>> wrote:
>>>
>>> Am 2017-01-05 11:20, schrieb Ben Cooksley:
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
>>>> <pri...@martin-graesslin.com> wrote:
>>>>>
>>>>>
>>>>> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> It seems that my previous vocal complaints about system level /
>>>>>> serious impact dependency bumps on the CI system have gone completely
>>>>>> unnoticed by (some) members of our Community.
>>>>>>
>>>>>> This was demonstrated earlier this week when components of Plasma
>>>>>> bumped their version requirements for XKBCommon and Appstream-Qt -
>>>>>> without even a thought about notifying Sysadmin or checking which
>>>>>> version the CI had, until their builds broke.
>>>>>>
>>>>>> Neither of these is easy to fix at this stage, as the system base is
>>>>>> now too old to receive updates such as these. Base upgrades require a
>>>>>> full rebuild of everything on the CI system, and usually involve
>>>>>> significant additional churn and is a process that must be done
>>>>>> roughly twice a year, depending on dependency bump demands.
>>>>>>
>>>>>> Does anyone have any suggestions as to how we may avoid this in the
>>>>>> future?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I have a few questions here:
>>>>>
>>>>> 1) Where is this requirement to check with sysadmins codified? So far I
>>>>> was
>>>>> only aware of dependency freeze.
>>>>
>>>>
>>>>
>>>> It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
>>>> Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
>>>> whole of PIM broke when they started using QtWebEngine. That was
>>>> around March/April 2016, my mail archives can't seem to find the exact
>>>> thread though.
>>>
>>>
>>>
>>> I'm sorry Ben, but I fear "sending out a mail about an issue with PIM"
>>> doesn't
>>> qualify as codifying it. Given what we have it looks like this did not
>>> reach
>>> the
>>> target audience. And neither will this thread.
>>
>>
>> Uhm, it was far more than a single email. It was quite the thread, and
>> if memory serves was on at least one of the mailing lists this thread
>> was on.
>> One of the key things that came out of that thread was to ask for
>> things to be bumped well in advance if a newer version is needed.
>>
>> I'm disappointed that you think that email threads have insufficient
>> reach given it's one of our communities principal means of
>> communication.
>
>
> Email threads don't work to codify such requirements. What we need is
> something like an "announce new dependency to sysadmin freeze" prior to
> the dependency freeze in the release schedule. That's what I mean with
> codifying it. We need to have it in a way where devs actually check.
> It needs to be part of the process. An old email thread cannot be part of
> the process.

Announcing new dependencies to Sysadmin as part of a release schedule
doesn't really work... because dependencies can be bumped at any time
(as long as a dependency freeze is not in effect for a project). Also,
CI builds for far more than just Plasma, including for software that
doesn't have a formal release schedule, including software in
Extragear. CI also doesn't really care for release schedules at all,
it just builds the latest state of the repository.

If you want to specify a time it has to be X before the commits
introducing the dependency land.

>
>>
>>>
>>> This needs to change the process, the way KDE develops software. It needs
>>> to
>>> be
>>> listed in the release schedule (is not, I checked), maybe reviews need to
>>> be
>>> acked by release managers, etc.
>>
>>
>> It seems to be part of the process for many others already, so not
>> sure what needs to change. The gpgme transition went 

Replacement of notes.kde.org

[Ben Cooksley]

Hi all,

Sysadmin is currently in the process of testing and evaluating
Collabora Online (CODE) as a replacement for notes.kde.org. We've
enabled this on share.kde.org.

It would be appreciated if people please test it out - anyone who is a
Developer, member of the e.V, or Visual Design Group should be able to
login on share.kde.org. Please send your feedback to this thread.

We've already figured out a process for exporting all data from
notes.kde.org, and will look to do this once initial testing is
finished - ideally this would happen a day or two after New Years.

Thanks,
Ben

Replacement of notes.kde.org

[Ben Cooksley]

Hi all,

Sysadmin is currently in the process of testing and evaluating
Collabora Online (CODE) as a replacement for notes.kde.org. We've
enabled this on share.kde.org.

It would be appreciated if people please test it out - anyone who is a
Developer, member of the e.V, or Visual Design Group should be able to
login on share.kde.org. Please send your feedback to this thread.

We've already figured out a process for exporting all data from
notes.kde.org, and will look to do this once initial testing is
finished - ideally this would happen a day or two after New Years.

Thanks,
Ben

CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

Hi all,

It seems that my previous vocal complaints about system level /
serious impact dependency bumps on the CI system have gone completely
unnoticed by (some) members of our Community.

This was demonstrated earlier this week when components of Plasma
bumped their version requirements for XKBCommon and Appstream-Qt -
without even a thought about notifying Sysadmin or checking which
version the CI had, until their builds broke.

Neither of these is easy to fix at this stage, as the system base is
now too old to receive updates such as these. Base upgrades require a
full rebuild of everything on the CI system, and usually involve
significant additional churn and is a process that must be done
roughly twice a year, depending on dependency bump demands.

Does anyone have any suggestions as to how we may avoid this in the future?

At this point i'm in favour of if you don't follow the rules your
dependency bump just gets reverted out of existence, then you get to
go through the process properly...

Regards,
Ben

CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

Hi all,

It seems that my previous vocal complaints about system level /
serious impact dependency bumps on the CI system have gone completely
unnoticed by (some) members of our Community.

This was demonstrated earlier this week when components of Plasma
bumped their version requirements for XKBCommon and Appstream-Qt -
without even a thought about notifying Sysadmin or checking which
version the CI had, until their builds broke.

Neither of these is easy to fix at this stage, as the system base is
now too old to receive updates such as these. Base upgrades require a
full rebuild of everything on the CI system, and usually involve
significant additional churn and is a process that must be done
roughly twice a year, depending on dependency bump demands.

Does anyone have any suggestions as to how we may avoid this in the future?

At this point i'm in favour of if you don't follow the rules your
dependency bump just gets reverted out of existence, then you get to
go through the process properly...

Regards,
Ben

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
<pri...@martin-graesslin.com> wrote:
> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>
>> Hi all,
>>
>> It seems that my previous vocal complaints about system level /
>> serious impact dependency bumps on the CI system have gone completely
>> unnoticed by (some) members of our Community.
>>
>> This was demonstrated earlier this week when components of Plasma
>> bumped their version requirements for XKBCommon and Appstream-Qt -
>> without even a thought about notifying Sysadmin or checking which
>> version the CI had, until their builds broke.
>>
>> Neither of these is easy to fix at this stage, as the system base is
>> now too old to receive updates such as these. Base upgrades require a
>> full rebuild of everything on the CI system, and usually involve
>> significant additional churn and is a process that must be done
>> roughly twice a year, depending on dependency bump demands.
>>
>> Does anyone have any suggestions as to how we may avoid this in the
>> future?
>
>
> I have a few questions here:
>
> 1) Where is this requirement to check with sysadmins codified? So far I was
> only aware of dependency freeze.

It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
whole of PIM broke when they started using QtWebEngine. That was
around March/April 2016, my mail archives can't seem to find the exact
thread though.

> 2) How can we easily check what build.kde.org has? Looking at cmake output
> is not a sufficient way as it gives me wrong information

If CMake is outputting wrong information, then your CMakeLists.txt
can't make the appropriate decisions as to whether the available
version is suitable, so i'd say you've got bigger problems here that
need to be addressed first.

In any case, you can see the Docker log of the container being
generated at https://build.kde.org/job/create_ubuntu_slave-ange/

> 3) What should we do when build.kde.org does not have the requirement?

You have to file a Sysadmin ticket, also tagging the project
'build.kde.org' at the same time.

>
> It should be rather obvious that we don't introduce new dependencies because
> we like to. There is a very important software reason to it.
> That's the case for the xkbcommon dependency increase. Should I have let the
> code broken as it was, expecting half a year of bug reports till
> build.kde.org has the base upgraded to Ubuntu 16.04?

That's what #ifdef is for...

>
> If I have to degrade the quality of the product for serving the CI, I and
> all users have a problem. And this is currently the only alternative. The
> quality of our product is highly at risk as our changes are no longer
> compile tested. This is a huge problem for the release of Plasma 5.9. On the
> other hand I cannot revert the dependency change as that would break tests
> or introduce the broken code again. So actually we are caught between a hard
> and a rock place.
>
> When I increased the dependency I had the dependency freeze of Plasma 5.9 in
> mind. That's the one target I have to hit from release process currently.
> Also I had to consider a social aspect here. I asked xkbcommon devs to do
> the release. I would have feeled ashamed if we asked for the release and
> then don't use it. For me it was from a social point of view a very high
> requirement to ship with the dependency in the next release after xkbcommon
> release.
>
> If we have to wait an arbitrary time till build.kde.org has upgraded the
> base, maybe the choice of the base is not sufficient. E.g. I asked openSUSE
> about this dependency weeks ago. Actually a few days after xkbcommon had the
> release and it was already shipped in tumbleweed. Similar for Mesa 13 which
> I'm also eagerly waiting for build.kde.org to fetch it.

Mesa 13 is news to me.

Base upgrades are a major, major piece of effort. Ignoring changes to
packaging made by the distros, everything on the CI has to be fully
rebuilt due to broken binary compatibility (GLIBC usually changes)

Even if it were kept, as soon as you get new builds using new features
while old build artifacts are still using old ones, it'll start to
break (Cue wave to Qt's plugin loader & Akonadi with even patch level
version bumps to Qt). This problem is exacerbated by us often ending
up using PPA's and other third party repositories to provide certain
version bumped dependencies - which of course are packaged
differently, leading to not only potential naming differences but also
different sets of compiler flags (ABI compatibility says hi again).

In terms of the rebuild - that's everything from Qt, up through
Frameworks, then all of the libraries that aren't in Frameworks but
everyone us

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
<pri...@martin-graesslin.com> wrote:
> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>
>> Hi all,
>>
>> It seems that my previous vocal complaints about system level /
>> serious impact dependency bumps on the CI system have gone completely
>> unnoticed by (some) members of our Community.
>>
>> This was demonstrated earlier this week when components of Plasma
>> bumped their version requirements for XKBCommon and Appstream-Qt -
>> without even a thought about notifying Sysadmin or checking which
>> version the CI had, until their builds broke.
>>
>> Neither of these is easy to fix at this stage, as the system base is
>> now too old to receive updates such as these. Base upgrades require a
>> full rebuild of everything on the CI system, and usually involve
>> significant additional churn and is a process that must be done
>> roughly twice a year, depending on dependency bump demands.
>>
>> Does anyone have any suggestions as to how we may avoid this in the
>> future?
>
>
> I have a few questions here:
>
> 1) Where is this requirement to check with sysadmins codified? So far I was
> only aware of dependency freeze.

It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
whole of PIM broke when they started using QtWebEngine. That was
around March/April 2016, my mail archives can't seem to find the exact
thread though.

> 2) How can we easily check what build.kde.org has? Looking at cmake output
> is not a sufficient way as it gives me wrong information

If CMake is outputting wrong information, then your CMakeLists.txt
can't make the appropriate decisions as to whether the available
version is suitable, so i'd say you've got bigger problems here that
need to be addressed first.

In any case, you can see the Docker log of the container being
generated at https://build.kde.org/job/create_ubuntu_slave-ange/

> 3) What should we do when build.kde.org does not have the requirement?

You have to file a Sysadmin ticket, also tagging the project
'build.kde.org' at the same time.

>
> It should be rather obvious that we don't introduce new dependencies because
> we like to. There is a very important software reason to it.
> That's the case for the xkbcommon dependency increase. Should I have let the
> code broken as it was, expecting half a year of bug reports till
> build.kde.org has the base upgraded to Ubuntu 16.04?

That's what #ifdef is for...

>
> If I have to degrade the quality of the product for serving the CI, I and
> all users have a problem. And this is currently the only alternative. The
> quality of our product is highly at risk as our changes are no longer
> compile tested. This is a huge problem for the release of Plasma 5.9. On the
> other hand I cannot revert the dependency change as that would break tests
> or introduce the broken code again. So actually we are caught between a hard
> and a rock place.
>
> When I increased the dependency I had the dependency freeze of Plasma 5.9 in
> mind. That's the one target I have to hit from release process currently.
> Also I had to consider a social aspect here. I asked xkbcommon devs to do
> the release. I would have feeled ashamed if we asked for the release and
> then don't use it. For me it was from a social point of view a very high
> requirement to ship with the dependency in the next release after xkbcommon
> release.
>
> If we have to wait an arbitrary time till build.kde.org has upgraded the
> base, maybe the choice of the base is not sufficient. E.g. I asked openSUSE
> about this dependency weeks ago. Actually a few days after xkbcommon had the
> release and it was already shipped in tumbleweed. Similar for Mesa 13 which
> I'm also eagerly waiting for build.kde.org to fetch it.

Mesa 13 is news to me.

Base upgrades are a major, major piece of effort. Ignoring changes to
packaging made by the distros, everything on the CI has to be fully
rebuilt due to broken binary compatibility (GLIBC usually changes)

Even if it were kept, as soon as you get new builds using new features
while old build artifacts are still using old ones, it'll start to
break (Cue wave to Qt's plugin loader & Akonadi with even patch level
version bumps to Qt). This problem is exacerbated by us often ending
up using PPA's and other third party repositories to provide certain
version bumped dependencies - which of course are packaged
differently, leading to not only potential naming differences but also
different sets of compiler flags (ABI compatibility says hi again).

In terms of the rebuild - that's everything from Qt, up through
Frameworks, then all of the libraries that aren't in Frameworks but
everyone us

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-01-05 11:20, schrieb Ben Cooksley:
>>
>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
>> <pri...@martin-graesslin.com> wrote:
>>>
>>> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> It seems that my previous vocal complaints about system level /
>>>> serious impact dependency bumps on the CI system have gone completely
>>>> unnoticed by (some) members of our Community.
>>>>
>>>> This was demonstrated earlier this week when components of Plasma
>>>> bumped their version requirements for XKBCommon and Appstream-Qt -
>>>> without even a thought about notifying Sysadmin or checking which
>>>> version the CI had, until their builds broke.
>>>>
>>>> Neither of these is easy to fix at this stage, as the system base is
>>>> now too old to receive updates such as these. Base upgrades require a
>>>> full rebuild of everything on the CI system, and usually involve
>>>> significant additional churn and is a process that must be done
>>>> roughly twice a year, depending on dependency bump demands.
>>>>
>>>> Does anyone have any suggestions as to how we may avoid this in the
>>>> future?
>>>
>>>
>>>
>>> I have a few questions here:
>>>
>>> 1) Where is this requirement to check with sysadmins codified? So far I
>>> was
>>> only aware of dependency freeze.
>>
>>
>> It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
>> Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
>> whole of PIM broke when they started using QtWebEngine. That was
>> around March/April 2016, my mail archives can't seem to find the exact
>> thread though.
>
>
> I'm sorry Ben, but I fear "sending out a mail about an issue with PIM"
> doesn't
> qualify as codifying it. Given what we have it looks like this did not reach
> the
> target audience. And neither will this thread.

Uhm, it was far more than a single email. It was quite the thread, and
if memory serves was on at least one of the mailing lists this thread
was on.
One of the key things that came out of that thread was to ask for
things to be bumped well in advance if a newer version is needed.

I'm disappointed that you think that email threads have insufficient
reach given it's one of our communities principal means of
communication.

>
> This needs to change the process, the way KDE develops software. It needs to
> be
> listed in the release schedule (is not, I checked), maybe reviews need to be
> acked by release managers, etc.

It seems to be part of the process for many others already, so not
sure what needs to change. The gpgme transition went quite well for
PIM, and other applications developers have reached out and asked
about version upgrades to various libraries which were in their area
of interest which we have sorted out easily enough.

>
>>
>>> 2) How can we easily check what build.kde.org has? Looking at cmake
>>> output
>>> is not a sufficient way as it gives me wrong information
>>
>>
>> If CMake is outputting wrong information, then your CMakeLists.txt
>> can't make the appropriate decisions as to whether the available
>> version is suitable, so i'd say you've got bigger problems here that
>> need to be addressed first.
>
>
> Cmake feature summary says: "required version >= 0.5" and that's for all
> found
> depeendencies. Unfortunately no information at all in the feature summary
> about
> the actual version.

Quoting the KWin CMake log...

15:08:41 -- Found Wayland_Client:
/usr/lib/x86_64-linux-gnu/libwayland-client.so (found version
"1.12.90")
15:08:41 -- Found Wayland_Cursor:
/usr/lib/x86_64-linux-gnu/libwayland-cursor.so (found version
"1.12.90")
15:08:42 -- Found Wayland_Egl:
/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found version "11.0.2")
15:08:42 -- Found Wayland:
/usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so
(found suitable version "1.12.90", minimum required is "1.2") found
components:  Cursor Egl
15:08:42 -- Could NOT find XKB: Found unsuitable version "0.5.0", but
required is at least "0.7.0" (found
/usr/lib/x86_64-linux-gnu/libxkbcommon.so)
15:08:42 -- Found Libinput: /usr/lib/x86_64-linux-gnu/libinput.so
(found suitable version "1.5.2", minimum required is "1.5")
15:08:42 -- 

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-01-05 11:20, schrieb Ben Cooksley:
>>
>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
>> <pri...@martin-graesslin.com> wrote:
>>>
>>> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> It seems that my previous vocal complaints about system level /
>>>> serious impact dependency bumps on the CI system have gone completely
>>>> unnoticed by (some) members of our Community.
>>>>
>>>> This was demonstrated earlier this week when components of Plasma
>>>> bumped their version requirements for XKBCommon and Appstream-Qt -
>>>> without even a thought about notifying Sysadmin or checking which
>>>> version the CI had, until their builds broke.
>>>>
>>>> Neither of these is easy to fix at this stage, as the system base is
>>>> now too old to receive updates such as these. Base upgrades require a
>>>> full rebuild of everything on the CI system, and usually involve
>>>> significant additional churn and is a process that must be done
>>>> roughly twice a year, depending on dependency bump demands.
>>>>
>>>> Does anyone have any suggestions as to how we may avoid this in the
>>>> future?
>>>
>>>
>>>
>>> I have a few questions here:
>>>
>>> 1) Where is this requirement to check with sysadmins codified? So far I
>>> was
>>> only aware of dependency freeze.
>>
>>
>> It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
>> Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
>> whole of PIM broke when they started using QtWebEngine. That was
>> around March/April 2016, my mail archives can't seem to find the exact
>> thread though.
>
>
> I'm sorry Ben, but I fear "sending out a mail about an issue with PIM"
> doesn't
> qualify as codifying it. Given what we have it looks like this did not reach
> the
> target audience. And neither will this thread.

Uhm, it was far more than a single email. It was quite the thread, and
if memory serves was on at least one of the mailing lists this thread
was on.
One of the key things that came out of that thread was to ask for
things to be bumped well in advance if a newer version is needed.

I'm disappointed that you think that email threads have insufficient
reach given it's one of our communities principal means of
communication.

>
> This needs to change the process, the way KDE develops software. It needs to
> be
> listed in the release schedule (is not, I checked), maybe reviews need to be
> acked by release managers, etc.

It seems to be part of the process for many others already, so not
sure what needs to change. The gpgme transition went quite well for
PIM, and other applications developers have reached out and asked
about version upgrades to various libraries which were in their area
of interest which we have sorted out easily enough.

>
>>
>>> 2) How can we easily check what build.kde.org has? Looking at cmake
>>> output
>>> is not a sufficient way as it gives me wrong information
>>
>>
>> If CMake is outputting wrong information, then your CMakeLists.txt
>> can't make the appropriate decisions as to whether the available
>> version is suitable, so i'd say you've got bigger problems here that
>> need to be addressed first.
>
>
> Cmake feature summary says: "required version >= 0.5" and that's for all
> found
> depeendencies. Unfortunately no information at all in the feature summary
> about
> the actual version.

Quoting the KWin CMake log...

15:08:41 -- Found Wayland_Client:
/usr/lib/x86_64-linux-gnu/libwayland-client.so (found version
"1.12.90")
15:08:41 -- Found Wayland_Cursor:
/usr/lib/x86_64-linux-gnu/libwayland-cursor.so (found version
"1.12.90")
15:08:42 -- Found Wayland_Egl:
/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found version "11.0.2")
15:08:42 -- Found Wayland:
/usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so
(found suitable version "1.12.90", minimum required is "1.2") found
components:  Cursor Egl
15:08:42 -- Could NOT find XKB: Found unsuitable version "0.5.0", but
required is at least "0.7.0" (found
/usr/lib/x86_64-linux-gnu/libxkbcommon.so)
15:08:42 -- Found Libinput: /usr/lib/x86_64-linux-gnu/libinput.so
(found suitable version "1.5.2", minimum required is "1.5")
15:08:42 -- 

Re: Scheduled downtime: spring.kde.org

[Ben Cooksley]

Hi all,

The system upgrade has now been completed - all of the previously
mentioned services should now be back online.
Please let us know if you find anything which is not functioning correctly.

Thanks,
Ben

Re: Scheduled downtime: spring.kde.org

[Ben Cooksley]

Hi all,

The system upgrade has now been completed - all of the previously
mentioned services should now be back online.
Please let us know if you find anything which is not functioning correctly.

Thanks,
Ben

Re: Scheduled downtime: spring.kde.org

[Ben Cooksley]

Hi all,

The system upgrade has now been completed - all of the previously
mentioned services should now be back online.
Please let us know if you find anything which is not functioning correctly.

Thanks,
Ben

Scheduled downtime: spring.kde.org

[Ben Cooksley]

Hi all,

I'm scheduling downtime of a few hours for tomorrow (28th December),
from 9am NZDT (UTC+13) for the server spring.kde.org. This is to allow
for a system upgrade to Ubuntu 16.04 LTS. This is part of our program
of phasing out Ubuntu 14.04 on our systems.

This upgrade also lays the ground work for later upcoming changes
surrounding notes.kde.org and share.kde.org which will be announced
later.

Spring hosts the following services, all of which will be fully
unavailable during the maintenance period:

- Nextcloud (share.kde.org)
- Jabber (kdetalk.net)
- IRC Bouncer (ZNC - bnc.kde.org)
- IRC Telegram Bridge (IrcsomeBot)
- Various IRC Bots (pursuivant, sKreamer, insanity, Amarok)

For those of you using the Bouncer, it is imperative you are either
connected to the Bouncer at the time of shutdown, or have enabled the
'savebuff' module (see http://wiki.znc.in/Savebuff) otherwise any
unreceived messages will be lost when ZNC is shutdown as part of the
system upgrade.

Thanks,
Ben Cooksley
KDE Sysadmin

Scheduled downtime: spring.kde.org

[Ben Cooksley]

Hi all,

I'm scheduling downtime of a few hours for tomorrow (28th December),
from 9am NZDT (UTC+13) for the server spring.kde.org. This is to allow
for a system upgrade to Ubuntu 16.04 LTS. This is part of our program
of phasing out Ubuntu 14.04 on our systems.

This upgrade also lays the ground work for later upcoming changes
surrounding notes.kde.org and share.kde.org which will be announced
later.

Spring hosts the following services, all of which will be fully
unavailable during the maintenance period:

- Nextcloud (share.kde.org)
- Jabber (kdetalk.net)
- IRC Bouncer (ZNC - bnc.kde.org)
- IRC Telegram Bridge (IrcsomeBot)
- Various IRC Bots (pursuivant, sKreamer, insanity, Amarok)

For those of you using the Bouncer, it is imperative you are either
connected to the Bouncer at the time of shutdown, or have enabled the
'savebuff' module (see http://wiki.znc.in/Savebuff) otherwise any
unreceived messages will be lost when ZNC is shutdown as part of the
system upgrade.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: All Frameworks modules are now available as repositories on Phabricator

[Ben Cooksley]

On Wed, Dec 28, 2016 at 8:56 AM, Luigi Toscano  wrote:
> Elvis Angelaccio ha scritto:
>> On Mon, Dec 26, 2016 at 1:19 AM, Luigi Toscano  
>> wrote:
>>> ... so that it's easier to use Differential for reviews.
>>
>> Thanks!
>> What about tasks? Should we create a Workboard for the Frameworks
>> project? Or is it planned that each framework be a Project with its
>> own workboard?
>
> This is entirely up to each maintainer. I personally think that 80% of the
> modules in Frameworks don't need a separate project for each of them, but
> again, if someone needs a separate project (and workboard), sure, it can be
> created.

For this very reason, as a general rule we'll only be creating
projects on a as-needed / requested basis (as a forest of empty and
unused projects splinters focus, makes it harder for new people to get
involved, etc)

>
> Ciao
> --
> Luigi
>

Cheers,
Ben

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

Hi all,

Can we please keep this thread on-topic. For the record, going off topic means:

a) Mentioning anything about distro patching
b) Mentioning anything about ifdefs.

All the above is serving to do is inflame things, and divert from the
current topic of this thread which is to sort out the dependencies
policy.
Whether or not those two have any merit is up for debate, but that can
be done in a separate thread.

Regards,
Ben

Re: How am i supposed to use arc? - was - Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Mon, Mar 27, 2017 at 9:34 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El diumenge, 26 de març de 2017, a les 20:26:25 CEST, A. Bikadorov va
> escriure:
>> On 26.03.2017 20:17, Albert Astals Cid wrote:
>> > El diumenge, 26 de mar� de 2017, a les 18:41:00 CEST, A. Bikadorov va
>> >
>> > escriure:
>> >> On 26.03.2017 18:36, Boudhayan Gupta wrote:
>> >>> Write it in a wiki page?
>> >>>
>> >>> Freundliche Gr��e
>> >>> Boudhayan Gupta
>> >>> KDE e.V. - Sysadmin and Community Working Groups
>> >>> +49 151 71032970
>> >>>
>> >>> On 26 March 2017 at 18:33, Albert Astals Cid <aa...@kde.org> wrote:
>> >>>> El diumenge, 29 de gener de 2017, a les 8:32:21 CEST, Ben Cooksley va
>> >>>>
>> >>>> escriure:
>> >>>>> Hi everyone,
>> >>>>>
>> >>>>> We've just completed the registration of all mainline repositories
>> >>>>> (not including Websites or Sysadmin namespaced ones) on Phabricator.
>> >>>>> Thanks go to Luigi Toscano for providing significant assistance with
>> >>>>> this process.
>> >>>>>
>> >>>>> From this point forward, communities should be moving away from
>> >>>>> Reviewboard to Phabricator for conducting code review. Sysadmin will
>> >>>>> be announcing a timeline for the shutdown of Reviewboard in the near
>> >>>>> future.
>> >>>>>
>> >>>>> Projects which haven't yet looked into Phabricator, including getting
>> >>>>> things like mailing list notifications and projects setup should do so
>> >>>>> as soon as practical.
>> >>>>>
>> >>>>> As part of the registration process, Sysadmin tagged repositories,
>> >>>>> associating them to Projects. These tags show what a repository is
>> >>>>> associated with and it's status.
>> >>>>>
>> >>>>> This includes things like whether development is currently active (the
>> >>>>> Historical Archival and Up For Adoption tags), which release unit it
>> >>>>> is part of (KDE Applications, Frameworks, etc) and the general
>> >>>>> development effort it is associated with.
>> >>>>>
>> >>>>> It would be appreciated if everyone could please check their
>> >>>>> repositories to ensure they've been tagged correctly. Adjustments can
>> >>>>> either be sent as replies to this email (include sysadmin@ in CC
>> >>>>> please) or by asking a member of the Community Admins project on
>> >>>>> Phabricator to make the change for you.
>> >>>>
>> >>>> I tried using arc today, after reading some documentation it seems i
>> >>>> need
>> >>>> to use
>> >>>>
>> >>>> arc diff
>> >>>>
>> >>>> to upload a patch, but then i got hit by
>> >>>>
>> >>>>
>> >>>> $ arc diff
>> >>>> Usage Exception: This command requires arc to connect to a Phabricator
>> >>>> install, but no
>> >>>>
>> >>>> Phabricator installation is configured. To configure a Phabricator URI:
>> >>>>   - set a default location with `arc set-config default `; or
>> >>>>   - specify `--conduit-uri=uri` explicitly; or
>> >>>>   - run `arc` in a working copy with an '.arcconfig'.
>> >>>>
>> >>>> And i couldn't find more documentation on how to move forward.
>> >>>> Ultimately
>> >>>> I
>> >>>> asked Aleix that told me "copy the .arcconfig file from
>> >>>> plasma-desktop".
>> >>>>
>> >>>> Since newbies usually don't have Aleix at hand, how do we fix this?
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>>   Albert
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Ben Cooksley
>> >>>>> KDE Sysadmin
>> >>
>> >> Which is already done?
>> >> -> https://community.kde.org/Infrastructure/Phabricator#Connecting_to_KDE
>> >
&

D5178: QtCurve/Qt5 : further KF5 adaptation

[Ben Cooksley]

bcooksley added a comment.


  We won't be modifying Phabricator, in part because Arcanist as shipped by 
upstream is designed to work with that text.
  Modifying it will create maintenance burden in the long run and lead to 
incompatibility with the software which runs on developers systems - requiring 
us to maintain a fork of Arcanist as well.

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D5178

To: rjvbb, yuyichao
Cc: bcooksley, ltoscano, #frameworks, yuyichao

Threadweaver compilation failure: Windows

[Ben Cooksley]

Hi all,

If someone could take a look at the following build log that would be
appreciated:
https://paste.kde.org/pzyhxydjw/xxx39x/raw

Cheers,
Ben

Re: KAuth buildability: new CI architecture

[Ben Cooksley]

On Mon, Apr 17, 2017 at 12:48 AM, Martin Gräßlin <mgraess...@kde.org> wrote:
> Am 2017-04-16 13:52, schrieb Ben Cooksley:
>>
>> On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter <sit...@kde.org> wrote:
>>>
>>> Not particularly related to the issue at hand (which is probably
>>> polkitqt having meh cmake files), but relocating stuff in general is
>>> sper unreliable and I would absolutely advise against it as it can
>>> easily screw up test results and builds alike, often in unobvious ways
>>> (all it takes is a bit of libexec use). Instead, as a general
>>> principle, I would suggest that you get stuff mounted in suitably
>>> stable/consistent/generic paths inside the build containers.
>>> Ultimately what things look like natively on the host file system
>>> shouldn't factor into what they look like in the build environment.
>>
>>
>> While I have thought of using a consistent path, this would simply
>> workaround the fact that our binaries are frail and have hardcoded
>> paths baked into them.
>
>
> note that this is partially intended for security reasons. E.g.
> kscreenlocker starts kcheckpass through a hardcoded path for security
> reasons (we want to be sure it's the kcheckpass we created and not a
> fakekcheckpass injected by a malicious tool). So overall especially in
> plasma lots of Wayland stuff is hardcoding paths for this reason and
> partially they are used in testing.
>
> In the case of kscreenlocker this can become a problem when KWin tests are
> run. We have tests verify that locking the screen works on Wayland. For that
> kscreenlocker_greet gets started and that has a hardcoded path as well. So
> if the paths is relocated we test an unsupported setup.

Would it be possible to use relative-to-calling-binary paths? The new
CI scripts do this to find their configuration and other resources
they need so it should be doable (note that the new CI environment
unpacks everything into the same directory when assembling an install
prefix so one can run with that assumption - and it's one that should
be true on 99% of systems out there)

This should meet the security requirements (if someone is running
their own kscreenlocker / kwin / etc binaries then chances are they
can modify the executable directly anyway)

>
> Cheers
> Martin

Cheers,
Ben

Re: Threadweaver compilation failure: Windows

[Ben Cooksley]

On Thu, Apr 20, 2017 at 10:54 PM, Alexey Min <alexey@gmail.com> wrote:
> Again, I don't have full Visual Studio installed, only build tools.
> Command Prompt does not show me anything, but installer displays
> version number - 15.1 (26403.7)
> ( https://puu.sh/vqgvx/f9122db5ef.png )

Okay. Could you try building with these arguments to CMake and see what happens?

-DCMAKE_BUILD_TYPE=Debug -DECM_ENABLE_SANITIZERS='address' -DBUILD_TESTING=ON

Thanks,
Ben



>
> 2017-04-20 15:31 GMT+05:00 Ben Cooksley <bcooks...@kde.org>:
>> On Wed, Apr 19, 2017 at 7:24 PM, Alexey Min <alexey@gmail.com> wrote:
>>> Built fine for me with "Build Tools for Visual Studio 2017"
>>> (https://www.visualstudio.com/downloads/ "Other Tools And Frameworks"
>>> section) which contains only compiler and libs without IDE.
>>
>> Okay. Would you mind checking what version of VS 2017 you've got?
>> The system i'm using has 15.0.26403.7 (per the CMD prompt)
>>
>>>
>>> I used part of the environment provided by craft, for cmake to able to
>>> find ECM (my KDEROOT is E:\KDE, or R:\).
>>> First I built threadweaver using craft, msvc2015 x64, to make sure it
>>> compiles with msvc2015.
>>>
>>> I went for manual procedure with vc2017: manually installed
>>> cmake-3.8.0 into craft's dir R:/dev-utils/cmake (by default craft has
>>> 3.7)
>>> Then launched Start menu -> Visual Studio 2017 -> x64 Native Tools
>>> Command Prompt.
>>> From there manually launched cmake with source dir set to where craft
>>> downloaded sources, E:/KDE/download/git/threadweaver, build dir to
>>> manually created E:/KDE/build/frameworks/threadweaver/vc2017.
>>> Configured with generator "NMake Makefiles", "Use default native compilers"
>>>
>>> and full build log https://paste.kde.org/pvhyt3xxo
>>>
>>
>> Cheers,
>> Ben
>>
>>>
>>> 2017-04-18 14:37 GMT+05:00 Ben Cooksley <bcooks...@kde.org>:
>>>> On Tue, Apr 18, 2017 at 6:53 PM, Kevin Funk <kf...@kde.org> wrote:
>>>>> On Monday, 17 April 2017 22:43:56 CEST Aleix Pol wrote:
>>>>>> On Mon, Apr 17, 2017 at 6:09 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>>>>>> > Hi all,
>>>>>> >
>>>>>> > If someone could take a look at the following build log that would be
>>>>>> > appreciated:
>>>>>> > https://paste.kde.org/pzyhxydjw/xxx39x/raw
>>>>>>

Re: Threadweaver compilation failure: Windows

[Ben Cooksley]

On Wed, Apr 19, 2017 at 7:24 PM, Alexey Min <alexey@gmail.com> wrote:
> Built fine for me with "Build Tools for Visual Studio 2017"
> (https://www.visualstudio.com/downloads/ "Other Tools And Frameworks"
> section) which contains only compiler and libs without IDE.

Okay. Would you mind checking what version of VS 2017 you've got?
The system i'm using has 15.0.26403.7 (per the CMD prompt)

>
> I used part of the environment provided by craft, for cmake to able to
> find ECM (my KDEROOT is E:\KDE, or R:\).
> First I built threadweaver using craft, msvc2015 x64, to make sure it
> compiles with msvc2015.
>
> I went for manual procedure with vc2017: manually installed
> cmake-3.8.0 into craft's dir R:/dev-utils/cmake (by default craft has
> 3.7)
> Then launched Start menu -> Visual Studio 2017 -> x64 Native Tools
> Command Prompt.
> From there manually launched cmake with source dir set to where craft
> downloaded sources, E:/KDE/download/git/threadweaver, build dir to
> manually created E:/KDE/build/frameworks/threadweaver/vc2017.
> Configured with generator "NMake Makefiles", "Use default native compilers"
>
> and full build log https://paste.kde.org/pvhyt3xxo
>

Cheers,
Ben

>
> 2017-04-18 14:37 GMT+05:00 Ben Cooksley <bcooks...@kde.org>:
>> On Tue, Apr 18, 2017 at 6:53 PM, Kevin Funk <kf...@kde.org> wrote:
>>> On Monday, 17 April 2017 22:43:56 CEST Aleix Pol wrote:
>>>> On Mon, Apr 17, 2017 at 6:09 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>>>> > Hi all,
>>>> >
>>>> > If someone could take a look at the following build log that would be
>>>> > appreciated:
>>>> > https://paste.kde.org/pzyhxydjw/xxx39x/raw
>>>>

KAuth buildability: new CI architecture

[Ben Cooksley]

Hi all,

As some will be aware i've been working on a new architecture for the
CI system which will solve a number of the problems we currently have
with the current iteration.

The new design should allow us to:
1) Use different base systems for different groupings of projects
2) Will eliminate installations changing mid-build (the RSync and file
not found errors which we hit from time to time)
3) Be more efficient when fetching dependencies

Unfortunately the new architecture has itself found some issues as
installations are relocated as part of the new design (necessary to
resolve #2). While our Frameworks handle this fine (for building at
least) unfortunately Polkit-Qt can't.

This blocks the build of KAuth, and in turn about half of the whole
Frameworks stack.

I've attached the build log. Would someone please be able to investigate this?

Thanks,
Ben


consoleText
Description: Binary data

Re: KAuth buildability: new CI architecture

[Ben Cooksley]

On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter  wrote:
> Not particularly related to the issue at hand (which is probably
> polkitqt having meh cmake files), but relocating stuff in general is
> sper unreliable and I would absolutely advise against it as it can
> easily screw up test results and builds alike, often in unobvious ways
> (all it takes is a bit of libexec use). Instead, as a general
> principle, I would suggest that you get stuff mounted in suitably
> stable/consistent/generic paths inside the build containers.
> Ultimately what things look like natively on the host file system
> shouldn't factor into what they look like in the build environment.

While I have thought of using a consistent path, this would simply
workaround the fact that our binaries are frail and have hardcoded
paths baked into them.

The CI has always run an unusual configuration as part of it's job is
to find brittle parts of our codebase and make the breakage visible.

Outside of traditionally provided FOSS packaging, relocatable binaries
are something we'll need - for Windows packages for instance as users
there expect to be able to specify the installation directory (on that
note - log for kcoreaddons on Windows is attached with several test
failures, and it looks like the logic around ASAN on Windows needs
adjustment too).

We'll see how things go.

>
> For example, in neon we simply mount everything into /workspace of our
> containers.
>
> You could have
>
> /workspace
> |_ src/  [on host: /home/jenkins/workspace/polkit-qt-1 kf5-qt5 
> XenialQt5.7/
> |_ install/  [on host: /home/jenkins/workspace/polkit-qt-1 kf5-qt5
> XenialQt5.7/install-prefix/]

The workspaces are, on the Linux systems at least, thrown away at the
completion of a job. The only thing that survives is a tarball archive
of the files installed by the job.

>
> Notably advantage is that relocation issue get entirely eliminated as
> the install prefix is always the same, and as an added bonus paths
> become much shorter and easier to read in the build logs.
>
> It also detaches the build tooling from the host tooling. e.g. the
> build code at this point no longer needs to care about which path
> Jenkins was installed to, or where it was configured to put
> workspaces, or what the jenkins job name is, or if jenkins is even
> still used.
>
> Food for thought :)
>
> HS

Cheers,
Ben


kcoreaddons-windows-build.log
Description: Binary data

Re: Threadweaver compilation failure: Windows

[Ben Cooksley]

On Fri, Apr 21, 2017 at 11:43 PM, Alexey Min <alexey@gmail.com> wrote:
> P.S.: But it built fine when I changed -DQT_STRICT_ITERATORS to
> -UQT_STRICT_ITERATORS in CXX_DEFINES. This affects class
> QTypedArrayData (
> http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qarraydata.h#n131
> ) maybe someone will have some clever thoughts with this info.

Hi Alexey,

Thanks for tracking that down. I'll look into forcibly disabling
QT_STRICT_ITERATORS with MSVC 2017 as an interim workaround so we can
get the rest of Frameworks built.

Regards,
Ben

>
> 2017-04-21 15:46 GMT+05:00 Alexey Min <alexey@gmail.com>:
>> Ok, I created "Debug" caft build environment and repeated build with
>> cmake parameters you asked, and I guess it shows exactly the same
>> build log with exactly the same error in the end -
>> https://paste.kde.org/p8wj1dqzf
>> Looks like a problem in STL header with debug iterator? Compiler
>> unable to find proper overload...
>>
>> 2017-04-20 16:03 GMT+05:00 Ben Cooksley <bcooks...@kde.org>:
>>>
>>> Okay. Could you try building with these arguments to CMake and see what 
>>> happens?
>>>
>>> -DCMAKE_BUILD_TYPE=Debug -DECM_ENABLE_SANITIZERS='address' 
>>> -DBUILD_TESTING=ON