Re: repository changes for plasma2/frameworks5
On Tuesday 29 January 2013, David Faure wrote: OTOH, there's also reasons to not split too early. It depended on quite some stuff in other modules last I checked (could have changed), moving it to another repo that early means less eyeballs and build problems likely caught later. We have the all-seeing build.kde.org now for this :-) yeah, if from the new repo will continue to send build errors here, it may be a good solution -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Tuesday, January 29, 2013 11:22:29 Kevin Ottens wrote: Kidding of course. You're right it's probably fine for that one if they keep updating kdelibs/frameworks during development to avoid diverging too quickly. Which is indeed likely the case in that team. yes, we'd commit to making sure it continues to build properly. after all .. we can't work on it unless we do :) so if we make that commitment (using both our eyes and the spiffy CI infrastructure), are you cool with us splitting sooner rather than later? as nothing in kdelibs depends on libplasma, this has no impact on any other part (which is not the case for many/most other parts of kdelibs which does indeed benefit as a result from delaying the split) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Wednesday 30 January 2013, Aaron J. Seigo wrote: On Tuesday, January 29, 2013 11:22:29 Kevin Ottens wrote: Kidding of course. You're right it's probably fine for that one if they keep updating kdelibs/frameworks during development to avoid diverging too quickly. Which is indeed likely the case in that team. yes, we'd commit to making sure it continues to build properly. after all .. we can't work on it unless we do :) so if we make that commitment (using both our eyes and the spiffy CI infrastructure), are you cool with us splitting sooner rather than later? as nothing in kdelibs depends on libplasma, this has no impact on any other part (which is not the case for many/most other parts of kdelibs which does indeed benefit as a result from delaying the split) i'm toying now with a scratch repo with the stuff we need filter-branched out. will need some adjustment since some old commits don't pass audit anymore, but we should have it soon(tm) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Wednesday 30 January 2013 12:38:06 Aaron J. Seigo wrote: On Tuesday, January 29, 2013 11:22:29 Kevin Ottens wrote: Kidding of course. You're right it's probably fine for that one if they keep updating kdelibs/frameworks during development to avoid diverging too quickly. Which is indeed likely the case in that team. yes, we'd commit to making sure it continues to build properly. after all .. we can't work on it unless we do :) Aha, well I was more thinking the other way around. I don't want the changes which would get in kdelibs to disrupt you too much (as those would be done by people not necessarily building the new repo every time they touch kdelibs/frameworks, which is not the case today). so if we make that commitment (using both our eyes and the spiffy CI infrastructure), are you cool with us splitting sooner rather than later? Sure. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Monday 28 January 2013 18:54:12 Stephen Kelly wrote: Marco Martin wrote: Most important, what is the less messy git way to do it? As we discussed on IRC, it may be better to split plasma out into its own repo now already, like we did with nepomuk. OTOH, there's also reasons to not split too early. It depended on quite some stuff in other modules last I checked (could have changed), moving it to another repo that early means less eyeballs and build problems likely caught later. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Tuesday 29 January 2013 09:11:54 Stephen Kelly wrote: Kevin Ottens wrote: OTOH, there's also reasons to not split too early. It depended on quite some stuff in other modules last I checked (could have changed), moving it to another repo that early means less eyeballs and build problems likely caught later. I don't know the latest on those dependencies either, but it doesn't really matter, does it? The problems will be caught whenever someone tries to build the external plasma repo and discovers they now need another include or whatever. Then it just depends on how often they update/build. People working on frameworks/plasma are not inexperienced newbies who don't know how to fix minor issues like that (and I don't think we need to optimize for such newbies yet either). I'm sure it's fine. Well, IMO you're putting too much trust in a bunch of punks with a clock fetish... Kidding of course. You're right it's probably fine for that one if they keep updating kdelibs/frameworks during development to avoid diverging too quickly. Which is indeed likely the case in that team. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Tuesday 29 January 2013, Kevin Ottens wrote: plasma repo and discovers they now need another include or whatever. Then it just depends on how often they update/build. People working on frameworks/plasma are not inexperienced newbies who don't know how to fix minor issues like that (and I don't think we need to optimize for such newbies yet either). I'm sure it's fine. Well, IMO you're putting too much trust in a bunch of punks with a clock fetish... eheh, indeed ;) Kidding of course. You're right it's probably fine for that one if they keep updating kdelibs/frameworks during development to avoid diverging too quickly. Which is indeed likely the case in that team. so, i think that for a while we'll continue the development of the library there for a while (a month/two or so) before moving out while in kde-runtime we'll do a plasma/frameworks branch accordingly) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Tuesday 29 January 2013 09:03:00 Kevin Ottens wrote: On Monday 28 January 2013 18:54:12 Stephen Kelly wrote: Marco Martin wrote: Most important, what is the less messy git way to do it? As we discussed on IRC, it may be better to split plasma out into its own repo now already, like we did with nepomuk. I agree. OTOH, there's also reasons to not split too early. It depended on quite some stuff in other modules last I checked (could have changed), moving it to another repo that early means less eyeballs and build problems likely caught later. We have the all-seeing build.kde.org now for this :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
repository changes for plasma2/frameworks5
Hi all, As you know, Plasma is composed mainly by two parts: the library, now in kdelibs and a runtime part, now in kde-runtime. the runtime part is basically: * QML imports * A scriptengine to write plasmoids in QML, dataengines in javascript etc * a kpart * default theme * some command line tools For the development of plasma2, the development of those parts will have to go together since both have to be ported to QML2 that has some significant differences at runtime level. Since one idea of Frameworks was to have in the same place the library and the runtime, this was the idea of repo reorganize: * what's is now in kdelibs/plasma goes to kdelibs/plasma/plasma (last name still being plasma makes possible to move without changes in the code) * what's now in kde-runtime/plasma (except the containments subfolder) goes in kdelibs/plasma * what's now in kde-runtime/desktoptheme goes to kdelibs/plasma/desktoptheme probably in the end i guess all of this will have to go in a separate repo of its own: so the merge operation can be done either before, still in kdelibs or after the creation of a new repo (if we want it in a separate repo) Most important, what is the less messy git way to do it? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
Marco Martin wrote: Most important, what is the less messy git way to do it? As we discussed on IRC, it may be better to split plasma out into its own repo now already, like we did with nepomuk. As the frameworks branch has a 'use-by' date, I'd prefer not to import more things into it from kde-runtime. Thanks, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
On Monday 28 January 2013, Stephen Kelly wrote: Marco Martin wrote: Most important, what is the less messy git way to do it? As we discussed on IRC, it may be better to split plasma out into its own repo now already, like we did with nepomuk. As the frameworks branch has a 'use-by' date, I'd prefer not to import more things into it from kde-runtime. yeah, would go for creating a new repo now, now asked scm interest and will let you know since may be useful again in frameworks in the future Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
