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 <pali.ro...@gmail.com> 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