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
* 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?
--
Aaron J. Seigo
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
