[arch-dev-public] Package cleanup - implementation - Arch-dev-public

[arch-dev-public] Package cleanup - implementation

older
[arch-dev-public] mkinitcpio 0.5.14

Aaron Griffin

11 May 2007 11 May '07

9:30 p.m.

This is a note for the developers. If you haven't seen the busy thread on the general list regarding package cleanup, this wiki page should cover everything: http://wiki.archlinux.org/index.php/Package_Cleanup Before the end of the weekend, I'm going to move most of these packages based on what is there. There are a few that are questionable, however, so please voice you opinions if you don't want things touched. Thanks Aaron

Show replies by thread

Thomas Bächler

11 May 11 May

10:21 p.m.

Aaron Griffin schrieb:

...

This is a note for the developers. If you haven't seen the busy thread on the general list regarding package cleanup, this wiki page should cover everything:

http://wiki.archlinux.org/index.php/Package_Cleanup

Before the end of the weekend, I'm going to move most of these packages based on what is there. There are a few that are questionable, however, so please voice you opinions if you don't want things touched.

I'm fine with most of it, just two things: - Don't touch beryl. It will be replaced with compiz when the time comes. - I'd like to keep ogle until dvdnav support in mplayer is stable. Despite being unmaintained upstream, it is still a good player (with a few issues, I know) - I don't know why we would move i18n stuff out of extra. The "default is english, would take a lot of load away" seems arrogant, at best. - loosing bittorrent is good IMO, it has become slow and bloated. It uses 25% CPU on a friend's Athlon X2 3800+. Sad that utorrent has no linux version (yet), it is THE standard bt client for windows (fast, feature-rich, small, clean).

Dan McGee

10:29 p.m.

On 5/11/07, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...
This is a note for the developers. If you haven't seen the busy thread on the general list regarding package cleanup, this wiki page should cover everything:

http://wiki.archlinux.org/index.php/Package_Cleanup

Before the end of the weekend, I'm going to move most of these packages based on what is there. There are a few that are questionable, however, so please voice you opinions if you don't want things touched.

- I don't know why we would move i18n stuff out of extra. The "default is english, would take a lot of load away" seems arrogant, at best.

The issue here is shifting the maintenance away from the devs to a set of TUs, not dropping i18n support from Arch Linux. Let me point out a few pros and cons. Pros: 1. More maintainers = more testing and frequent updates. Instead of only allowing devs to update the localizations, we allow TUs to do this as well. Devs should have no problem still doing this as well- they should be able to update anything in community if necessary. 2. It separates the building tasks (package and l10n), allowing the developer to focus more on the package and others on the localizations. This would hopefully encourage developers to do better testing. 3. ? Cons: 1. People may frown a bit upon 'community' taking a more official role, although I think this perception should be changed. 2. ? Fill in the blanks if you got reasons. -Dan

Aaron Griffin

10:36 p.m.

On 5/11/07, Thomas Bächler wrote:

...

- Don't touch beryl. It will be replaced with compiz when the time comes. Deal.

...

- I'd like to keep ogle until dvdnav support in mplayer is stable. Despite being unmaintained upstream, it is still a good player (with a few issues, I know)

For similar reasons, I want to keep muttng where it is, as I like it far more than mutt and it's much faster. I'm sure jeff (and maybe jason?) would agree.

...

- I don't know why we would move i18n stuff out of extra. The "default is english, would take a lot of load away" seems arrogant, at best.

That was my gut reaction too. However, I know nothing about how this pans out, being a native english speaker... still, it might be worthwhile to push some of it to community and allow actual speakers of said language to maintain them, so that we aren't maintaining packages no one uses (like german, we have no german users at all, heh).

...

- loosing bittorrent is good IMO, it has become slow and bloated. It uses 25% CPU on a friend's Athlon X2 3800+. Sad that utorrent has no linux version (yet), it is THE standard bt client for windows (fast, feature-rich, small, clean).

I agree we have much better alternatives. ctorrent and transmission are my favorites.

Thomas Bächler

10:41 p.m.

Dan McGee schrieb:

...

Pros: 1. More maintainers = more testing and frequent updates. Instead of only allowing devs to update the localizations, we allow TUs to do this as well. Devs should have no problem still doing this as well- they should be able to update anything in community if necessary. 2. It separates the building tasks (package and l10n), allowing the developer to focus more on the package and others on the localizations. This would hopefully encourage developers to do better testing. 3. ?

Cons: 1. People may frown a bit upon 'community' taking a more official role, although I think this perception should be changed. 2. ?

I can give the example of firefox/thunderbird here: Their i18n packages should be updated the same time as the main package, else localization will break (that is reflected with a pkg=ver depend in these cases). So having the i18n package in a repo the main package maintainer has no access to is not a good idea.

Aaron Griffin

10:46 p.m.

On 5/11/07, Thomas Bächler wrote:

...

having the i18n package in a repo the main package maintainer has no access to is not a good idea.

Just a quick clarification - all developers have access to the community repo, and this is reflected in the AUR interface as well.

Simo Leone

11:01 p.m.

On Fri, May 11, 2007 at 05:46:22PM -0500, Aaron Griffin wrote:

...

On 5/11/07, Thomas Bächler wrote:

...
having the i18n package in a repo the main package maintainer has no access to is not a good idea.

Just a quick clarification - all developers have access to the community repo, and this is reflected in the AUR interface as well.

And a quick clarification on that clarification (oh how recursive sounding!), many devs don't have access simply because they haven't had the need and haven't asked. But all you need to do is ask and it takes about 10 seconds to set up. -S

Thomas Bächler

11:38 p.m.

Aaron Griffin schrieb:

...

...
- I don't know why we would move i18n stuff out of extra. The "default is english, would take a lot of load away" seems arrogant, at best.

That was my gut reaction too. However, I know nothing about how this pans out, being a native english speaker... still, it might be worthwhile to push some of it to community and allow actual speakers of said language to maintain them, so that we aren't maintaining packages no one uses (like german, we have no german users at all, heh).

Maybe we should make a poll or something on what languages our user speak and which localized packages are actually required. Most packages provide gettext localizations, but some (kde, koffice, openoffice, firefox, thunderbird, ...) need extra packages. If you want, I could put a small poll script together (that is, if I can get access to mysql).

Roman Kyrylych

12 May 12 May

11:20 a.m.

2007/5/12, Thomas Bächler :

...

Aaron Griffin schrieb:

...
...
- I don't know why we would move i18n stuff out of extra. The "default is english, would take a lot of load away" seems arrogant, at best.

That was my gut reaction too. However, I know nothing about how this pans out, being a native english speaker... still, it might be worthwhile to push some of it to community and allow actual speakers of said language to maintain them, so that we aren't maintaining packages no one uses (like german, we have no german users at all, heh).

Maybe we should make a poll or something on what languages our user speak and which localized packages are actually required. Most packages provide gettext localizations, but some (kde, koffice, openoffice, firefox, thunderbird, ...) need extra packages.

I'd like to have all available localized packages maintained in the same way. Splitting them by "popularity" is a bad idea IMO. About community and access rights - I think most (if not all) will need access there because many of their favourite packages will be moved there, and while we're moving to shared maintainership philosophy - it's always better if more people who care about given package can update it. -- Roman Kyrylych (Роман Кирилич)

James

12:28 p.m.

On 5/12/07, Roman Kyrylych wrote:

...

2007/5/12, Thomas Bächler :

...
Aaron Griffin schrieb:

...
...
- I don't know why we would move i18n stuff out of extra. The "default is english, would take a lot of load away" seems arrogant, at best.

That was my gut reaction too. However, I know nothing about how this pans out, being a native english speaker... still, it might be worthwhile to push some of it to community and allow actual speakers of said language to maintain them, so that we aren't maintaining packages no one uses (like german, we have no german users at all, heh).

Maybe we should make a poll or something on what languages our user speak and which localized packages are actually required. Most packages provide gettext localizations, but some (kde, koffice, openoffice, firefox, thunderbird, ...) need extra packages.

I'd like to have all available localized packages maintained in the same way. Splitting them by "popularity" is a bad idea IMO.

About community and access rights - I think most (if not all) will need access there because many of their favourite packages will be moved there, and while we're moving to shared maintainership philosophy - it's always better if more people who care about given package can update it.

Whoever's doing this, please be more careful. There was an objection to muttng on the bottom of the wikipage, but it's been moved to the aur anyway. And as for i18n, leave it in the repositories for now imho, we can make an i18n repository later. To remove it entirely, is totally arrogant and rude. James -- iphitus // Arch Developer // iphitus.loudas.com

Dan McGee

4:36 p.m.

On 5/12/07, James wrote:

...

And as for i18n, leave it in the repositories for now imho, we can make an i18n repository later. To remove it entirely, is totally arrogant and rude.

I don't think we are ready to go ahead with any i18n moving as no one has a real great plan of action, so this will definitely wait. -Dan

Aaron Griffin

8:14 p.m.

On 5/12/07, James wrote:

...

Whoever's doing this, please be more careful. There was an objection to muttng on the bottom of the wikipage, but it's been moved to the aur anyway.

I asked some people to move to unsupported while I was away. Nothing was removed from CVS yet - still muttng was unmaintained - I'll probably maintain it in community if no one else wants it.

6204

Age (days ago)

6205

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Aaron Griffin
Dan McGee
James
Roman Kyrylych
Simo Leone
Thomas Bächler