2010/7/12 Lubos Lunak <l.lunak(a)suse.cz>cz>:
On Saturday 10 of July 2010, Markus Slopianka wrote:
On Friday 09 July 2010 19:43:06 Cristian Morales
way to keep the release numbers higher after the change?
Add a new bugfix release (SC 4.5.4 or whatever will be released in
November) to the repo... :-)
What are the stumbling blocks to create /45 now?
- somebody doing the work
As said I want it for myself. So I could do the work, meaning:
- I'm not a KDE dev. I'm not subscribed to KDE ML and I don't follow
SVN. What I can do is keep it building and updated, little more.
- I will test the parts I use. Don't expect me to install eric to
verify it doesn't segfaults at start.
- Bug reports against such a repo: I would take care of them, but I
don't consider them very high priority if it's a problem already fixed
in KDE 4.6 (I'm not going to backport/create fixes).
- I would stop maintaining it the day K:D:F starts providing KDE 4.6.0 final.
- I'm interested in keep it for openSUSE *11.3*. Older versions and
SLE... I would fix problems in them when I were really bored. So *if
it's going to be just me* perhaps it's better to not build against !=
11.3 at all. But I don't expect it to break so often. Most of the time
the fix should be to just add (link from another project) a newer
library not provided by the old openSUSE version. So, if people can
tolerate a delay of a week/ten days, old openSUSE versions builds can
- people getting even more confused by which repo to
use (KDE:<version> vs vs
KDE:Distro:Stable vs KDE:Distro:Factory)
The most problematic part would be getting people to change to Factory
when 4.6.0 is released. Not sure about the best idea... name the repo
"KDE:latest_release_version_from_upstream" ;-) an start aggregating it
(or keeping a redirect at download.opensuse.org
) again from K:F:D?
- I don't remember if there were also other
problems when we tried KDE:42,
Well, that's important. I'm expecting this to be a low (once a month)
maintainership task. Being the most problematic part keeping some
patches applying when packages are updated to new micro versions. But
once a new KDE 4.5.x version is ready it shouldn't need to be touched
at all until the next update from upstream. I'm wrong?
In my view this will be:
- The repo is created as an aggregate (redirect at
download.opensuse.org?) of K:D:F soon before the day K:D:F starts
providing KDE 4.5. Once 4.5.0 is released publishing is enabled.
- I do nothing special until K:D:F starts providing KDE 4.6.
- It would be great if you sync the move to 4.6 with a 4.5.x release.
The day the repo would start being independent of K:D:F it will be
providing a new version, so users have no problems with updates.
- Everything is working. The update meant just substituting the
version tag in spec files and updating the tarball. No more than ten
packages stopped building, because a patch didn't apply anymore. The
patch was either easily refreshed or not needed anymore.
- No problems until the next month, when a new upstream version is
released. Once again it just means updating tarballs and version tags
("osc collab update" is doing all the work?). I have 5 days between it
being tagged and released (I need to create tarballs from SVN? Do you
have early access to the official ones?)
- Every month this is repeated.
- Some independent apps have new releases from time to time. These are
now links from K:D:F... sometimes they break and I create a local
patch (no need to pollute K:D:F packages because of this).
- KDE 4.6.0 is released and this repo deleted.
If that's enough, create the repo and put me as maintainer/bugowner.
To unsubscribe, e-mail: opensuse-kde+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kde+help(a)opensuse.org