On Sunday 16 Sep 2012 13:11:12 Sven Burmeister wrote:
Am Samstag, 15. September 2012, 22:24:45 schrieb Will Stephenson:
In my humble opinion there is now a false dichotomy between 'community maintained' and 'team maintained' - KR49 as community territory and KDF as the homeland of the SUSE engineer. As there is effectively no dedicated KDE (or GNOME if it makes you feel better) team inside SUSE for openSUSE any more, KDF has to be community maintained. Whether that is Dirk doing bits and pieces on his own time, my small parcels of work time, you, Martin, Raymond, Alin, Todd or Nico, we are the openSUSE KDE team.
But we have different goals. Martin wants a rock stable release and warns of regressions. And don't get me wrong, I do see his point even though I do not want to use it. I just don't see the community to create and maintain it or alternatively the commitment by openSUSE to do so.
openSUSE people are concerned with the openSUSE release as well albeit not having time to contribute as much as they want to. They enforce the schedule but lack time to contribute – a pretty "funny" situation. Some from the employed "KDE team" seem to work more on other projects or are suddenly away for "more important" work. Not blaming (maybe the management) but just describing my impression. Raymond and Alin AFAIK do not use any stable KDE, maybe not even a stable openSUSE version. I do not use STABLE either but KRxy, i.e. follow upstream, Todd and Nico probably as well.
There hasn't been an 'employed "KDE team"' since all the desktop teams were rolled up into the Boosters team. We were all doing KDE (or GNOME for that matter) stuff, more or less successfully, on the side of our Boosters projects. After 2 years, nobody thought the team as a whole was working so it's now been made clear by management that with the exception of essential 'release engineering' the team will work together on making openSUSE cool, whether it's release PR, events, or big picture engineering, and stuff like packaging desktops is a job for the community. This shouldn't come as a shock to you - in fact, while we were called the Boosters Team, I justified my KDE work to managers as saying it was essential heavy lifting to support a working community team. However I fear that by doing so much, we inhibited an independent community team from forming to work on KDE for openSUSE releases, so everyone got used to doing their personal luxury contributions without any constraints.
My conclusion is that very few use and contribute to what is stated as the most important target, i.e. openSUSE release KDE version, aka KDF and STABLE. Most follow upstream one way or another and their work just adds to the openSUSE release KDE version as long and if it concurs with the upstream releases.
Even if your conclusion is correct, which I doubt - the point I tried to make is that you* are the openSUSE community so you get to agree and set the targets and the policy that determines "openSUSE release KDE version". Look at how Dominique (community) just got made part of the checkin team, enforcing the schedule. Look at the discussion that is happening on opensuse-project@ about schedules and development and you'll see that variations on the release schedule that would allow more flexible version updates and more frequent releases are being discussed and refined. If you're not part of that discussion, others (who you are just as well qualified as) will shape those decisions. There's no need to go from where we are now to being a dissident Kubuntu to "openSUSE"'s Ubuntu. If you are content to tinker away in the KDE: namespace without caring about schedules, keep in mind that other desktops' community teams will happily work together provide a stable release and maintain it and KDE will be relegated to being an alternative option. * I include myself in 'the openSUSE community' but write 'you' instead of 'we' - as an individual I'm in the minority.
The aim of KDE:Release:xy repos is to provide packages of the latest upstream stable release, implemented as a snapshot of our development towards the next openSUSE release. What you suggest is the converse of that, but then we can't use KRxy for feature/packaging/new version development without bombarding 'stable upstream release' users with (broken?) updates.
Currently only important upstream patches are added to KRxy in-between upstream releases and apps that are not part of KDE SC updated to stable releases. That's how the official update channel should work as well, updated pnm in order not to annoy upstream etc. Just that it does not happen because backporting and all that double work is needed.
If somebody wants to play wild with patches not tested or applied upstream he can create a devel branch of the KRxy package in KDF. Further, KDF might at some point contain betas, KRxy not. KDF might change from one major version to another, KRxy not. So KRxy is far more reliable and predictable than KDF. And KRxy is only left behind after the last upstream bugfix release and if a new stable upstream release is available for openSUSE users.
KRxy is the repo which moves forward continuously, i.e. follows upstream. KDF does not. So why would one branch the former from the latter instead of the other way around? Only because of the "openSUSE KDE release".
In the end KRxy has to get "unlinked" from KDF at some point anyway, i.e. as soon as the freeze prevents any updates in KDF. If KDF branches from KRxy that problem does not exist and those maintaining KRxy can just go on with their work as usual without having to care about the dos and dont's of an openSUSE release. And I think the current maintenance of KRxy works really well unlike when it was bound to KDF.
So if I may paraphrase and answer you point by point:
S1 "KRxy is an alternative stable update channel because official updates are
restricted by lack of resources"
W1 The work you're doing is exactly what would be needed for official updates.
Do it in our devel repos and link it to KRxy and everyone wins. Or play at
project level instead of KDE: and get the maintenance policy changed.
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.
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.
Conversely, doing development work directly in KRxy limits you to not doing
any significant packaging changes, eg to track upstream changes such as the
kdegames move to git. You want to be able to leave it publish-enabled so you
and others can test your own work easily, but you don't want to have the
responsibility of not being able to break things while working. As soon as you
want to work on something that affects >1 package, you have to make a devel
branch and you're effectively the same as
S5 "KRxy maintenance works better that it did when linked to KDF"
W5 I don't see evidence to support this claim, and anyway you haven't been
doing it long enough to face some nasty, complex issues to maintain yet.