From kde-release-team Thu Jul 25 03:05:55 2013 From: Michael Pyne Date: Thu, 25 Jul 2013 03:05:55 +0000 To: kde-release-team Subject: Re: Proposal for branching policy towards KF5 Message-Id: <6305865.oArMyMoMQZ () midna> X-MARC-Message: https://marc.info/?l=kde-release-team&m=137472165225316 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============2739584880112545529==" --===============2739584880112545529== Content-Type: multipart/signed; boundary="nextPart1715372.FS1yph5LRa"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart1715372.FS1yph5LRa Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 --nextPart1715372.FS1yph5LRa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAABCAAGBQJR8JYcAAoJEAuvDJx7aunypSEP/RxzYmDobazPVbp0DZ/jMkvw b+UaBT+0RcCLHIpMtRHgIAdEbHsSjjgemC8C26eakIS621B9sbNzKKviz4z2PAO4 vDFojlhqAF+EEZK/LWa8KuGudg67dSGDFEr9K50POuDoo+ek/jLz++3OEUXesjJ2 wrXRgTgZt8YRkLteuYRjsfm9cM094sqXnqQBeeHKmUKbX0eWF47iQ4hiJE3Y5k1F pky1zfT3aF3tc1Mf5kzfF1sWkU5O7NIgiDQdJFrTxCqCXwInpEzdCvwLOM8ZQmnU 6I04mMCNhCsNDjhWzEgCISFH9S77wfJthkgG9GMt9ttVfclM2+Zd4TqueQqxLpyp ztEoGNVf+9Cq7kOLvKD3roj+t+Wd9G4kxlJYx2xdCERbVPZS8v7oKSFqcLKFTGzm CdmE4N97mrulwnhCrjhyi2Wa2vICQ24tVmi3mt0BMbPenJUDomXjLnEcrlM84zW0 nfd3v7F04hEH4JXMkcbFi8dRISfXIYZYZZv2pfj7hjoqQGeRjTqtRYWuxwFHHHKs wBr6ah3yehd8Pt/x5uO0EMrbnoZ2el7pcWfUtqEYXVq9kBLD52KeawGJGmY52fNm oWvnVVvhsz+Rs2MqsCqnjzNXGlxlmexOIikwJt7zTyLuG30SHAXRwb9TUVf7lAIb YnzlaQ0pHp2xn8Dyvuq/ =gMWK -----END PGP SIGNATURE----- --nextPart1715372.FS1yph5LRa-- --===============2739584880112545529== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team --===============2739584880112545529==--