[opensuse-packaging] Packages for sale
Hi, some of the packages currently assigned to me need other maintainers who can give more love. If any of you find a package below interesting, please let me know. ================================================================ cachefilesd The new feature of 2.6.31 kernel; Maybe not much work compcache Compressed RAM swap, including KMP Experimental packages for the time being csound Can be dropped from FACTORY, maintained on multimedia:apps dssi Can be dropped from FACTORY, maintained on multimedia:libs fftw Old FFTW2; very stable, so far nothing needed except for minor build fixes fftw3 New FFTW3; a newer version expected to be released soon, but for openSUSE-11.3 fluidsynth Can be dropped from FACTORY, maintained on multimedia:libs freqtweak Very old; can be dropped from FACTORY gamix Very old; can be dropped from FACTORY gnash Opensource flash player; recently quiet; Can be dropped from FACTORY gwc Old program; can be dropped hydrogen Can be dropped from FACTORY icecast Can be dropped from FACTORY ices Can be dropped from FACTORY jack Old JACK-0.x; Maybe JACK-2.x will be on the future distro jack-rack Can be dropped from FACTORY jackEQ Can be dropped from FACTORY jamin Can be dropped from FACTORY ladspa Needs updates of some plugins; another idea would be to split this to several packages lash Can be dropped from FACTORY latencytop Fairly stable libao Fairly stable libatomic-ops-devel Just copied from Debian libfreebob Old package, can be dropped libid3tag Can be dropped libjackasyn Can be dropped liblo Can be dropped liblrdif Can be dropped libsamplerate Fairly stable libshout Fairly stable mercurial Active development, a newer version will come sooner or later meterbridge Old package; can be dropped pmidi Old package; can be dropped portaudio No active development? Can be dropped qjackctl Fairy stable, spontaneous updates resample Can be dropped rosegarden4 Can be dropped seq24 Can be dropped snd Can be dropped solfege Can be dropped soundtracker Old package; can be dropped stgit Stable, can be dropped swami Old package; should be updated to the unstable version or dropped sweep Can be dropped timidity can be dropped ================================================================ thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Mon, 07 Sep 2009 18:06:19 +0200, I wrote:
Hi,
some of the packages currently assigned to me need other maintainers who can give more love.
If any of you find a package below interesting, please let me know.
No one interested? I'm going to send deletereq to FACTORY unless any one can pick them up. thanks, Takashi
================================================================ cachefilesd The new feature of 2.6.31 kernel; Maybe not much work compcache Compressed RAM swap, including KMP Experimental packages for the time being csound Can be dropped from FACTORY, maintained on multimedia:apps dssi Can be dropped from FACTORY, maintained on multimedia:libs fftw Old FFTW2; very stable, so far nothing needed except for minor build fixes fftw3 New FFTW3; a newer version expected to be released soon, but for openSUSE-11.3 fluidsynth Can be dropped from FACTORY, maintained on multimedia:libs freqtweak Very old; can be dropped from FACTORY gamix Very old; can be dropped from FACTORY gnash Opensource flash player; recently quiet; Can be dropped from FACTORY gwc Old program; can be dropped hydrogen Can be dropped from FACTORY icecast Can be dropped from FACTORY ices Can be dropped from FACTORY jack Old JACK-0.x; Maybe JACK-2.x will be on the future distro jack-rack Can be dropped from FACTORY jackEQ Can be dropped from FACTORY jamin Can be dropped from FACTORY ladspa Needs updates of some plugins; another idea would be to split this to several packages lash Can be dropped from FACTORY latencytop Fairly stable libao Fairly stable libatomic-ops-devel Just copied from Debian libfreebob Old package, can be dropped libid3tag Can be dropped libjackasyn Can be dropped liblo Can be dropped liblrdif Can be dropped libsamplerate Fairly stable libshout Fairly stable mercurial Active development, a newer version will come sooner or later meterbridge Old package; can be dropped pmidi Old package; can be dropped portaudio No active development? Can be dropped qjackctl Fairy stable, spontaneous updates resample Can be dropped rosegarden4 Can be dropped seq24 Can be dropped snd Can be dropped solfege Can be dropped soundtracker Old package; can be dropped stgit Stable, can be dropped swami Old package; should be updated to the unstable version or dropped sweep Can be dropped timidity can be dropped ================================================================
thanks,
Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Takashi Iwai wrote:
I'm going to send deletereq to FACTORY unless any one can pick them up.
Isn't it better to leave them in Factory so someone in the future could take care of them? What benefits brings dropping from Factory? -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Mittwoch 09 September 2009 schrieb Pavol Rusnak:
Takashi Iwai wrote:
I'm going to send deletereq to FACTORY unless any one can pick them up.
Isn't it better to leave them in Factory so someone in the future could take care of them? What benefits brings dropping from Factory?
I tend to agree to leave them as long as they are not security relevant and simply remove yourself from bugowner status in the devel projects. And I'll remove compcache from livecds again :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Wed, 9 Sep 2009 17:39:36 +0200, Stephan Kulow wrote:
Am Mittwoch 09 September 2009 schrieb Pavol Rusnak:
Takashi Iwai wrote:
I'm going to send deletereq to FACTORY unless any one can pick them up.
Isn't it better to leave them in Factory so someone in the future could take care of them? What benefits brings dropping from Factory?
I tend to agree to leave them as long as they are not security relevant and simply remove yourself from bugowner status in the devel projects.
OK, will do. But, what should we do really for security issues...?
And I'll remove compcache from livecds again :)
Or assign yourself as the maintainer of compcache :) thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ... -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, Sep 09, 2009 at 06:04:47PM +0200, Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
But in this case there is noone in the community that cares to care either... Petr "Pasky" Baudis -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mercredi 09 septembre 2009, à 18:54 +0200, Petr Baudis a écrit :
On Wed, Sep 09, 2009 at 06:04:47PM +0200, Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
But in this case there is noone in the community that cares to care either...
There might be people who care about security issues in openSUSE (and so in the packages we have), and not the packages themselves. Those people would step to submit security fixes when needed. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Vincent Untz wrote:
But in this case there is noone in the community that cares to care either...
There might be people who care about security issues in openSUSE (and so in the packages we have), and not the packages themselves. Those people would step to submit security fixes when needed.
Yes, exactly. What list do you think would be the most appropriate to discuss with community and our internal security team about the creation of external team? (I doubt packaging is the right place :-) -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
There is already a discuss about a community focused on a kind of
"openSLES, an openSUSE based distro to aim small companies that needs
security fix an so on...
Perhaps, these two interests can converge.
On Wed, Sep 9, 2009 at 6:09 PM, Pavol Rusnak
Vincent Untz wrote:
But in this case there is noone in the community that cares to care either...
There might be people who care about security issues in openSUSE (and so in the packages we have), and not the packages themselves. Those people would step to submit security fixes when needed.
Yes, exactly. What list do you think would be the most appropriate to discuss with community and our internal security team about the creation of external team? (I doubt packaging is the right place :-)
-- Best Regards / S pozdravom,
Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- [ ]'s Aledr - Alexandre "OpenSource Solutions for SmallBusiness Problems" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
We did and have already volunteers. See the thread, [opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html Waiting for Dirks reaction at the moment. I understood that he traveled a lot... Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 11:09:33 +0200, Henne Vogelsang wrote:
Hi,
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice? thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag 10 September 2009 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 11:09:33 +0200,
Henne Vogelsang wrote:
Hi,
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice?
Of course there is a problem - if there is a bug with it, it needs evaluation. For most of your "can be dropped from Factory", this wouldn't change anything as people can report bugs also when the package is from multimedia:libs :) For those old ones that "can be dropped", I would prefer to see them really dropped if there is no user of it that is able to maintain it. But for things that are really adding value to the distribution I don't want to see them dropped _NOW_ because noone stepped up for 3 days. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 11:26:27 +0200, Stephan Kulow wrote:
Am Donnerstag 10 September 2009 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 11:09:33 +0200,
Henne Vogelsang wrote:
Hi,
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice?
Of course there is a problem - if there is a bug with it, it needs evaluation. For most of your "can be dropped from Factory", this wouldn't change anything as people can report bugs also when the package is from multimedia:libs :)
That's true - but then at least the bug doesn't belong only to the package maintainer but all project maintainers. And, OBS packages are basically non-official unless they are on FACTORY. So, if you have any problems, it's free to drop immediately at worst. That's why dropping from FACTORY can be a "safer" option for orphaned packages.
For those old ones that "can be dropped", I would prefer to see them really dropped if there is no user of it that is able to maintain it. But for things that are really adding value to the distribution I don't want to see them dropped _NOW_ because noone stepped up for 3 days.
Don't worry, maybe the target to drop will be 11.3, judging from the timeline. As I mentioned, the post was a sort of provocation :) But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more? The situation of maintenance isn't so trivial right now in many areas; even though many packages are even on SLES. This is my honest and serious concern... thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag 10 September 2009 schrieb Takashi Iwai:
That's true - but then at least the bug doesn't belong only to the package maintainer but all project maintainers. And, OBS packages are basically non-official unless they are on FACTORY. So, if you have any problems, it's free to drop immediately at worst. That's why dropping from FACTORY can be a "safer" option for orphaned packages.
While it's certainly true, it's clearly not so black & white. I still find it acceptable closing bugs as WONTFIX with the comment that you have no time to fix it and the suggestion to take over maintenance if cared for. Of course we shouldn't put such packages on the DVD - and I need to go through your list checking :)
For those old ones that "can be dropped", I would prefer to see them really dropped if there is no user of it that is able to maintain it. But for things that are really adding value to the distribution I don't want to see them dropped _NOW_ because noone stepped up for 3 days.
Don't worry, maybe the target to drop will be 11.3, judging from the timeline. As I mentioned, the post was a sort of provocation :)
Well, the problem is provocation as such won't help - it won't generate volunteers. Dropping the package might indeed generate volunteers, just as we have a vpnc package maintainer now again that's using it too :)
But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more?
I'm very well aware and openSUSE users will have to decide if it's worth to keep it alive or concentrate on scim and xemacs. Some packages in there are really outdated and noone really knows who is using them (and not even Mike knows about all of them I'm sure :) - I don't think we should have such packages. And if there are packages that are used by people and buggy, _then_ we need to convince these people to pick 'em. And yes, that "people" includes Novell managers - if anyway wants M17N packages fixed, he needs to find a way to get it fixed. But the whole "Novell does not control all of factory" concept is pretty new, so I would give it some more time to settle before claiming failure. But again: we still need a way to evaluate if a package should be dropped, I'm just claiming that _now_ is a bad time for that :)
The situation of maintenance isn't so trivial right now in many areas; even though many packages are even on SLES. This is my honest and serious concern...
Mine too, but we have way too many packages around to always have an active maintainer for them. So some staleness we will always have to live with. I got notified that my package would be removed from debian only after leaving it alone for 8 years - so even debian removes packages ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 12:21:23 +0200, Stephan Kulow wrote:
Am Donnerstag 10 September 2009 schrieb Takashi Iwai:
That's true - but then at least the bug doesn't belong only to the package maintainer but all project maintainers. And, OBS packages are basically non-official unless they are on FACTORY. So, if you have any problems, it's free to drop immediately at worst. That's why dropping from FACTORY can be a "safer" option for orphaned packages.
While it's certainly true, it's clearly not so black & white. I still find it acceptable closing bugs as WONTFIX with the comment that you have no time to fix it and the suggestion to take over maintenance if cared for. Of course we shouldn't put such packages on the DVD - and I need to go through your list checking :)
Yeah, sorting packages should be really recommended before RC -- not only about my packages but in general.
For those old ones that "can be dropped", I would prefer to see them really dropped if there is no user of it that is able to maintain it. But for things that are really adding value to the distribution I don't want to see them dropped _NOW_ because noone stepped up for 3 days.
Don't worry, maybe the target to drop will be 11.3, judging from the timeline. As I mentioned, the post was a sort of provocation :) Well, the problem is provocation as such won't help - it won't generate volunteers. Dropping the package might indeed generate volunteers, just as we have a vpnc package maintainer now again that's using it too :)
Heh, such a post alone can help often indeed, at least, to spark something. This is much much better than a post that no one reacts. Of course, this is no such a technique that one can use too often :)
But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more? I'm very well aware and openSUSE users will have to decide if it's worth to keep it alive or concentrate on scim and xemacs. Some packages in there are really outdated and noone really knows who is using them (and not even Mike knows about all of them I'm sure :) - I don't think we should have such packages. And if there are packages that are used by people and buggy, _then_ we need to convince these people to pick 'em. And yes, that "people" includes Novell managers - if anyway wants M17N packages fixed, he needs to find a way to get it fixed. But the whole "Novell does not control all of factory" concept is pretty new, so I would give it some more time to settle before claiming failure.
I don't call it a failure. But, many things are missing over here and there. I stated my questions to clarify the situation, and to lead to a constructive direction.
But again: we still need a way to evaluate if a package should be dropped, I'm just claiming that _now_ is a bad time for that :)
Agreed.
The situation of maintenance isn't so trivial right now in many areas; even though many packages are even on SLES. This is my honest and serious concern... Mine too, but we have way too many packages around to always have an active maintainer for them. So some staleness we will always have to live with.
Heh, the lack of resource is a generic problem of open-source development.
I got notified that my package would be removed from debian only after leaving it alone for 8 years - so even debian removes packages ;)
So we can wait for a few more years :) thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, Takashi Iwai wrote:
But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more?
Then obviously we can't have M17N stuff on openSUSE anymore.
The situation of maintenance isn't so trivial right now in many areas; even though many packages are even on SLES. This is my honest and serious concern...
Everybody is well aware of this situation. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 12:40:29 +0200, Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more?
Then obviously we can't have M17N stuff on openSUSE anymore.
Do you want it to be so? If not, what is your proposal to avoid it?
The situation of maintenance isn't so trivial right now in many areas; even though many packages are even on SLES. This is my honest and serious concern...
Everybody is well aware of this situation.
Yes, just like a world hunger or CO2 increase :) What people want to hear is rather how to stop it. thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, Takashi Iwai wrote:
At Thu, 10 Sep 2009 12:40:29 +0200, Henne Vogelsang wrote:
Takashi Iwai wrote:
But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more? Then obviously we can't have M17N stuff on openSUSE anymore.
Do you want it to be so?
Its not a question of me or anyone else wanting anything. The question is do we have resources to reasonably[1] maintain M17N stuff in openSUSE. If you, as someone involved in the devel project, say that we don't have resources then we simply _can't_. Even if you, me and everyone else want it.
If not, what is your proposal to avoid it?
My proposal was, from the beginning, that we break the 1:1 package:maintainer relation and people start to work in groups and share the load of responsibility and work. This way can carry more with less. I'm still hopeful that this will happen in the future.
The situation of maintenance isn't so trivial right now in many areas; even though many packages are even on SLES. This is my honest and serious concern... Everybody is well aware of this situation.
Yes, just like a world hunger or CO2 increase :) What people want to hear is rather how to stop it.
See above :) [1] Please note that reasonably can mean letting it bitrot until we find the time. What coolo calls "a certain staleness". -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 13:19:51 +0200, Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
At Thu, 10 Sep 2009 12:40:29 +0200, Henne Vogelsang wrote:
Takashi Iwai wrote:
But, the questions regarding the package maintainer is still quite open. One typical example is M17N repo. Since Mike left, we have no people working on this area. So I eventually volunteered to fix / improve the issues. But, if really no one takes care any more? Then obviously we can't have M17N stuff on openSUSE anymore.
Do you want it to be so?
Its not a question of me or anyone else wanting anything. The question is do we have resources to reasonably[1] maintain M17N stuff in openSUSE. If you, as someone involved in the devel project, say that we don't have resources then we simply _can't_. Even if you, me and everyone else want it.
That's true.
If not, what is your proposal to avoid it?
My proposal was, from the beginning, that we break the 1:1 package:maintainer relation and people start to work in groups and share the load of responsibility and work. This way can carry more with less. I'm still hopeful that this will happen in the future.
Yes, this is one thing. Another missing thing is, however, that each system needs regular health checks. If you are aware of lack of vitamin C, you can eat more fruits or tablets. If we are aware of SERIOUS lack of maintainability in certain areas, we can reassign resources from other areas (in theory). For a big project like openSUSE, we need health checks from both the macroscopic and the microscopic viewpoints. The former can't be done alone by devel projects. That is, you guys need to listen which part aches in the whole body. thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, Takashi Iwai wrote:
At Thu, 10 Sep 2009 11:09:33 +0200, Henne Vogelsang wrote:
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...? We probably should start thinking about creating a Community Security Team ... We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice?
There is no problem if you talk to the other project maintainers and they agree to maintain it (together or someone steps up). Only if you just drop the work on them without talking to them we have a problem. Just remember: * A devel project MUST have a maintainer * A package in a devel project MIGHT have a maintainer * A package in a devel project MIGHT have a bugowner I think this is also the general challenge we currently face. The transition of working alone on a package to working together in groups. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 12:36:53 +0200, Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
At Thu, 10 Sep 2009 11:09:33 +0200, Henne Vogelsang wrote:
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...? We probably should start thinking about creating a Community Security Team ... We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice?
There is no problem if you talk to the other project maintainers and they agree to maintain it (together or someone steps up). Only if you just drop the work on them without talking to them we have a problem.
Fair enough.
Just remember:
* A devel project MUST have a maintainer * A package in a devel project MIGHT have a maintainer * A package in a devel project MIGHT have a bugowner
I think this is also the general challenge we currently face. The transition of working alone on a package to working together in groups.
Right, and there are a few problem around here. So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group. However, the real problem is, that this situation hasn't been changed for months. I think we really have to consider this more deeply before we rushing into the release -- because most of bug reports come first after RC :) thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, Takashi Iwai wrote:
So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 12:59:24 +0200, Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though.
Just because don't know what to do? As a start, what about to forcibly create accounts for devel-proj maintainers, so that bugs can be assigned to them if uncertain? We need more whips, supposing it's still no dead horse. thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 10. September 2009 13:19:56 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 12:59:24 +0200,
Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though.
Just because don't know what to do?
As a start, what about to forcibly create accounts for devel-proj maintainers, so that bugs can be assigned to them if uncertain?
What do you mean with creating accounts ? Do you mean we should define a bugowner in each devel project ? Yes, I am all in favour for this. bye adrian
We need more whips, supposing it's still no dead horse.
thanks,
Takashi
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Sep 10, 2009 at 01:22:34PM +0200, Adrian Schröter wrote:
Am Donnerstag, 10. September 2009 13:19:56 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 12:59:24 +0200,
Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though.
Just because don't know what to do?
As a start, what about to forcibly create accounts for devel-proj maintainers, so that bugs can be assigned to them if uncertain?
What do you mean with creating accounts ?
Do you mean we should define a bugowner in each devel project ?
Yes, I am all in favour for this.
If you create a list you still need the subscribers per list to agree who is responsible, so this just defers the problem one step. Ciao, Marcus (enough experience with devnull team lists) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 13:27:36 +0200, Marcus Meissner wrote:
On Thu, Sep 10, 2009 at 01:22:34PM +0200, Adrian Schröter wrote:
Am Donnerstag, 10. September 2009 13:19:56 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 12:59:24 +0200,
Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though.
Just because don't know what to do?
As a start, what about to forcibly create accounts for devel-proj maintainers, so that bugs can be assigned to them if uncertain?
What do you mean with creating accounts ?
Do you mean we should define a bugowner in each devel project ?
Yes, I am all in favour for this.
If you create a list you still need the subscribers per list to agree who is responsible, so this just defers the problem one step.
Why do we need agreement? Many MLs (in this case rather aliases) start from people without explicit subscriptions. People can unsubscribe, i.e. step down from the maintainer late if they can't live with that. Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Sep 10, 2009 at 01:36:03PM +0200, Takashi Iwai wrote:
At Thu, 10 Sep 2009 13:27:36 +0200, Marcus Meissner wrote:
On Thu, Sep 10, 2009 at 01:22:34PM +0200, Adrian Schröter wrote:
Am Donnerstag, 10. September 2009 13:19:56 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 12:59:24 +0200,
Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though.
Just because don't know what to do?
As a start, what about to forcibly create accounts for devel-proj maintainers, so that bugs can be assigned to them if uncertain?
What do you mean with creating accounts ?
Do you mean we should define a bugowner in each devel project ?
Yes, I am all in favour for this.
If you create a list you still need the subscribers per list to agree who is responsible, so this just defers the problem one step.
Why do we need agreement? Many MLs (in this case rather aliases) start from people without explicit subscriptions. People can unsubscribe, i.e. step down from the maintainer late if they can't live with that.
The issue is that they will become empty lists at some point in time. And then we would have to take some kind of action, Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Thu, 10 Sep 2009 13:52:57 +0200, Marcus Meissner wrote:
On Thu, Sep 10, 2009 at 01:36:03PM +0200, Takashi Iwai wrote:
At Thu, 10 Sep 2009 13:27:36 +0200, Marcus Meissner wrote:
On Thu, Sep 10, 2009 at 01:22:34PM +0200, Adrian Schröter wrote:
Am Donnerstag, 10. September 2009 13:19:56 schrieb Takashi Iwai:
At Thu, 10 Sep 2009 12:59:24 +0200,
Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote: > So far, not all (maybe most of) devel projects have tight > communication channels for maintainers, even no dedicated MLs. Thus, > no real consensus has been made wrt how to handle bugs as a group.
True and thats exactly the problem we are facing all over the place. People just not doing anything. I'm not sure why though.
Just because don't know what to do?
As a start, what about to forcibly create accounts for devel-proj maintainers, so that bugs can be assigned to them if uncertain?
What do you mean with creating accounts ?
Do you mean we should define a bugowner in each devel project ?
Yes, I am all in favour for this.
If you create a list you still need the subscribers per list to agree who is responsible, so this just defers the problem one step.
Why do we need agreement? Many MLs (in this case rather aliases) start from people without explicit subscriptions. People can unsubscribe, i.e. step down from the maintainer late if they can't live with that.
The issue is that they will become empty lists at some point in time. And then we would have to take some kind of action,
Yes, we need definitely some checks and controls over the whole projects. Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 10 Sep 2009, Takashi Iwai wrote:
At Thu, 10 Sep 2009 12:36:53 +0200, Henne Vogelsang wrote:
Hi,
Takashi Iwai wrote:
At Thu, 10 Sep 2009 11:09:33 +0200, Henne Vogelsang wrote:
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...? We probably should start thinking about creating a Community Security Team ... We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice?
There is no problem if you talk to the other project maintainers and they agree to maintain it (together or someone steps up). Only if you just drop the work on them without talking to them we have a problem.
Fair enough.
Just remember:
* A devel project MUST have a maintainer * A package in a devel project MIGHT have a maintainer * A package in a devel project MIGHT have a bugowner
I think this is also the general challenge we currently face. The transition of working alone on a package to working together in groups.
Right, and there are a few problem around here. So far, not all (maybe most of) devel projects have tight communication channels for maintainers, even no dedicated MLs. Thus, no real consensus has been made wrt how to handle bugs as a group.
However, the real problem is, that this situation hasn't been changed for months. I think we really have to consider this more deeply before we rushing into the release -- because most of bug reports come first after RC :)
How about creating a Orphaned devel project and moving stuff that gets dropped from Factory there? Richard. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Richard Guenther wrote:
How about creating a Orphaned devel project and moving stuff that gets dropped from Factory there?
We already have Dropped project. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Donnerstag, 10. September 2009 12:36:53 schrieb Henne Vogelsang:
Hi,
Takashi Iwai wrote:
At Thu, 10 Sep 2009 11:09:33 +0200,
Henne Vogelsang wrote:
Pavol Rusnak wrote:
Takashi Iwai wrote:
OK, will do. But, what should we do really for security issues...?
We probably should start thinking about creating a Community Security Team ...
We did and have already volunteers. See the thread,
[opensuse-factory] openSUSE 11.2 and maintenance http://lists.opensuse.org/opensuse-factory/2009-08/msg00372.html
So, actually there is no problem to keep the maintainer and bugowner of OBS devel packages empty in practice?
There is no problem if you talk to the other project maintainers and they agree to maintain it (together or someone steps up). Only if you just drop the work on them without talking to them we have a problem.
Just remember:
* A devel project MUST have a maintainer * A package in a devel project MIGHT have a maintainer * A package in a devel project MIGHT have a bugowner
But if the packages do not have bugowners, the project needs one. Some projects, like KDE4:Factory:Desktop or GNOME:Factory have only a project global bugowner (what is fine). bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Wed, 09 Sep 2009 17:36:06 +0200, Pavol Rusnak wrote:
Takashi Iwai wrote:
I'm going to send deletereq to FACTORY unless any one can pick them up.
Isn't it better to leave them in Factory so someone in the future could take care of them? What benefits brings dropping from Factory?
The problem is rather the responsibility to (future) bug reports. Packing is relatively easy. But, handling bugs isn't always easy. Basically this is still an open question to me -- who will handle any security issues if the packages are orphaned? Also, another reason of the text above is to provoke people for keeping attentions. That seems working fine, at least ;) thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 09/07/2009 06:06 PM, Takashi Iwai wrote:
Hi,
some of the packages currently assigned to me need other maintainers who can give more love.
If any of you find a package below interesting, please let me know.
================================================================ cachefilesd The new feature of 2.6.31 kernel; Maybe not much work compcache Compressed RAM swap, including KMP Experimental packages for the time being csound Can be dropped from FACTORY, maintained on multimedia:apps dssi Can be dropped from FACTORY, maintained on multimedia:libs fftw Old FFTW2; very stable, so far nothing needed except for minor build fixes fftw3 New FFTW3; a newer version expected to be released soon, but for openSUSE-11.3 fluidsynth Can be dropped from FACTORY, maintained on multimedia:libs freqtweak Very old; can be dropped from FACTORY gamix Very old; can be dropped from FACTORY gnash Opensource flash player; recently quiet; Can be dropped from FACTORY gwc Old program; can be dropped hydrogen Can be dropped from FACTORY icecast Can be dropped from FACTORY ices Can be dropped from FACTORY jack Old JACK-0.x; Maybe JACK-2.x will be on the future distro jack-rack Can be dropped from FACTORY jackEQ Can be dropped from FACTORY jamin Can be dropped from FACTORY ladspa Needs updates of some plugins; another idea would be to split this to several packages lash Can be dropped from FACTORY latencytop Fairly stable libao Fairly stable libatomic-ops-devel Just copied from Debian libfreebob Old package, can be dropped libid3tag Can be dropped libjackasyn Can be dropped liblo Can be dropped liblrdif Can be dropped libsamplerate Fairly stable libshout Fairly stable mercurial Active development, a newer version will come sooner or later meterbridge Old package; can be dropped pmidi Old package; can be dropped portaudio No active development? Can be dropped qjackctl Fairy stable, spontaneous updates resample Can be dropped rosegarden4 Can be dropped seq24 Can be dropped snd Can be dropped solfege Can be dropped soundtracker Old package; can be dropped stgit Stable, can be dropped swami Old package; should be updated to the unstable version or dropped sweep Can be dropped timidity can be dropped ================================================================
thanks,
Takashi
I'll take on rosegarden4, obs username plater Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Wed, 23 Sep 2009 21:16:48 +0200, Dave Plater wrote:
On 09/07/2009 06:06 PM, Takashi Iwai wrote:
Hi,
some of the packages currently assigned to me need other maintainers who can give more love.
If any of you find a package below interesting, please let me know.
================================================================ cachefilesd The new feature of 2.6.31 kernel; Maybe not much work compcache Compressed RAM swap, including KMP Experimental packages for the time being csound Can be dropped from FACTORY, maintained on multimedia:apps dssi Can be dropped from FACTORY, maintained on multimedia:libs fftw Old FFTW2; very stable, so far nothing needed except for minor build fixes fftw3 New FFTW3; a newer version expected to be released soon, but for openSUSE-11.3 fluidsynth Can be dropped from FACTORY, maintained on multimedia:libs freqtweak Very old; can be dropped from FACTORY gamix Very old; can be dropped from FACTORY gnash Opensource flash player; recently quiet; Can be dropped from FACTORY gwc Old program; can be dropped hydrogen Can be dropped from FACTORY icecast Can be dropped from FACTORY ices Can be dropped from FACTORY jack Old JACK-0.x; Maybe JACK-2.x will be on the future distro jack-rack Can be dropped from FACTORY jackEQ Can be dropped from FACTORY jamin Can be dropped from FACTORY ladspa Needs updates of some plugins; another idea would be to split this to several packages lash Can be dropped from FACTORY latencytop Fairly stable libao Fairly stable libatomic-ops-devel Just copied from Debian libfreebob Old package, can be dropped libid3tag Can be dropped libjackasyn Can be dropped liblo Can be dropped liblrdif Can be dropped libsamplerate Fairly stable libshout Fairly stable mercurial Active development, a newer version will come sooner or later meterbridge Old package; can be dropped pmidi Old package; can be dropped portaudio No active development? Can be dropped qjackctl Fairy stable, spontaneous updates resample Can be dropped rosegarden4 Can be dropped seq24 Can be dropped snd Can be dropped solfege Can be dropped soundtracker Old package; can be dropped stgit Stable, can be dropped swami Old package; should be updated to the unstable version or dropped sweep Can be dropped timidity can be dropped ================================================================
thanks,
Takashi
I'll take on rosegarden4, obs username plater
Thanks, assigned now. Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (11)
-
Adrian Schröter -
aledr -
Dave Plater -
Henne Vogelsang -
Marcus Meissner -
Pavol Rusnak -
Petr Baudis -
Richard Guenther -
Stephan Kulow -
Takashi Iwai -
Vincent Untz