Re: Rebase of kopete branch and push it to master
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
Re: Rebase of kopete branch and push it to master
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: Rebase of kopete branch and push it to master
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: Rebase of kopete branch and push it to master
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
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
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
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
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
Re: Rebase of kopete branch and push it to master
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?
> >
> > 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.
> 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?
> 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
signature.asc
Description: PGP signature
Re: Rebase of kopete branch and push it to master
Pali Rohár ha scritto:
> 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
>> [...]
>> {"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.
I fixed this (only trunk_kf5 points to master, the others are none) and moved
the translations to the proper i18n branch.
>
>> (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?
I updated logical-module-structure adding the new branch and removing the old
one. On the other side, dependency-data-kf5-qt5 contains only few dependencies
but they seems to be enough to compile on build.kde.org, at least for now,
maybe thanks to transitive dependencies.
Ciao
--
Luigi
Re: Rebase of kopete branch and push it to master
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.
> - displayname: "Pali Roh\xE1r"
What is encoding of that YAML file? Is not UTF-8 supported?
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.
> (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?
> as soon as possible.
>
> Regards,
> Ben
--
Pali Rohár
pali.ro...@gmail.com
Re: Rebase of kopete branch and push it to master
Pali Rohár ha scritto: > On Tuesday 16 January 2018 23:05:42 Albert Astals Cid wrote: >> El dimarts, 16 de gener de 2018, a les 0:45:27 CET, Pali Rohár va escriure: >>> On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote: El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va >> escriure: > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: >> So is the problem: >> a) that you could not push that master-kf5 to master > > Problem is really a). Why is that? You said master-kf5 is just a rebase of kf5 on top of master, what's the problem of pushing that branch? >>> >>> 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. >> >> Please someone correct me, but that has nothing to do with rebasing no? > > Let me explain it again. Under "rebase" I mean result of operation > git rebase. Under "push" I mean result of operation git push. > > I took branch kf5 from main kopete repository. Then I rebased it on top > of master and pushed to my personal cloned git repository into branch > master-kf5. > > Now I wanted to push this master-kf5 into branch master to main kopete > repository. And push failed. As explained by Ben, it is by design: a push like this is usually not what the developer wants, and only in rare cases it makes sense (usually an import, or when codes was shuffled around in the early times of Frameworks). > > Strictly speaking it git rebase --onto & git push. But with fact that it > does not use any force push (therefore no history overwrite). This is were the opinion differs. It is history rewriting for me: looking back at what happened in the KF5 port, people will see a big set of commits pushed on top of master, without understanding when some change happened in comparison to the others, because all the intermediate merges are lost. The information conveyed by two parallel branches with cross-merges is lost. I understand they wrote that it was ugly - but it was what happened. Something to not repeat, but now it is like this. This is just for reference; a decision has been made. -- Luigi
Re: Rebase of kopete branch and push it to master
On Tuesday 16 January 2018 23:05:42 Albert Astals Cid wrote: > El dimarts, 16 de gener de 2018, a les 0:45:27 CET, Pali Rohár va escriure: > > On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote: > > > El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va > escriure: > > > > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: > > > > > So is the problem: > > > > > a) that you could not push that master-kf5 to master > > > > > > > > Problem is really a). > > > > > > Why is that? You said master-kf5 is just a rebase of kf5 on top of master, > > > what's the problem of pushing that branch? > > > > 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. > > Please someone correct me, but that has nothing to do with rebasing no? Let me explain it again. Under "rebase" I mean result of operation git rebase. Under "push" I mean result of operation git push. I took branch kf5 from main kopete repository. Then I rebased it on top of master and pushed to my personal cloned git repository into branch master-kf5. Now I wanted to push this master-kf5 into branch master to main kopete repository. And push failed. Strictly speaking it git rebase --onto & git push. But with fact that it does not use any force push (therefore no history overwrite). > It's just about a big merge potentially triggering lots of emails and stuff, > no? There is no merge commit, in fact it is just fast forward. And yes it is a big. It is a more clear now? -- Pali Rohár pali.ro...@gmail.com
Re: Rebase of kopete branch and push it to master
El dimarts, 16 de gener de 2018, a les 21:56:34 CET, Ben Cooksley va escriure: > 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. kopete is not part of KDE Applications 17.12 since it didn't make it on time with a KF5-base version. So no problem on that side. Cheers, Albert > > Regards, > Ben Cooksley > KDE Sysadmin
Re: Rebase of kopete branch and push it to master
El dimarts, 16 de gener de 2018, a les 0:45:27 CET, Pali Rohár va escriure: > On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote: > > El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va escriure: > > > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: > > > > So is the problem: > > > > a) that you could not push that master-kf5 to master > > > > > > Problem is really a). > > > > Why is that? You said master-kf5 is just a rebase of kf5 on top of master, > > what's the problem of pushing that branch? > > 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. Please someone correct me, but that has nothing to do with rebasing no? It's just about a big merge potentially triggering lots of emails and stuff, no? Cheers, Albert
Re: Rebase of kopete branch and push it to master
On Tuesday 16 January 2018 09:24:56 Ivan Čukić wrote: > Would it be possible for sysadmins to just rename master -> > master-kde4, and master-kf5 -> master? I do not understand you. See my email in first post. master-kf5 is in my cloned repository, not in main one. So I do not understand how such renaming would help. -- Pali Rohár pali.ro...@gmail.com
Re: Rebase of kopete branch and push it to master
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
Re: Rebase of kopete branch and push it to master
On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote: > El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va escriure: > > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: > > > So is the problem: > > > a) that you could not push that master-kf5 to master > > > > Problem is really a). > > Why is that? You said master-kf5 is just a rebase of kf5 on top of master, > what's the problem of pushing that branch? 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. -- Pali Rohár pali.ro...@gmail.com
Re: Rebase of kopete branch and push it to master
El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va escriure: > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: > > So is the problem: > > a) that you could not push that master-kf5 to master > > Problem is really a). Why is that? You said master-kf5 is just a rebase of kf5 on top of master, what's the problem of pushing that branch? Cheers, Albert
Re: Rebase of kopete branch and push it to master
Pali Rohár ha scritto: > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: >> So is the problem: >> a) that you could not push that master-kf5 to master > > Problem is really a). > a) can't be changed. You can merge your rebased kf5 branch to master. I would still complain, because the rebase kf5 would have a messed-up history, but if it's fine for the other people, well... -- Luigi
Re: Rebase of kopete branch and push it to master
On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote: > So is the problem: > a) that you could not push that master-kf5 to master Problem is really a). -- Pali Rohár pali.ro...@gmail.com
Re: Rebase of kopete branch and push it to master
El dilluns, 15 de gener de 2018, a les 9:50:11 CET, Pali Rohár va escriure: > On Sunday 14 January 2018 23:59:45 Albert Astals Cid wrote: > > El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va escriure: > > > Hi! > > > > Hello Mr Rohár > > > > > From the following ticket https://phabricator.kde.org/T7642 I was > > > suggested to open discussion on kde-core-devel list. Sending this email > > > also to kopete-devel as it is relevant for Kopete development. > > > > > > Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a > > > branch kf5 which contains port of Kopete to KF5. That branch was created > > > 3 years ago as part of GSoC was used as "staging area". Some patches > > > there are incomplete and later were "fixed & cherry-picked" into master > > > branch. Therefore you can find commits with same description/commit > > > message in master branch and kf5, but correct (working) one is in > > > master. Later this branch was used for pushing whole work of porting. > > > > > > I took commits from this branch kf5 and rebased it on top of master with > > > cleanup of duplicate commits and commits which are already in master > > > branch. And this rebase I pushed into my cloned git repository > > > https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5 > > > > > > I wanted to push these master-kf5 changes into main kopete repository > > > into master branch, but it was rejected by commits hook, see above T7642 > > > ticket. > > > > No, we can't read private sysadmin tickets. > > > > > Reason is that "rebase" is not supported by KDE. ltoscano and > > > bcooksley suggested to discuss about it on kde-core-devel. > > > > > > From my side as that branch kf5 contains duplicate commits as in master > > > branch and commits with same commit messages and different (old) patches > > > I really do not like see these commits in master branch. It would break > > > certain of git functionality (like bisect or blame, or log). And because > > > it was mean as a staging area, I would really like to use that rebase > > > for this time. I do not thing that there are advantage to merge this kf5 > > > branch as is into master and better would be rebase. > > > > > > Is there anything really against rebasing this one particular branch? > > > > Yes, you have not explained why you need rebasing. > > I already wrote it. I do not want to see one commit in git history > accessible from master branch two times. Or git commits with same commit > message / same description, but with different content. That's not really a big problem is it? Like you wrote it seemed that if you were unable to rebase things would be terribly broken or something. > > > Just merge master-kf5 into master. > > > > master as it is right now works, no? > > Yes, but depends on KDE4. > > > (or i hope it should, we agreed long time > > ago to not break master), so just merge the "kf5 clean branch" into it and > > that's it, no? > > > > > For future (to prevent any such problem with rebasing), staging areas > > > would be outside of main KDE git repository. > > > > How would that fix anything? You will still not be able to rebase master. > > But I never wanted such thing, nor I want in the future. I am really lost then, you don't want to rebase master, but you wrote an email saying you needed to rebase the master branch, no? If not then i misunderstood your problem. > > Or you're saying that you want to rebase your work branches? > > Yes, take branch kf5, locally rebase it (on top of master) and then push > changes to remote master. As already wrote, I did it and pushed this > rebased branch into my cloned git repository under branch name > master-kf5. So is the problem: a) that you could not push that master-kf5 to master or b) that you could not push that master-kf5 to kf5 or c) something else and Albert is still lost ? Cheers, Albert
Re: Rebase of kopete branch and push it to master
On Sunday 14 January 2018 23:59:45 Albert Astals Cid wrote: > El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va escriure: > > Hi! > > Hello Mr Rohár > > > > > From the following ticket https://phabricator.kde.org/T7642 I was > > suggested to open discussion on kde-core-devel list. Sending this email > > also to kopete-devel as it is relevant for Kopete development. > > > > Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a > > branch kf5 which contains port of Kopete to KF5. That branch was created > > 3 years ago as part of GSoC was used as "staging area". Some patches > > there are incomplete and later were "fixed & cherry-picked" into master > > branch. Therefore you can find commits with same description/commit > > message in master branch and kf5, but correct (working) one is in > > master. Later this branch was used for pushing whole work of porting. > > > > I took commits from this branch kf5 and rebased it on top of master with > > cleanup of duplicate commits and commits which are already in master > > branch. And this rebase I pushed into my cloned git repository > > https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5 > > > > I wanted to push these master-kf5 changes into main kopete repository > > into master branch, but it was rejected by commits hook, see above T7642 > > ticket. > > No, we can't read private sysadmin tickets. > > > Reason is that "rebase" is not supported by KDE. ltoscano and > > bcooksley suggested to discuss about it on kde-core-devel. > > > > From my side as that branch kf5 contains duplicate commits as in master > > branch and commits with same commit messages and different (old) patches > > I really do not like see these commits in master branch. It would break > > certain of git functionality (like bisect or blame, or log). And because > > it was mean as a staging area, I would really like to use that rebase > > for this time. I do not thing that there are advantage to merge this kf5 > > branch as is into master and better would be rebase. > > > > Is there anything really against rebasing this one particular branch? > > Yes, you have not explained why you need rebasing. I already wrote it. I do not want to see one commit in git history accessible from master branch two times. Or git commits with same commit message / same description, but with different content. > Just merge master-kf5 into master. > > master as it is right now works, no? Yes, but depends on KDE4. > (or i hope it should, we agreed long time > ago to not break master), so just merge the "kf5 clean branch" into it and > that's it, no? > > > For future (to prevent any such problem with rebasing), staging areas > > would be outside of main KDE git repository. > > How would that fix anything? You will still not be able to rebase master. But I never wanted such thing, nor I want in the future. > Or you're saying that you want to rebase your work branches? Yes, take branch kf5, locally rebase it (on top of master) and then push changes to remote master. As already wrote, I did it and pushed this rebased branch into my cloned git repository under branch name master-kf5. > > But for now I would like to have finally KF5 port in master branch. > > > > I'm very disappointed by KDE as I'm periodically hitting technical > > problems with KDE infrastructure which makes maintaining of Kopete > > application just harder. > > Now that you mention it, I'm very disappointed that you never answered my > answer to your email > https://mail.kde.org/pipermail/release-team/2017-November/010714.html > > > (Problems like git push is not reflected to > > annongit servers, git push hooks are failing because of dns server > > errors and now git push failed because rebase is not supported). When I > > compare it with other servers (like Launchpad, Github or old Gitorious) > > I never hit any problem on them (yet). > > I've never hit any of the problems you mention with KDE servers either. > > Best Regards, > Albert > > > > > I'm not subscribed to kde-core-devel, so please CC me on reply. > > -- Pali Rohár pali.ro...@gmail.com
Re: Rebase of kopete branch and push it to master
El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va escriure: > Hi! Hello Mr Rohár > > From the following ticket https://phabricator.kde.org/T7642 I was > suggested to open discussion on kde-core-devel list. Sending this email > also to kopete-devel as it is relevant for Kopete development. > > Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a > branch kf5 which contains port of Kopete to KF5. That branch was created > 3 years ago as part of GSoC was used as "staging area". Some patches > there are incomplete and later were "fixed & cherry-picked" into master > branch. Therefore you can find commits with same description/commit > message in master branch and kf5, but correct (working) one is in > master. Later this branch was used for pushing whole work of porting. > > I took commits from this branch kf5 and rebased it on top of master with > cleanup of duplicate commits and commits which are already in master > branch. And this rebase I pushed into my cloned git repository > https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5 > > I wanted to push these master-kf5 changes into main kopete repository > into master branch, but it was rejected by commits hook, see above T7642 > ticket. No, we can't read private sysadmin tickets. > Reason is that "rebase" is not supported by KDE. ltoscano and > bcooksley suggested to discuss about it on kde-core-devel. > > From my side as that branch kf5 contains duplicate commits as in master > branch and commits with same commit messages and different (old) patches > I really do not like see these commits in master branch. It would break > certain of git functionality (like bisect or blame, or log). And because > it was mean as a staging area, I would really like to use that rebase > for this time. I do not thing that there are advantage to merge this kf5 > branch as is into master and better would be rebase. > > Is there anything really against rebasing this one particular branch? Yes, you have not explained why you need rebasing. Just merge master-kf5 into master. master as it is right now works, no? (or i hope it should, we agreed long time ago to not break master), so just merge the "kf5 clean branch" into it and that's it, no? > For future (to prevent any such problem with rebasing), staging areas > would be outside of main KDE git repository. How would that fix anything? You will still not be able to rebase master. Or you're saying that you want to rebase your work branches? > But for now I would like to have finally KF5 port in master branch. > > I'm very disappointed by KDE as I'm periodically hitting technical > problems with KDE infrastructure which makes maintaining of Kopete > application just harder. Now that you mention it, I'm very disappointed that you never answered my answer to your email https://mail.kde.org/pipermail/release-team/2017-November/010714.html > (Problems like git push is not reflected to > annongit servers, git push hooks are failing because of dns server > errors and now git push failed because rebase is not supported). When I > compare it with other servers (like Launchpad, Github or old Gitorious) > I never hit any problem on them (yet). I've never hit any of the problems you mention with KDE servers either. Best Regards, Albert > > I'm not subscribed to kde-core-devel, so please CC me on reply.
