Getting ecm files from the ECM package

[Alexander Neundorf]

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