Mandag den 17. september 2012 18:15:49 skrev Will Stephenson:
S2 "KRxy follows a predictable, continuous update policy" S3 "KDF imposes artificial restrictions on tracking upstream" W2 KDF follows the same policy except for a short phase during the end of the release cycle.
Let me propose an alternative, lock-free yet releasable approach where we can all work together:
Give KDF access to proven KRxy maintainers. KRxy(for latest stable KDE x.y) links KDF packages. As soon as the openSUSE release cycle locks the KDE version down, KDF is copied to KDS, and release development (high prio bugfixing) happens in KDS. Any maintenance work for the released openSUSE happens via branches. The team continues to do version updates and upstream patches in KDF and updates links in KRxy until KRxy+1 is released, at which point the old codebase is moved to a new project, same as always.
Sounds like a very good idea that should fit everyone's needs. The challenge is just to make anyone care about KDS for the two month freeze period every eight (12?) months. Of course caring about KDS would also imply caring about what's best for the openSUSE project, the openSUSE distribution, KDE and end users more than version numbers, so it's an uhill battle.
S4 "KDF might ship a beta" W4 Highly unlikely at this stage in the KDE 4 cycle, really. When we do ship KDE5 beta it will be from a different devel project, we'll keep stable KDE4 as a default.
Say 12.3 will be released in March with 4.10, there would be very little time to test 4.10 if 4.10beta wasn't allowed in KDF. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org