Re: Proposal for branching policy towards KF5
Le mercredi 24 juillet 2013 23:05:55 Michael Pyne a écrit : On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. First note: There's a lot of different mailing lists with at least some interest in this discussion, so I've mailed them all for informational purposes... but let's keep the discussion limited to the kde-core-devel mailing list! Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. I didn't want to write another parser, but JSON has no native comment support, so the documentation [1] is on community.kde.org (though perhaps that's for the best). Slightly off-topic: I probably arrive a bit late, but have you considered using YAML instead of JSON? YAML is as light to write (if not lighter) than JSON, widespread enough to have parsers in many languages and does support comments. Aurélien
Re: Proposal for branching policy towards KF5
On Mon, July 29, 2013 22:09:38 Aurélien Gâteau wrote: Le mercredi 24 juillet 2013 23:05:55 Michael Pyne a écrit : I didn't want to write another parser, but JSON has no native comment support, so the documentation [1] is on community.kde.org (though perhaps that's for the best). Slightly off-topic: I probably arrive a bit late, but have you considered using YAML instead of JSON? YAML is as light to write (if not lighter) than JSON, widespread enough to have parsers in many languages and does support comments. I won't claim to have seriously considered it, but it seems we're using JSON elsewhere already, and Python at least appears to support it by default on all of the hosts where JSON may be necessary (e.g. l10n servers, build.kde.org, etc.). The logic of the existing scripts is not very tied to the data interchange format so it's not like migrating to YAML would be traumatic at this point, but I don't think comments alone would warrant switching either now that we have some small amount of code supporting it. And also, who wants to have to worry about code execution when you're just trying to parse a data interchange format? ;) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
On Friday 26 July 2013 23.53.07 Michael Pyne wrote: On Fri, July 26, 2013 21:11:21 Torgny Nyblom wrote: On Thursday 25 July 2013 18.24.50 Michael Pyne wrote: The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Wouldn't this be nice to have as the source of branch info for the releases? One place to have this information instead of duplicate it for each tool/user? I think I see what you're talking about, but the release team essentially just make their own branch already, make their tags, that's it. Things are generally not tagged directly from master or any other development branch. Not quite :), when we make a release the tags are put on the release branch, i.e. KDE/4.10 for the last stable release. The release branch/tag is a thing of the past that was used in the SVN days. The only release team only thing is that we keep a list of modules/branches that we should tag modules from. Since this will be the same as the stable branch I see no reason why we should hide this information in the release tools repo. /Regards Torgny
Re: Proposal for branching policy towards KF5
El Diumenge, 28 de juliol de 2013, a les 11:33:58, Torgny Nyblom va escriure: On Friday 26 July 2013 23.53.07 Michael Pyne wrote: On Fri, July 26, 2013 21:11:21 Torgny Nyblom wrote: On Thursday 25 July 2013 18.24.50 Michael Pyne wrote: The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Wouldn't this be nice to have as the source of branch info for the releases? One place to have this information instead of duplicate it for each tool/user? I think I see what you're talking about, but the release team essentially just make their own branch already, make their tags, that's it. Things are generally not tagged directly from master or any other development branch. Not quite :), when we make a release the tags are put on the release branch, i.e. KDE/4.10 for the last stable release. The release branch/tag is a thing of the past that was used in the SVN days. The only release team only thing is that we keep a list of modules/branches that we should tag modules from. Since this will be the same as the stable branch I see no reason why we should hide this information in the release tools repo. I see your point, and kind of agree that it may be useful, but i see two issues: * Right now, only me and you (afaik) commit to the release-tools repo, so I don't have to care about people vandalizing the release info in purpose or by mistake * There's moments like a few weeks ago where the l10n stable branch points to KDE/4.11 and l10n unstable to master, but release-wise and code- wise I am not sure we should like to give 4.11 to people asking for a stable code branch since the .0 is still unreleased Anyway if you think it's worth it, i'm not against exploring such solution :-) Cheers, Albert /Regards Torgny
Re: Proposal for branching policy towards KF5
On Thursday 25 July 2013 18.24.50 Michael Pyne wrote: On Thu, July 25, 2013 22:44:47 Albert Astals Cid wrote: El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va escriure: On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. snip A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long ago we had to write support for the projects.kde.org branches thing when we already had our nice set of scripts and now you say we'll have to build support for something different? It's good that we never removed our internal scripts and they are the authoritative source, that way removing the projects.kde.org support is trivial :D [/I18N_HAT] Well it would certainly be possible to *keep* support for whatever you're doing now with projects.kde.org, that isn't going away at this point. But since the concept is complementary, it would make sense to try to end up on one solution. At least this way it should be easier to fixup the branches for groups of modules at a time! ;) I'm not familiar with the i18n scripts at this point but I would volunteer to help with any needed porting. At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. You mean something like kde-build-metadata? Neither i18n nor releasing uses that file. Kind of (dependency data is one part of kde-build-metadata). It is true that neither requires dependency info. In the event, some prototyping of the result of making *all* of our deps go in the file is rather unsatisfactory so I'll be dropping that for now (the hard work is already done in case we decide to investigate later though). Basically from release I don't see how that affects us, we use the data from the release-tools module that is de-coupled from what you mention, no? dependency-data would not affect you at all. The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Wouldn't this be nice to have as the source of branch info for the releases? One place to have this information instead of duplicate it for each tool/user? /Regards Torgny Regards, - Michael Pyne
Re: Proposal for branching policy towards KF5
On Fri, July 26, 2013 21:11:21 Torgny Nyblom wrote: On Thursday 25 July 2013 18.24.50 Michael Pyne wrote: The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Wouldn't this be nice to have as the source of branch info for the releases? One place to have this information instead of duplicate it for each tool/user? I think I see what you're talking about, but the release team essentially just make their own branch already, make their tags, that's it. Things are generally not tagged directly from master or any other development branch. It's true that our proposed 'stable-qt4' branch would generally be hooked up to a release branch, so there's no theoretical reason why we couldn't later add released branches for the SC/Platform/*Desktop. But I think it would be easier to use sane and consistent branch naming policy for release purposes, with any exceptions clearly known. Even with kde-workspace, there's no technical reason I can see why we can't have both KDE/4.11 and KDE/4.12 (when we get to that point) pointed to the same commit once we're in LTS mode on that, if we're worried about people just trying to checkout KDE/4.12 for everything. Are there tools that have to maintain this data for themselves though? I do agree with the idea of centralizing it so if that's an issue I say let's see what the impl would look like and see if that works out. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
On Wednesday 24 July 2013 10:23:46 Michael Pyne wrote: On Tue, July 23, 2013 14:20:39 David Faure wrote: On Saturday 20 July 2013 23:04:10 Michael Pyne wrote: This is a labor-intensive task, but it's easy to centrally-manage without having to rely on many different module maintainers or core developers for each git repository to update their own metadata in projects.kde.org I volunteer to help. (assuming we can get the sysadmins to add that). I didn't understand that. To add what? To add a scheme within the projects.kde.org repository administration interface for each individual repo administrator to fill out which branch is appropriate for each of our 3 overarching development tracks. They would then need to add something to export that information back into the XML database. Similar concerns about how this could even realistically work were what lead me to making the kde-build-metadata repository in the first place; it's a lot easier just to have a single spot for that metadata which anyone can update, not just a repo admin or sysadmin. Yes, definitely. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va escriure: On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. First note: There's a lot of different mailing lists with at least some interest in this discussion, so I've mailed them all for informational purposes... but let's keep the discussion limited to the kde-core-devel mailing list! Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. I didn't want to write another parser, but JSON has no native comment support, so the documentation [1] is on community.kde.org (though perhaps that's for the best). For those with no clue what I'm talking about, the original thread from kde- core-devel is available from [2]. A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long ago we had to write support for the projects.kde.org branches thing when we already had our nice set of scripts and now you say we'll have to build support for something different? It's good that we never removed our internal scripts and they are the authoritative source, that way removing the projects.kde.org support is trivial :D [/I18N_HAT] At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. You mean something like kde-build-metadata? Neither i18n nor releasing uses that file. Basically from release I don't see how that affects us, we use the data from the release-tools module that is de-coupled from what you mention, no? Cheers, Albert I put the effort into doing this as it would also help make the implementation of some kdesrc-build misfeatures relating to dependency-data additions a bit easier, as there's no need to construct an AST and a parser. Additionally it would permit 'soft' dependencies, which are useful for modules that can utilize optional features but don't have required dependencies on other git modules. However that can, and probably should, be considered separately (though I'll take comments now, if you have them). [1]: http://community.kde.org/Infrastructure/Project_Metadata [2]: http://markmail.org/message/4l3yqerga7mfiit5 Anyways, thanks for your interest and please let me know if this will work to solve the problem at hand. If so I will start on integrating within kdesrc- build, and working with the sysadmins to support within the continuous integration infrastructure. Regards, - Michael Pyne
Re: Proposal for branching policy towards KF5
On Thu, July 25, 2013 22:44:47 Albert Astals Cid wrote: El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va escriure: On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. snip A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long ago we had to write support for the projects.kde.org branches thing when we already had our nice set of scripts and now you say we'll have to build support for something different? It's good that we never removed our internal scripts and they are the authoritative source, that way removing the projects.kde.org support is trivial :D [/I18N_HAT] Well it would certainly be possible to *keep* support for whatever you're doing now with projects.kde.org, that isn't going away at this point. But since the concept is complementary, it would make sense to try to end up on one solution. At least this way it should be easier to fixup the branches for groups of modules at a time! ;) I'm not familiar with the i18n scripts at this point but I would volunteer to help with any needed porting. At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. You mean something like kde-build-metadata? Neither i18n nor releasing uses that file. Kind of (dependency data is one part of kde-build-metadata). It is true that neither requires dependency info. In the event, some prototyping of the result of making *all* of our deps go in the file is rather unsatisfactory so I'll be dropping that for now (the hard work is already done in case we decide to investigate later though). Basically from release I don't see how that affects us, we use the data from the release-tools module that is de-coupled from what you mention, no? dependency-data would not affect you at all. The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. First note: There's a lot of different mailing lists with at least some interest in this discussion, so I've mailed them all for informational purposes... but let's keep the discussion limited to the kde-core-devel mailing list! Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. I didn't want to write another parser, but JSON has no native comment support, so the documentation [1] is on community.kde.org (though perhaps that's for the best). For those with no clue what I'm talking about, the original thread from kde- core-devel is available from [2]. A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. I put the effort into doing this as it would also help make the implementation of some kdesrc-build misfeatures relating to dependency-data additions a bit easier, as there's no need to construct an AST and a parser. Additionally it would permit 'soft' dependencies, which are useful for modules that can utilize optional features but don't have required dependencies on other git modules. However that can, and probably should, be considered separately (though I'll take comments now, if you have them). [1]: http://community.kde.org/Infrastructure/Project_Metadata [2]: http://markmail.org/message/4l3yqerga7mfiit5 Anyways, thanks for your interest and please let me know if this will work to solve the problem at hand. If so I will start on integrating within kdesrc- build, and working with the sysadmins to support within the continuous integration infrastructure. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
On Sonntag, 21. Juli 2013 05:04:10 CEST, Michael Pyne wrote: On Fri, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. ... implementation Michael: I see two ways this could be done in kdesrc-build. Either with the selection layers being defined by the projects XML and some additional magic in branch selection to allow for these new names, or with a much more low-tech solution: 3 available files to include from kdesrc-buildrc, like ... Well there's a 3rd method as well, which is to add a separate metadata file to the kde-build-metadata repository which maps each git repository to its appropriate branch for each of the 3 categories. git symbolic-ref refs/heads/NEXT refs/heads/master or for workspace/libs git symbolic-ref refs/heads/NEXT refs/heads/KDE/4.11 eventually also git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.11 and then at some point git symbolic-ref --delete refs/heads/CURRENT git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.12 But i don't know how this will exactly behave on remote/local conditions (ie. whether you get a local symref if the remote is one) Cheers, Thomas
Re: Proposal for branching policy towards KF5
On Sun, Jul 21, 2013 at 9:13 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: On Sonntag, 21. Juli 2013 05:04:10 CEST, Michael Pyne wrote: On Fri, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. ... implementation Michael: I see two ways this could be done in kdesrc-build. Either with the selection layers being defined by the projects XML and some additional magic in branch selection to allow for these new names, or with a much more low-tech solution: 3 available files to include from kdesrc-buildrc, like ... Well there's a 3rd method as well, which is to add a separate metadata file to the kde-build-metadata repository which maps each git repository to its appropriate branch for each of the 3 categories. git symbolic-ref refs/heads/NEXT refs/heads/master or for workspace/libs git symbolic-ref refs/heads/NEXT refs/heads/KDE/4.11 eventually also git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.11 and then at some point git symbolic-ref --delete refs/heads/CURRENT git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.12 It would appear that git remote update does not handle symbolic refs at all (at least it does not handle HEAD) so that will require manual updates on both the main Git server and then each anongit node - for each change we make. But i don't know how this will exactly behave on remote/local conditions (ie. whether you get a local symref if the remote is one) Cheers, Thomas Thanks, Ben
Re: Proposal for branching policy towards KF5
On Sonntag, 21. Juli 2013 11:15:29 CEST, Ben Cooksley wrote: On Sun, Jul 21, 2013 at 9:13 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: On Sonntag, 21. Juli 2013 05:04:10 CEST, Michael Pyne wrote: On Fri, July 19, 2013 00:21:21 David Faure wrote: ... git symbolic-ref refs/heads/NEXT refs/heads/master or for workspace/libs git symbolic-ref refs/heads/NEXT refs/heads/KDE/4.11 eventually also git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.11 and then at some point git symbolic-ref --delete refs/heads/CURRENT git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.12 It would appear that git remote update does not handle symbolic refs at all (at least it does not handle HEAD) Tried recently? HEAD used to be a symbolic link rather than a symbolic-ref; Technically, the symbolic ref is (now) just a ref that instead $ cat .git/refs/heads/master 65dd83dfb5593eebaec44b71925c15cee5955e9a contains $ cat .git/refs/heads/NEXT ref: refs/heads/master Not sure why it would not be passed around like any other ref - but i really don't know ;-) Norm! Thomas
Re: Proposal for branching policy towards KF5
On Sun, Jul 21, 2013 at 9:54 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: On Sonntag, 21. Juli 2013 11:15:29 CEST, Ben Cooksley wrote: On Sun, Jul 21, 2013 at 9:13 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: On Sonntag, 21. Juli 2013 05:04:10 CEST, Michael Pyne wrote: On Fri, July 19, 2013 00:21:21 David Faure wrote: ... git symbolic-ref refs/heads/NEXT refs/heads/master or for workspace/libs git symbolic-ref refs/heads/NEXT refs/heads/KDE/4.11 eventually also git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.11 and then at some point git symbolic-ref --delete refs/heads/CURRENT git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.12 It would appear that git remote update does not handle symbolic refs at all (at least it does not handle HEAD) Tried recently? HEAD used to be a symbolic link rather than a symbolic-ref; Technically, the symbolic ref is (now) just a ref that instead Yes, I ran into this problem recently because a couple of Qt 5 modules changed their HEAD. This broke our mirrored copies of Qt. $ cat .git/refs/heads/master 65dd83dfb5593eebaec44b71925c15cee5955e9a contains $ cat .git/refs/heads/NEXT ref: refs/heads/master Not sure why it would not be passed around like any other ref - but i really don't know ;-) It is passed around on the initial git clone --mirror but it is not subsequently updated unfortunately - unless there is a different command other than git remote update -p to run - If there is I would definitely like to know about it. Norm! Thomas Thanks, Ben
Re: Proposal for branching policy towards KF5
On Saturday, July 20, 2013 10:10:11 David Faure wrote: On Saturday 20 July 2013 13:28:47 Ben Cooksley wrote: I'd also be inclined to think of kde-runtime as part of kdelibs, rather than the workspace Yes, that is very true. Especially since the plan for most of kde-runtime is to fold it into the relevant frameworks, IIRC. The Plasma bits from kde-runtime have already moved, so at least there, it's not an issue. This will crop up again afterwards, however. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Proposal for branching policy towards KF5
On Fri, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. I see this as kind of layer on top of the actual branch names (an indirection, in other words). This gives us consistency for everyone: * for contributors to a specific module, master is where new features should go * for people who compile many modules that are supposed to be working together, a logical selection layer can be selected, stable, latest-qt4, or qt5-kf5. implementation Michael: I see two ways this could be done in kdesrc-build. Either with the selection layers being defined by the projects XML and some additional magic in branch selection to allow for these new names, or with a much more low-tech solution: 3 available files to include from kdesrc-buildrc, like we did with kf5-qt5-build-include, except that these files would only contain module- options (yet another reason for that feature to exist), not actual module definitions. The user's kdesrc-buildrc would still define which module he/she wants to build, but the included file would define which branch should be used for each module (unless overriden, of course). /implementation Well there's a 3rd method as well, which is to add a separate metadata file to the kde-build-metadata repository which maps each git repository to its appropriate branch for each of the 3 categories. This is a labor-intensive task, but it's easy to centrally-manage without having to rely on many different module maintainers or core developers for each git repository to update their own metadata in projects.kde.org (assuming we can get the sysadmins to add that). In addition this would probably be easier to support for build.kde.org and the other non-kdesrc-build tools that use the current information in kde-build- metadata. We could probably significantly reduce the labor involved in maintenance by setting up defaults and then only specifying exceptions from the rule. The question will be how to group modules together. This is definitely something that would need discussion with the sysadmins and Release Team to hash out the details and any process changes that might need to happen too (e.g. adding a tool to verify all modules in kde/* are actually described for each of the 3 categories and running before a release to make sure new modules are not inadvertently left out of the metadata). I think we're getting to the point where it would be a good idea to document the metadata on our TechBase as well instead of just a README embedded within the directory. By a strange coincidence I happen to be on vacation leave so I will try to be online to discuss on IRC, but failing that we can setup a separate thread on the relevant mailing lists to hash out details. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
On Friday 19 July 2013 01:39:47 Michael Jansen wrote: On Friday, July 19, 2013 12:21:21 AM David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. I would like to mention that this is only a solution for scripts. It does not keep consistency for humans and all scripts outside of kde. And consistency is normally only needed for humans. could we please stop the bike shedding in this thread? Thank, you. It is impossible to find a solution which fits everybody's workflow. All I can say to breaking a workflow is http://xkcd.com/1172 Cheers Martin
Re: Proposal for branching policy towards KF5
On Friday, July 19, 2013 01:39:47 Michael Jansen wrote: I would like to mention that this is only a solution for scripts. It does not keep consistency for humans and all scripts outside of kde. And consistency is normally only needed for humans. As Martin noted, it’s not possible to keep every single workflow 100% in place when we are experiencing changes in development. For instance: the consistent place for merging features into 'next' is master (previously: trunk); and the consistent place for bugfixes is in the stable branch. The proposals that attempted to make things better for people building from master changed that around so that master is not for features and mainline moves to some other branch. That is a loss of consistency in our most important workflow: development. Yes, something will end up changing. We are optimizing this change in kde- workspace for development practices. We’ll keep careful track of well it works and then be able to apply that experience (positive or negative) to other modules in the future. In our discussion the other day, we defined some metrics we will be watching to measure success by. We are also paying attention to the needs of those who do build from master and will work on improving the tooling to minimize the disruption for people who build from git master. For those who don’t use that tooling, we’realso going to ensure that there are clear error messages when someone builds master against a 4.x environment telling them what’s going on and which branch they should be using. Note that this “master means different things in different modules” issue is unnavoidable at some point: unless we wait for every single application (including in extragear) to port to Qt5/Frameworks5 before making master Qt5 based modules that are already ported, there will be differences between the modules as to what is in master. The work we do in kde-workspace to make this as easy as we can for people who build from master can be applied to these future situations as well. Those who build from tarballs or from the stable branches aren’t affected by this, so the challenges are thankfully limited. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Proposal for branching policy towards KF5
On Friday, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : [...] (*) kde-workspace, plasma-frameworks, please complete this list if there are more. The following also belong into the workspace category: * kdeplasma-addons * declarative-plasmoids * kde-runtime These ones I'm unsure about: * kdebase-artwork * kde-wallpapers * kmix * kscreen * libkscreen * bluedevil * libbluedevil * bluedevil * activitymanager * *libdbusmenu-qt (special case, since it comes from launchpad / bazaar) * lightdm-kde * nepomuk-core * nepomuk-widgets * share-like-connect * networkmanagement (+libs, need to ask Lamarque which repos those are exactly) I'll dig a bit deeper to make sure we're complete. Sidenote: It's interesting to look at the rapture lines between apps and workspace. :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Proposal for branching policy towards KF5
On Friday 19 July 2013 17:42:14 Sebastian Kügler wrote: On Friday, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : [...] (*) kde-workspace, plasma-frameworks, please complete this list if there are more. The following also belong into the workspace category: * kdeplasma-addons * declarative-plasmoids * kde-runtime These ones I'm unsure about: * kdebase-artwork * kde-wallpapers * kmix * kscreen * libkscreen * bluedevil * libbluedevil * bluedevil * activitymanager * *libdbusmenu-qt (special case, since it comes from launchpad / bazaar) * lightdm-kde * nepomuk-core * nepomuk-widgets * share-like-connect * networkmanagement (+libs, need to ask Lamarque which repos those are exactly) networkmanagement repository is deprecated. Now we have libmm-qt, libnm-qt and plasma-nm repos. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Proposal for branching policy towards KF5
On Sat, Jul 20, 2013 at 3:42 AM, Sebastian Kügler se...@kde.org wrote: On Friday, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : [...] (*) kde-workspace, plasma-frameworks, please complete this list if there are more. The following also belong into the workspace category: * kdeplasma-addons * declarative-plasmoids * kde-runtime If you use the master branch of kde-runtime for frameworks development, this will pose major issues for the CI system. It relies on kdelibs and kde-runtime using the same branch naming scheme to include kde-runtime in the test environment for anything that depends on kdelibs. I'd also be inclined to think of kde-runtime as part of kdelibs, rather than the workspace - especially considering many distributions kdelibs packages depend in some manner on kde-runtime. These ones I'm unsure about: * kdebase-artwork * kde-wallpapers * kmix * kscreen * libkscreen * bluedevil * libbluedevil * bluedevil * activitymanager * *libdbusmenu-qt (special case, since it comes from launchpad / bazaar) * lightdm-kde * nepomuk-core * nepomuk-widgets * share-like-connect * networkmanagement (+libs, need to ask Lamarque which repos those are exactly) I'll dig a bit deeper to make sure we're complete. Sidenote: It's interesting to look at the rapture lines between apps and workspace. :) Cheers, -- sebas Regards, Ben http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Proposal for branching policy towards KF5
Hi all, especially workspace and frameworks hackers, Based on our earlier discussion, I'd like to propose the following strategy as a general way to move kde-workspace and related modules (such as kdeplasma- adddons, etc.) to KF5 gradually: - master stays on 4.11, receives bugfixes, our releases are based on this branch and their version number will stay 4.11 - KDE/4.11 gets regular merges from master to avoid mistakes when people use it instead of master - We create a branch called frameworks and use that for Frameworks development. It depends on Qt5 and KF5 - master is being merged into frameworks regularly (we have multiple volunteers for that( This keeps the consistency across modules. Whoever wants a Qt4-based build that works for daily usage builds master - no change there. Whoever builds atop KF5/Qt5 builds from frameworks branch. We use frameworks as branch name for this across all modules that we move - nobody has to check which branch in a given module has the actual frameworks build. We can apply this same policy to other modules that we make work atop KF5. Having a branching policy for those makes it easier to parallelize development further. In order to prevent confusion, we can merge master into 4.11 regularly, since there will not be any non-bugfix commits in there anyway. This merge will be trivial to do. We merge master into frameworks regularly to not lose bugfixes for PW2. I've gone through the email thread, and it's my understanding that this would satisfy our needs. I might have missed something, so: Does this work for everybody? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Proposal for branching policy towards KF5
On Thursday 18 July 2013 10:26:06 Sebastian Kügler wrote: - master stays on 4.11, receives bugfixes, our releases are based on this branch and their version number will stay 4.11 how do we prevent that people commit features into master? I would prefer if we lock down master in gitolite so that only module admins can commit to it. This would mean that bugfixes needs to be done in the branch? Cheers Martin
Re: Proposal for branching policy towards KF5
Martin Graesslin wrote: how do we prevent that people commit features into master? I would prefer To be honest, I haven't really seen people commit features into kdelibs, and that's been frozen for a while. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: Proposal for branching policy towards KF5
After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. I see this as kind of layer on top of the actual branch names (an indirection, in other words). This gives us consistency for everyone: * for contributors to a specific module, master is where new features should go * for people who compile many modules that are supposed to be working together, a logical selection layer can be selected, stable, latest-qt4, or qt5-kf5. What's not consistent is that kdelibs uses a different scheme for now, but if the workspace workflow experiment shows to be a success, which also means the tools work well with that, we can switch kdelibs to the same solution later. (and the apps even later). implementation Michael: I see two ways this could be done in kdesrc-build. Either with the selection layers being defined by the projects XML and some additional magic in branch selection to allow for these new names, or with a much more low-tech solution: 3 available files to include from kdesrc-buildrc, like we did with kf5-qt5-build-include, except that these files would only contain module- options (yet another reason for that feature to exist), not actual module definitions. The user's kdesrc-buildrc would still define which module he/she wants to build, but the included file would define which branch should be used for each module (unless overriden, of course). /implementation At this point I think this still needs a green light from the release team, though. To be clear: this means no kde-workspace 4.12, only 4.11.x with increasing values of x. Maintainance mode, much like KDE 3.5.x went. If everything works ok, we could switch kdelibs to that too, as was originally the plan. (*) kde-workspace, plasma-frameworks, please complete this list if there are more. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
Re: Proposal for branching policy towards KF5
On Friday, July 19, 2013 12:21:21 AM David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. I would like to mention that this is only a solution for scripts. It does not keep consistency for humans and all scripts outside of kde. And consistency is normally only needed for humans. Mike
Re: Proposal for branching policy towards KF5
El Divendres, 19 de juliol de 2013, a les 00:21:21, David Faure va escriure: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. I see this as kind of layer on top of the actual branch names (an indirection, in other words). This gives us consistency for everyone: * for contributors to a specific module, master is where new features should go * for people who compile many modules that are supposed to be working together, a logical selection layer can be selected, stable, latest-qt4, or qt5-kf5. What's not consistent is that kdelibs uses a different scheme for now, but if the workspace workflow experiment shows to be a success, which also means the tools work well with that, we can switch kdelibs to the same solution later. (and the apps even later). implementation Michael: I see two ways this could be done in kdesrc-build. Either with the selection layers being defined by the projects XML and some additional magic in branch selection to allow for these new names, or with a much more low-tech solution: 3 available files to include from kdesrc-buildrc, like we did with kf5-qt5-build-include, except that these files would only contain module- options (yet another reason for that feature to exist), not actual module definitions. The user's kdesrc-buildrc would still define which module he/she wants to build, but the included file would define which branch should be used for each module (unless overriden, of course). /implementation At this point I think this still needs a green light from the release team, though. From a creating tarballs perspective, it is not a problem (it may need some adapting to our scripts but it won't be more work than creating the fake fat tarballs from all the split tarballs we where doing for some of the releases) Cheers, Albert To be clear: this means no kde-workspace 4.12, only 4.11.x with increasing values of x. Maintainance mode, much like KDE 3.5.x went. If everything works ok, we could switch kdelibs to that too, as was originally the plan. (*) kde-workspace, plasma-frameworks, please complete this list if there are more.
