On Monday 11 November 2013, Aaron J. Seigo wrote: > On Sunday, November 3, 2013 20:51:57 Alexander Neundorf wrote: > > I wanted to release ECM as fast as possible, since this was one of the > > main points I got from the platform meeting in Randa in June 2011: > > people want to be able to use cmake stuff from KDE without depending on > > kdelibs. Stephen added files, partly without documentation, partly with > > strange interfaces, partly with temporary hacks. Together this has the > > effect that since 2 years ECM is continously not in a releasable state. > > To me this is very frustrating, because this was the goal why I created > > the ECM repository at all. > > I can understand your frustration; let’s see if we can find a solution that > works for everyone, including you and ECM’s primary and largest-by-far > user: KDE. > > > By splitting the "ECM" library into two "libraries", one geared towards > > KF5, and one containing general useful stuff, this issue would be > > solved. General useful stuff would go into ECM, and it would only be > > accepted if it is in releasable state, and this would be released e.g. > > once per month. Hacks needed to make something work in KF5 would go into > > the other (KF5 tier0) package. > > here is a counter-proposal: > > let's use git. > > :) > > branch the repository: > * create a stable branch (stable) full of the things that are ready for > release > * create a KF5 branch (frameworks) which can serve as a playground for > necessary hacks > * if needed, create a third devel branch (stable-next, perhaps use the > master branch for this) > > create some simple workflow policies: > * anything that goes into stable must be merged into frameworks > * anything that goes into stable must be releasable at the time it goes > into stable > * if/when the frameworks branch reaches a stable point, merge all changes > into “stable”, or even a “stable-next” > * people working on frameworks 5 build using the frameworks branch > > form a release strategy: > * release the stable branch right now as ecm 0.1 (or 1.0 .. whatever makes > sense) > * never release frameworks branch, but instead have as release requirement > that it is fully merged into stable-next; when that happens remove the > frameworks branch and all future KDE Frameworks related work would enter > stable-next > > in my mind this allows: > > * an immediate release of ecm
In general yes, but IMO some cleanups in the not-KDE-specific parts would be needed for this currently. I'd propose to proceed with a monthly release cycle afterwards. > * allows KDE to back it rather than have ecm distanced from KDE > * this gives ecm a needed “reference customer” > * this gives KDE a first step into the “we’re a community you can get > your app dev needs from” position > * allows frameworks needs to continue to be worked on in ecm > * avoids further disruptions, like having to think about git submodules in > frameworks repos > > would that work for everyone? Sounds doable I think. The step about merging from "framework" into "stable" may be controversial at times. Ideally I'd like to have somebody without "KDE hat" involved in reviewing the non-KDE stuff which is in/goes into stable. I could ask Dave... Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
