2010/7/9 Markus S. :

Why not create a KDE:/45 repo now? It could be officially maintained till November (and Factory be just a link to /45) and then left to the community (of whom either a few pick up the work or at least keep an unmaintained SC 4.5

I have been doing this since... always. So feel free to add me as maintainer/bugowner of such a repo. I would not be looking at KDE SVN for security fixes, but I could keep it building and updated to newer minor versions. To avoid problems to users I agree, the best way is to do the main development in KDE:45 and aggregate from Factory until it moves to 4.6. But that's not so good for devs, that expect K:D:F to be the development KDE repo. The best thing would be to keep K:D:F as now, and aggregate from KDE:45 (but yes, create it "now"). But at some point those aggregates will need to be converted to own copies... and that will mean a full rebuild, with release numbers doing funny things (not a problem with "zypper dup --from K:D:F", but some people will do a "zypper up"). Any way to keep the release numbers higher after the change? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Friday 09 July 2010 19:43:06 Cristian Morales Vega wrote:

Any 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? Markus -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Sunday 11 July 2010 00:48:54 todd rme wrote:

Would it be KDE:45 or KDE:Distro:45? Or maybe put it whether Unstable is being put?

-Todd

Not Distro. SC 4.5 is no openSUSE release. In the same parent folder as UNSTABLE should work... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

2010/7/12 Lubos Lunak :

On Saturday 10 of July 2010, Markus Slopianka wrote:

...

On Friday 09 July 2010 19:43:06 Cristian Morales Vega wrote:

...

Any 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 be kept.

 - 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, KDE:43

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@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Monday 12 of July 2010, Cristian Morales Vega wrote:

2010/7/12 Lubos Lunak :

...

On Saturday 10 of July 2010, Markus Slopianka wrote:

...

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:

This topic will be discussed at today's IRC meeting (http://en.opensuse.org/openSUSE:KDE_Meetings).

- 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

Hmm, that's not much of a commitment. If that's all you and everybody else would do, it would mean a repo working for a month for one version, in which case it might be better to keep it under somebody's home: rather than "official" under KDE: .

...

 - I don't remember if there were also other problems when we tried KDE:42, KDE:43

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?

That is the theory.

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.

Makes sense.

- 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?)

Tarballs are made accessible to packagers. Since Dirk builds them anyway, the work could be probably shared.

- Every month this is repeated.

Not really, there usually not further x.y-1.z releases once x.y.0 is out and there is not more than one release during the beta cycle of the next minor version.

- 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).

If the repository contains KDE SC 4.x , then only the SC should be there IMO. Independent apps can come from KDE:Extra. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org