Susanne Oberhauser wrote:
Hi Peter,
Peter Poeml
writes: Nitpick: no new python is required. (Just some modules.)
Yes.
For that reason we linked some packages into the current openSUSE:Tools:Unstable project and made them build on the old distros, too.
[This is evil]
Fully agreed, that's why I brought this up.
The links were only done because: - there is no other project yet were we can get the required pkgs for all the target distros (also the python pkgs are not yet been there for Fedora) - there are required version updates of packages (e.g. createrepo), which are needed by OBS scripts. - some required sub packages might also been required to update. So we have the situation that the pkgs are intentionally supplied with new versions atm. What to do with packages that: a) need a newer version in OBS b) have an old version of the package in the distro c) beak on update to the new required version. Tell me how to solve this and I do it. I was not able to test all the combinations if we implement a policy of keeping old versions if it works and upgrading to new if it doesnt. Who wants to test that?
So simple: 1) wait if it actually happens at all 2) talk to the maintainers so they are aware 3) move on. ;-)
We still could link a package with patches into openSUSE:Tools _then_.
We've already had 1), and 2) is only a solution after the fact and doesn't prevent others from breaking 'my product'.
linking in the package is not the solution I'm proposing, though, it's an ugly work-around that I'd like to avoid.
You and I are members of the obs team, we are used for things to break and we're used to get a quick fix, plus we don't _rely_ on obs yet for some other bread-and-butter business (like releasing a product that uses obs).
Fortunately we start seeing people using obs for such jobs, where obs is a tool that's supposed to work, not the tool that is being worked on.
I'd love to see more of this, a real network of obs instances, and my concern is that by iterating 1) and 2) above, the early birds shy away.
May this was not clear, but I agree with Susanne that we have 1) and 2) already.
I don't like this proposal. I really don't think that anybody needs different releases of the build service at all.
At this time, this is right. But there is aneed for different Rails releases. So far non of the base python packages were API incompatible after upgrades, so _so far_ we're fine on that end.
Now there's two options:
1) I, as maintainer of some Foo-foo project , need to know exactl the different API policies of the base projects I rely on
2) there's an established policy of giving new APIs a new name, and I just rely on that.
Option 2) implicitely is implemented by the openSUSE releases. after release, they don't change dramatically any more.
How to do that with multiarch pkgs. They need to comply to all distros policies then.
I don't think we are going to (nor need to) maintain old releases in "maintenance-mode", we will rather move on.
I'm currently talking about the base packages, and for a foreseeable future I'm also talking about force-updating users with possibly incompatible versions by releasing new packages into the old release repo.
Maybe this is just me but I'd hate to run zypper up and after that the system I just _use_ to build some packages doesn't work any more :/
Most OBS users are just users, not developers. They want fire and forget. Only people that know already that they want to make a challenge (some yet untested feature etc.) look deeper and might install some testing version or even install from source. Its a fact that we had in the past more than once "released" versions that broke your build service. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org