On Friday 30 of January 2009 12:40:00 Henne Vogelsang wrote:
Hi,
on 01/30/2009 02:11 AM Lars Vogdt wrote:
1) How frozen is frozen?
As far as I understand, contrib will contain Contrib:Factory => current development Contrib:<release> => frozen repository
Correct.
Each maintainer should maintain his package for Contrib:Factory and Contrib:<release>, right?
Yes.
Really? I think that we talk that every maintainer lost the permissions after freeze and updates will be handled via submitreq. If we'll allow a direct access, we could reconsider a Contrib as a rolling updates repository like Packman and don't need to play on freeze of repository.
As contrib:<release> is frozen (cite: "After the branch no version updates are allowed anymore") - is there really no chance to upgrade a package?
We are mimicking Factory. So the same rules apply.
2) What about orphaned/unfixed packages? If a package fails in contrib:factory or needs a security fix in the contrib:<release> repos - what's the expected response time?
ASAP :)
I'm not sure that we want and need to be strict rule. Afaik only one community based distro has this policy - the Debian, but they have only *one* stable release at time. And Debian community (I'm talking about package maintainers especially) is probably more experienced and bigger than openSUSE, so why we want more annoying work (which backporting of fixes is) for openSUSE contributors than Debian? Fedora is more close to openSUSE release cycle and it's also community opened and allow [1] the version update after release, so why not be able to do this in Contrib? I don't see any big advantages of this rule in Contrib, which contains at least leaf packages (like apg, or gle-graphics). I suppose we should be less strict and allow a version update in frozen repository when it will be necessary.
Who escalates/detects, if a packager is not responding?
I'm sure the security team will notify this list. We did not talk about this yet.
3) Is there a jury and/or escalation method defined to settle potential disputes between contrib-reviewers and contrib-maintainers (updates/reachability) ?
In general: Reviewers win. Everything else has to be decided on a case by case basis.
4) How to test updates?
If a packager has to fix a package for a frozen distribution and wants some people to test it - how should this work? * Would there be a Contrib:<release>:testing repository for this? * Should testers add the packagers home repository (containing perhaps other packages) and install from there?
Up to the Maintainer and his testers. Why do you think should we "regulate" this?
5) How will users be informed about updated packages for their release?
We talked about this briefly if we need security announcements for Contrib. We did not come to a conclusion yet.
Is it perhaps possible to get a "real update repository" containing patchinfos (the files which can be shown in the updater-applet on my desktop) for released contrib repositories (like Education does ;-)?
Of course we can do this.
In general: As you can see we have not put too much thought into the release of Contrib yet. You are welcome to drive this as you obviously have experience with this in Education :)
BTW: I suggest adapt a Fedora Maintainers Policy [2] for Contrib, because those things needs to be written! BTW2: The Packaging Guidelines [3] is also better that almost everything what we have on opensuse.org, but this has an impact on packaging on whole openSUSE, so I'll start this discussion on opensuse-packaging ML. [1] http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines [2] http://fedoraproject.org/wiki/PackageMaintainers/Policy [3] http://fedoraproject.org/wiki/Packaging/Guidelines Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org