![](https://seccdn.libravatar.org/avatar/036efc5132b2df24eac525839eef1038.jpg?s=120&d=mm&r=g)
Hi Before I start to submit packages to contrib, I like to have answers for at least the following questions. (Even if Henne sais that we should start with contributing first and afterwards request answers to our questions ;-) Now to my questions - sorry if they're already answered, but I can't find the comlete answers in the wiki... 1) How frozen is frozen? As far as I understand, contrib will contain Contrib:Factory => current development Contrib:<release> => frozen repository Each maintainer should maintain his package for Contrib:Factory and Contrib:<release>, right? As contrib:<release> is frozen (cite: "After the branch no version updates are allowed anymore") - is there really no chance to upgrade a package? I think openSUSE has a very strong policy about frozen packages - but even there some packages have exceptions. If you try to follow the same or a stronger policy in contrib, you lost at least me as packager, as I don't want to maintain leave packages for over 2 years by backporting patches. (I think that's one of the main reasons for the shriveling official repo, btw.) 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? Who escalates/detects, if a packager is not responding? (BTW: Just a side note from my experience with the Education repository: freezing in the same time as the official repository doesn't work - at least for Education.) 3) Is there a jury and/or escalation method defined to settle potential disputes between contrib-reviewers and contrib-maintainers (updates/reachability) ? 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? 5) How will users be informed about updated packages for their release? Currently, if I add a repository like contrib:<release> as user via zypper, it will be added with "refresh disabled". So zypper will never look for updated packages - and therefore I'll never get informed about an updated package. Even if I refresh the repository, I have to download the new package and hope to find information about the reason for the update in the rpm changelog, right? -> Suggestion: 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 ;-)? With kind regards, Lars -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/9767aae13b5dc5bae57766bd5ad32421.jpg?s=120&d=mm&r=g)
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.
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 :)
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 :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/3a766c4a0b64a5d1b06b4a786d5e3a9e.jpg?s=120&d=mm&r=g)
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
![](https://seccdn.libravatar.org/avatar/1d9647aea6c3224f85cf1f361035d660.jpg?s=120&d=mm&r=g)
On Wed, Feb 11, 2009 at 03:21:16PM +0100, Michal Vyskocil wrote:
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.
I agree with Michal (and some others) that disallowing bugfixing by version updates might be too strict rule and should be relaxed a bit - e.g. only for leaf packages (leaf withing the scope of Contrib), prefer minor updates (if possible) etc. As well as Michal, I don't see any good reason of being so strict. May be I'm just blind :) -- Best regards / s pozdravem Petr Uzel, Packages maintainer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel@suse.cz Lihovarská 1060/12 tel: +420 284 028 964 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/bff5f3a982c0eca43c2cf6e50e2daaff.jpg?s=120&d=mm&r=g)
Le mercredi 11 février 2009, à 15:21 +0100, Michal Vyskocil a écrit :
On Friday 30 of January 2009 12:40:00 Henne Vogelsang wrote: 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?
Actually, I think Fedora is the exception, not Debian :-) But maybe I'm wrong. I'm not opposed to version updates on a frozen branch, but this has to be very careful. It's really a matter of making sure it doesn't break anything.
BTW: I suggest adapt a Fedora Maintainers Policy [2] for Contrib, because those things needs to be written!
Nod. Actually, it makes sense for openSUSE in general, not just Contrib ;-) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/9767aae13b5dc5bae57766bd5ad32421.jpg?s=120&d=mm&r=g)
Hi, on 02/11/2009 03:21 PM Michal Vyskocil wrote:
On Friday 30 of January 2009 12:40:00 Henne Vogelsang wrote:
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.
I understood that the question was about maintainership and not about how to submit something. So about who is responsible for doing the patch. And this is the maintainer for both Factory:Contrib and 11.2: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.
We can phrase this differently. The rule is that new features are strongly discouraged (this is actually how it is handled in Factory). Does that sound better?
BTW: I suggest adapt a Fedora Maintainers Policy [2] for Contrib, because those things needs to be written!
I'm against writing down common sense stuff. Makes life complicated :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/bff5f3a982c0eca43c2cf6e50e2daaff.jpg?s=120&d=mm&r=g)
Le jeudi 12 février 2009, à 14:54 +0100, Henne Vogelsang a écrit :
Hi,
on 02/11/2009 03:21 PM Michal Vyskocil wrote:
BTW: I suggest adapt a Fedora Maintainers Policy [2] for Contrib, because those things needs to be written!
I'm against writing down common sense stuff. Makes life complicated :)
Heh, right. But some stuff like "What to do if a Maintainer is absent" seems useful, especially since there's no common sense about this (some people would wait 2 days, others would wait 2 weeks...). Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/3a766c4a0b64a5d1b06b4a786d5e3a9e.jpg?s=120&d=mm&r=g)
On Thursday 12 of February 2009 14:54:11 Henne Vogelsang wrote:
Hi,
on 02/11/2009 03:21 PM Michal Vyskocil wrote:
On Friday 30 of January 2009 12:40:00 Henne Vogelsang wrote:
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.
I understood that the question was about maintainership and not about how to submit something. So about who is responsible for doing the patch. And this is the maintainer for both Factory:Contrib and 11.2: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.
We can phrase this differently. The rule is that new features are strongly discouraged (this is actually how it is handled in Factory). Does that sound better?
Yes, it sound better.
BTW: I suggest adapt a Fedora Maintainers Policy [2] for Contrib, because those things needs to be written!
I'm against writing down common sense stuff. Makes life complicated :)
It makes things more clear (even a maintenance of this documentation is not easy), because everyone will knows what to do if <something>. Currently we don't know who will be able to do an update in frozen Contrib, because we didn't write it as a rule. We don't want how to deal with non-responsing maintainers, ... I think that distribution with community participation as Debian or Fedora has these rules, because they're necessary.
Henne
-- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson
-- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/036efc5132b2df24eac525839eef1038.jpg?s=120&d=mm&r=g)
On Freitag 30 Januar 2009 12:40:00 Henne Vogelsang wrote:
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.
ok: In this case, you lost at least me as packager for contrib.
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 :)
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.
What about security issues with CRD? They shouldn't be visible in public... ...so: Can the current Novell Security Team handle security issues in Contrib via Bugzilla?
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?
I'm just thinking about people currently using the official openSUSE Update-Test repositories. They want is easy to test whatever will be released in the next update cycle. If you say: "Each package maintainer has to find his own way to get testers for his package outside the Contrib repository", you make it harder for people to participate.
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 :)
Well, for Education we're currently NOT using the buildservice for our frozen repositories. We use the Buildservice for development and preparing package updates... So we have at least 3 different repositories: 1) Development repository => OBS:Education 2) Frozen repository => repo/1.0/11.1 for example 3) Update repository => updates/1.0/11.1 for example Might be an idea to setup a similar setup for contrib? CU, Lars -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/bff0c215e01f23fcee6fe49e65fae458.jpg?s=120&d=mm&r=g)
On Thu, Feb 12, 2009 at 12:13:48PM +0100, Lars Vogdt wrote:
I'm sure the security team will notify this list. We did not talk about this yet.
What about security issues with CRD? They shouldn't be visible in public... ...so: Can the current Novell Security Team handle security issues in Contrib via Bugzilla?
We can try. :) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
participants (6)
-
Henne Vogelsang
-
Lars Vogdt
-
Marcus Meissner
-
Michal Vyskocil
-
Petr Uzel
-
Vincent Untz