Re: Will kopete be ported to kf5?

[Luigi Toscano]

Pali Rohár ha scritto:
> On Monday 08 January 2018 22:28:28 Shawn Sorbom wrote:

> 
>> Second, I found a bug in MUC handling with jabber. Where would the best
>> place
>> to report it be?
> 
> Probably the best place is kde bugzilla, but I do not know how many
> people watch bugzilla. It has broken email support and kde team decided
> to not fix it. Therefore I stopped using it.

Pali, bugzilla email works for many developers and this is the first time that
I heard issues with that. If it does not work with your email, it's possible
to redirect the notifications to a mailing list (like this; it works for
example for Okular).
Also, you can periodically check queries on the website for updated/new bugs.

Given that contributors expect to use bugzilla, not looking at it is not doing
a favor to the community.

-- 
Luigi

Re: Will kopete be ported to kf5?

[Pali Rohár]

On Monday 08 January 2018 22:28:28 Shawn Sorbom wrote:
> First off,
> Hi!

Hi!

> I really enjoy using kopete! I was wondering if I would be able to continue
> doing so in the brave new KF5 Era (IE, would somebody port it? Please,
> please,
> please)?

Kopete was ported to KF5 and now in master git branch is KF5 version
only.

> Second, I found a bug in MUC handling with jabber. Where would the best
> place
> to report it be?

Probably the best place is kde bugzilla, but I do not know how many
people watch bugzilla. It has broken email support and kde team decided
to not fix it. Therefore I stopped using it.

> Third, Are you accepting feature requests?

Feature requests can be send, but I do not think there are many people
who would willing to implement it.

Therefore state is "patches are welcome".

> Fourth, Did I mention I really want to see kopete survive?
> Thanks,
> --Shawn

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Re: Rebase of kopete branch and push it to master

[Ben Cooksley]

On Thu, Jan 25, 2018 at 11:26 AM, Pali Rohár  wrote:
> On Friday 19 January 2018 21:56:10 Ben Cooksley wrote:
>> On Fri, Jan 19, 2018 at 12:06 PM, Pali Rohár  wrote:
>> > On Thursday 18 January 2018 20:50:35 Ben Cooksley wrote:
>> >> Hi all,
>> >>
>> >> I have now completed the merge from Pali's clone repository into the
>> >> 'master' branch of the main Kopete repository.
>> >> Phabricator processing of all the commits has been completed without 
>> >> incident.
>> >
>> > Hi! Thank you very very much!
>> >
>> >> Pali, please revise the metadata accordingly in sysadmin/repo-metadata
>> >
>> > See quoted comments/questions below
>> >
>> > https://phabricator.kde.org/source/sysadmin-repo-metadata/browse/master/projects/kde/kdenetwork/kopete/metadata.yaml
>> >
>> >> description: 'h1. Kopete - The KDE Instant Messenger
>> >
>> > What does "h1." means? Looks like some wiki(?) syntax for heading. No
>> > idea if it should be there or not.
>>
>> That is a leftover from when this data was generated from the
>> descriptions used by projects.kde.org, which ran Redmine/Chiliproject.
>> It means nothing to anything we run these days and should be cleaned up.
>>
>> >
>> >> - displayname: "Pali Roh\xE1r"
>> >
>> > What is encoding of that YAML file? Is not UTF-8 supported?
>>
>> The conversion tool we used was conservative in regards to handling
>> information and encoded everything that couldn't be represented in
>> Latin-1 I believe.
>> I've entered UTF-8 characters into other files, and they certainly
>> should be encoded in and support, UTF-8.
>
> Ok. Is some step from my side needed now?

Please feel free to update that file to use the UTF-8 version of your
name should you wish to do so.

>
>> >
>> > Otherwise looks correct.
>> >
>> > https://phabricator.kde.org/source/sysadmin-repo-metadata/browse/master/projects/kde/kdenetwork/kopete/i18n.json
>> >
>> >> {"trunk": "master", "stable": "Applications/17.08", "stable_kf5": "none", 
>> >> "trunk_kf5": "none"}
>> >
>> > I do not fully understand content of this JSON file, but there is no
>> > KDE4 trunk version in repository anymore. master branch now points to
>> > trunk KF5 version and there is no 17.12 (stable) version.
>>
>> Luigi has now updated this I believe.
>>
>> >
>> >> (for i18n) and kde-build-metadata (for the CI and kdesrc-build users)
>> >
>> > It is https://phabricator.kde.org/source/kde-build-metadata/ right? What
>> > should I check there?
>>
>> In that repository you need to check two things:
>>
>> 1) logical-module-structure, JSON formatted, which defines a series of
>> rules stating which branches are used by projects.
>
> Seems correct.

Excellent.

>
>> 2) the dependency-data-* files, which contain the dependency
>> definition rules between KDE projects for each branch grouping.
>> Anything not defined in here won't be made available on the CI, and
>> this data is used by kdesrc-build to sequence the order of things to
>> build.
>>
>> In regards to the dependency data, please note that there is a generic
>> wildcard rule at the very bottom which makes essentially all
>> Frameworks a dependency of anything in Applications, Extragear or
>> Playground so you don't need to declare a dependency on any Framework
>> you use.
>
> This IIRC should be enough. Anyway, if there is CI problem, is report
> send to somewhere?

Please file a task on Phabricator against the build.kde.org project
and we'll take it from there.

>
>> Hope that clears things up.
>>
>> Cheers,
>> Ben
>>
>> >
>> >> as soon as possible.
>> >>
>> >> Regards,
>> >> Ben
>> >
>> > --
>> > Pali Rohár
>> > pali.ro...@gmail.com
>
> --
> Pali Rohár
> pali.ro...@gmail.com

Cheers,
Ben

D9981: Remove obsolete content from Kopete docbook

[Pali Rohár]

pali accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R434 Kopete

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

To: lueck, #documentation, pali
Cc: #kopete, cochise

D9981: Remove obsolete content from Kopete docbook

[Burkhard Lück]

lueck created this revision.
lueck added reviewers: Documentation, pali.
Restricted Application added a project: Kopete.
Restricted Application added a subscriber: Kopete.
lueck requested review of this revision.

REVISION SUMMARY
  remove or replace entities already defined in kdoctools
  remove obsolete comments
  remove link to kopete website, does not exist any more
  replace kde-look.org with store.kde.org
  remove obsolete appendix, unused in kf5

TEST PLAN
  checkXML5 doc/index.docbook

REPOSITORY
  R434 Kopete

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

AFFECTED FILES
  doc/index.docbook
  doc/pipes.docbook

To: lueck, #documentation, pali
Cc: #kopete, cochise

D9981: Remove obsolete content from Kopete docbook

[Burkhard Lück]

lueck updated this revision to Diff 25657.
lueck added a comment.


  add mising context

REPOSITORY
  R434 Kopete

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9981?vs=25641&id=25657

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

AFFECTED FILES
  doc/index.docbook
  doc/pipes.docbook

To: lueck, #documentation, pali
Cc: #kopete, cochise

Will kopete be ported to kf5?

[Shawn Sorbom]

First off,
Hi!
I really enjoy using kopete! I was wondering if I would be able to continue
doing so in the brave new KF5 Era (IE, would somebody port it? Please,
please,
please)?
Second, I found a bug in MUC handling with jabber. Where would the best
place
to report it be?
Third, Are you accepting feature requests?
Fourth, Did I mention I really want to see kopete survive?
Thanks,
--Shawn

Re: KDE and Google Summer of Code 2018

[Valorie Zimmerman]

I'm very discouraged to see so little movement on this. After skipping GCi
this past fall, are we now also considering skipping GSoC? Or downsizing
the number of students we are mentoring?

Without Ideas we will not get students. More important, we must complete
the Org application soon, and the Ideas page is the core of that
application.

This is good for your team and your project, in the long run. It brings in
new contributors and fresh ideas.

If you need some guidance, please read
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html

I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
valorie.zimmer...@gmail.com> wrote:

>
> Hello GSoC mentors, and teams supporting mentors,
>
> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
> https://community.kde.org/GSoC. Now.
>
> Every year, we've asked for more time to get ramped up for GSoC, and so
> now is the time for organizations to apply[1]. We have begun to write our
> application, and  that means that our Ideas page needs to be filled NOW,
> because that is the prime consideration for the GSoC team once the Org
> Applications deadline has passed.
>
> The quality of our ideas and the guidance they give our students are the
> most important part of our application. Please begin filling in your ideas
> now if you have not already, and ensure that that page is comprehensive,
> accurate and attractive. Including screenshots and other images is allowed,
> if it enriches the idea for a project. *Please ensure complete information
> about how to contact the team*; this is crucial.
>
> Also, take a look at the landing page https://community.kde.org/GSoC.
> Experienced mentors agree that:
>
> 1. commits must be made before the student proposal is submitted, and
> linked on that proposal, and
>
> 2. that regular communication from the student must be initiated by the
> student at least weekly, and we expect daily or nearly daily communication
> with the team in a more informal way.
>
> Be sure to point students to that information, as this should lower the
> number of proposals, while raising the quality.
>
> 1. https://developers.google.com/open-source/gsoc/timeline
>
> PS: If your team has an Idea, ensure that you have mentors for it, and
> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
> without mentors available, please. Now, before you forget!
>
> Valorie
>


-- 
http://about.me/valoriez

Re: Rebase of kopete branch and push it to master

[Alexander Semke]

On 16.01.2018 00:45, Pali Rohár wrote:

Because it does not work.

remote: Push declined - excessive notifications would be sent
remote: Please file a KDE Sysadmin bug to continue

Therefore I opened sysadmin ticket T7642 and I was told that I should
discuss about it on kde-core-devel.

If I remember it correctly, we had this problem last year in LabPlot 
when we decided to bring frameworks into master, too.
We then merged frameworks into master (no rebase) and pushed this merge 
to remote. I think the history is still there in the sense
that I can see all those "KDE4Libs->KF5" changes done in the frameworks 
branch when bringing master into frameworks, etc.


Did you try already
1. merge the current master to master-kf5 and finish all the porting stuff
2. merge master-kf5 back into master
3. check the history in master

--
Alexander

Re: KDE and Google Summer of Code 2018

[Marco Martin]

On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham  wrote:
> I've submitted an idea for System Settings: Improve handling for touchpads
> and mice with Libinput

Speaking of systemsettings, would be a good fit porting to qml some
medium-to-big kcm?
--
Marco Martin

Re: Rebase of kopete branch and push it to master

[Alexander Semke]

On 16.01.2018 09:20, Pali Rohár wrote:



Did you try already
1. merge the current master to master-kf5 and finish all the porting stuff

If you by "merge" means only git merge without git push, then this
operation does nothing.
Of course you have to push after the merge. But you can try to do the 
merge and to check the history first.
Instead of bringing in hundreds of commits with a rebase you would bring 
in one single merge commit.

If you're ok with the history, do the push.



  Commit on top of master branch is also ancestor
accessible from master-kf5.
Why do you want to care about master-kf5 at all once you brought 
everything into master?



2. merge master-kf5 back into master

See above, it does nothing. And git push (after git merge) is failing.
It brings all porting changes done in master-kf5 into master. Push 
shouldn't fail in this case because you will end up with one single 
merge commit.


--
Alexander

Re: KDE and Google Summer of Code 2018

[Nate Graham]

I've submitted an idea for System Settings: Improve handling for 
touchpads and mice with Libinput


https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput

This is pretty important going forward since most distros are shipping 
with Libinput now, but our users aren't able to configure their devices 
without resorting to editing xorg config files using a different driver.


Nate


On 01/15/2018 06:13 AM, Dmitry Kazakov wrote:

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
mailto:valorie.zimmer...@gmail.com>> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

Re: KDE and Google Summer of Code 2018

[Johnny Jazeix]

Hi,

on GCompris side, we hope/plan to mentor 2 students like last year. I
updated the page to add one more task.

Regarding the events: this year, we were planning to skip SoK to focus more
on GCi and GSoC, having the 3 events is too consuming and do not allow us
to progress on our main tasks. There was a bit of change due to the fact
that it was GCi that was skipped but the main point is still there, we
don't have enough time/resource to handle the 3 events.

Johnny


2018-01-15 1:39 GMT+01:00 Valorie Zimmerman :

> I'm very discouraged to see so little movement on this. After skipping GCi
> this past fall, are we now also considering skipping GSoC? Or downsizing
> the number of students we are mentoring?
>
> Without Ideas we will not get students. More important, we must complete
> the Org application soon, and the Ideas page is the core of that
> application.
>
> This is good for your team and your project, in the long run. It brings in
> new contributors and fresh ideas.
>
> If you need some guidance, please read https://google.github.io/
> gsocguides/mentor/defining-a-project-ideas-list.html
>
> I should have linked to it for the last email.
>
> Valorie
>
> On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
> valorie.zimmer...@gmail.com> wrote:
>
>>
>> Hello GSoC mentors, and teams supporting mentors,
>>
>> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
>> https://community.kde.org/GSoC. Now.
>>
>> Every year, we've asked for more time to get ramped up for GSoC, and so
>> now is the time for organizations to apply[1]. We have begun to write our
>> application, and  that means that our Ideas page needs to be filled NOW,
>> because that is the prime consideration for the GSoC team once the Org
>> Applications deadline has passed.
>>
>> The quality of our ideas and the guidance they give our students are the
>> most important part of our application. Please begin filling in your ideas
>> now if you have not already, and ensure that that page is comprehensive,
>> accurate and attractive. Including screenshots and other images is allowed,
>> if it enriches the idea for a project. *Please ensure complete information
>> about how to contact the team*; this is crucial.
>>
>> Also, take a look at the landing page https://community.kde.org/GSoC.
>> Experienced mentors agree that:
>>
>> 1. commits must be made before the student proposal is submitted, and
>> linked on that proposal, and
>>
>> 2. that regular communication from the student must be initiated by the
>> student at least weekly, and we expect daily or nearly daily communication
>> with the team in a more informal way.
>>
>> Be sure to point students to that information, as this should lower the
>> number of proposals, while raising the quality.
>>
>> 1. https://developers.google.com/open-source/gsoc/timeline
>>
>> PS: If your team has an Idea, ensure that you have mentors for it, and
>> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
>> without mentors available, please. Now, before you forget!
>>
>> Valorie
>>
>
>
> --
> http://about.me/valoriez
>

Re: KDE and Google Summer of Code 2018

[Dmitry Kazakov]

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
mailto:valorie.zimmer...@gmail.com>> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

KDE and Google Summer of Code 2018

[Valorie Zimmerman]

Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC, and so now
is the time for organizations to apply[1]. We have begun to write our
application, and  that means that our Ideas page needs to be filled NOW,
because that is the prime consideration for the GSoC team once the Org
Applications deadline has passed.

The quality of our ideas and the guidance they give our students are the
most important part of our application. Please begin filling in your ideas
now if you have not already, and ensure that that page is comprehensive,
accurate and attractive. Including screenshots and other images is allowed,
if it enriches the idea for a project. *Please ensure complete information
about how to contact the team*; this is crucial.

Also, take a look at the landing page https://community.kde.org/GSoC.
Experienced mentors agree that:

1. commits must be made before the student proposal is submitted, and
linked on that proposal, and

2. that regular communication from the student must be initiated by the
student at least weekly, and we expect daily or nearly daily communication
with the team in a more informal way.

Be sure to point students to that information, as this should lower the
number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline

PS: If your team has an Idea, ensure that you have mentors for it, and that
those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
without mentors available, please. Now, before you forget!

Valorie
-- 
http://about.me/valoriez

Re: Rebase of kopete branch and push it to master

[Ivan Čukić]

Hi all,

Would it be possible for sysadmins to just rename master ->
master-kde4, and master-kf5 -> master?

Cheers,
Ivan


On Tue, Jan 16, 2018 at 9:20 AM, Pali Rohár  wrote:
> On Tuesday 16 January 2018 09:05:41 Alexander Semke wrote:
>>
>> On 16.01.2018 00:45, Pali Rohár wrote:
>> > Because it does not work.
>> >
>> > remote: Push declined - excessive notifications would be sent
>> > remote: Please file a KDE Sysadmin bug to continue
>> >
>> > Therefore I opened sysadmin ticket T7642 and I was told that I should
>> > discuss about it on kde-core-devel.
>> >
>> If I remember it correctly, we had this problem last year in LabPlot when we
>> decided to bring frameworks into master, too.
>> We then merged frameworks into master (no rebase) and pushed this merge to
>> remote. I think the history is still there in the sense
>> that I can see all those "KDE4Libs->KF5" changes done in the frameworks
>> branch when bringing master into frameworks, etc.
>>
>> Did you try already
>> 1. merge the current master to master-kf5 and finish all the porting stuff
>
> If you by "merge" means only git merge without git push, then this
> operation does nothing. Commit on top of master branch is also ancestor
> accessible from master-kf5.
>
>> 2. merge master-kf5 back into master
>
> See above, it does nothing. And git push (after git merge) is failing.
>
>> 3. check the history in master
>
> --
> Pali Rohár
> pali.ro...@gmail.com



-- 
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3  45DF C9C5 77AF 0A37 240A

Re: Rebase of kopete branch and push it to master

[Ben Cooksley]

Hi all,

I have now completed the merge from Pali's clone repository into the
'master' branch of the main Kopete repository.
Phabricator processing of all the commits has been completed without incident.

Pali, please revise the metadata accordingly in sysadmin/repo-metadata
(for i18n) and kde-build-metadata (for the CI and kdesrc-build users)
as soon as possible.

Regards,
Ben

Re: Rebase of kopete branch and push it to master

[Ben Cooksley]

On Fri, Jan 19, 2018 at 12:06 PM, Pali Rohár  wrote:
> On Thursday 18 January 2018 20:50:35 Ben Cooksley wrote:
>> Hi all,
>>
>> I have now completed the merge from Pali's clone repository into the
>> 'master' branch of the main Kopete repository.
>> Phabricator processing of all the commits has been completed without 
>> incident.
>
> Hi! Thank you very very much!
>
>> Pali, please revise the metadata accordingly in sysadmin/repo-metadata
>
> See quoted comments/questions below
>
> https://phabricator.kde.org/source/sysadmin-repo-metadata/browse/master/projects/kde/kdenetwork/kopete/metadata.yaml
>
>> description: 'h1. Kopete - The KDE Instant Messenger
>
> What does "h1." means? Looks like some wiki(?) syntax for heading. No
> idea if it should be there or not.

That is a leftover from when this data was generated from the
descriptions used by projects.kde.org, which ran Redmine/Chiliproject.
It means nothing to anything we run these days and should be cleaned up.

>
>> - displayname: "Pali Roh\xE1r"
>
> What is encoding of that YAML file? Is not UTF-8 supported?

The conversion tool we used was conservative in regards to handling
information and encoded everything that couldn't be represented in
Latin-1 I believe.
I've entered UTF-8 characters into other files, and they certainly
should be encoded in and support, UTF-8.

>
> Otherwise looks correct.
>
> https://phabricator.kde.org/source/sysadmin-repo-metadata/browse/master/projects/kde/kdenetwork/kopete/i18n.json
>
>> {"trunk": "master", "stable": "Applications/17.08", "stable_kf5": "none", 
>> "trunk_kf5": "none"}
>
> I do not fully understand content of this JSON file, but there is no
> KDE4 trunk version in repository anymore. master branch now points to
> trunk KF5 version and there is no 17.12 (stable) version.

Luigi has now updated this I believe.

>
>> (for i18n) and kde-build-metadata (for the CI and kdesrc-build users)
>
> It is https://phabricator.kde.org/source/kde-build-metadata/ right? What
> should I check there?

In that repository you need to check two things:

1) logical-module-structure, JSON formatted, which defines a series of
rules stating which branches are used by projects.
2) the dependency-data-* files, which contain the dependency
definition rules between KDE projects for each branch grouping.
Anything not defined in here won't be made available on the CI, and
this data is used by kdesrc-build to sequence the order of things to
build.

In regards to the dependency data, please note that there is a generic
wildcard rule at the very bottom which makes essentially all
Frameworks a dependency of anything in Applications, Extragear or
Playground so you don't need to declare a dependency on any Framework
you use.

Hope that clears things up.

Cheers,
Ben

>
>> as soon as possible.
>>
>> Regards,
>> Ben
>
> --
> Pali Rohár
> pali.ro...@gmail.com

Re: Rebase of kopete branch and push it to master

[Ben Cooksley]

On Tue, Jan 16, 2018 at 9:24 PM, Ivan Čukić  wrote:
> Hi all,

Hi Ivan (and others),

>
> Would it be possible for sysadmins to just rename master ->
> master-kde4, and master-kf5 -> master?

If master were merged into frameworks we could of course do such a
rename without too much fuss. The problem here is that Pali wants to
throw away the current frameworks branch and bring in the commits
which made it up, newly rebased on top of master, with the commits
which were reworked eliminated (ie. a 'pure' history).

The number of commits which get rebased as part of this, is naturally,
greater than 100 and was hence blocked by the server. This is not a
failure, it is the system operating as designed, and there are
numerous reasons why it is setup to do this.

>
> Cheers,
> Ivan

Cheers,
Ben

>
>
> On Tue, Jan 16, 2018 at 9:20 AM, Pali Rohár  wrote:
>> On Tuesday 16 January 2018 09:05:41 Alexander Semke wrote:
>>>
>>> On 16.01.2018 00:45, Pali Rohár wrote:
>>> > Because it does not work.
>>> >
>>> > remote: Push declined - excessive notifications would be sent
>>> > remote: Please file a KDE Sysadmin bug to continue
>>> >
>>> > Therefore I opened sysadmin ticket T7642 and I was told that I should
>>> > discuss about it on kde-core-devel.
>>> >
>>> If I remember it correctly, we had this problem last year in LabPlot when we
>>> decided to bring frameworks into master, too.
>>> We then merged frameworks into master (no rebase) and pushed this merge to
>>> remote. I think the history is still there in the sense
>>> that I can see all those "KDE4Libs->KF5" changes done in the frameworks
>>> branch when bringing master into frameworks, etc.
>>>
>>> Did you try already
>>> 1. merge the current master to master-kf5 and finish all the porting stuff
>>
>> If you by "merge" means only git merge without git push, then this
>> operation does nothing. Commit on top of master branch is also ancestor
>> accessible from master-kf5.
>>
>>> 2. merge master-kf5 back into master
>>
>> See above, it does nothing. And git push (after git merge) is failing.
>>
>>> 3. check the history in master
>>
>> --
>> Pali Rohár
>> pali.ro...@gmail.com
>
>
>
> --
> KDE, ivan.cu...@kde.org, http://cukic.co/
> gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3  45DF C9C5 77AF 0A37 240A

Re: Rebase of kopete branch and push it to master

[Ben Cooksley]

Hi all,

Given that we are in essentially a intractable stalemate here and i'd
rather spend energy elsewhere, i'm going to go ahead and allow this.

It's going to be fairly messy however and will have consequences which
impact all KDE projects when it happens.

Phabricator will have to process all these commits (which are new as
far as it is concerned), which will cause delays in commit
availability there for all projects. Without determining the full
number of rebased commits it won't be possible to tell how long this
will take i'm afraid. While Phabricator is reasonably efficient here
it could still easily take a few hours for it to process them, during
which time other projects commits may not be processed.

General performance of both Phabricator, along with both Git and
Subversion will likely also be impaired during this time period as a
consequence of this processing. Other systems should be mostly
unimpacted by this.

Given it is late for me now, I will action this tomorrow night (my
time). For the duration of the processing time, the Kopete repository
will be totally locked (all branches) against any changes, and I won't
be proceeding with the push if it clashes with an Applications module
release or freeze for which an exception has not been granted.

Regards,
Ben Cooksley
KDE Sysadmin