- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] [arch] Archlinux [current] status
by Dan McGee 08 May '07

08 May '07

Kludging a few emails together here. > Am Dienstag, 8. Mai 2007 22:30:59 schrieb Tobias Powalowski: > > Hi > > something is really going wrong at the moment. > > People claim for having other interests or not time for doing the packaging > > work. > > I start here only with [current] first. > > Jan quit doing maintenance of important parts of our distro and probably > > also of doing quite some update tirades through current. > > > > Let me stress this, from my point of view Jan and me did the most [current] > > updates the last weeks, even if we didn't use the software for our own > > stuff, correct me if im wrong. I for one do not have access to [current]. I would be plenty willing to help out with maintenance there, although I am not as keen on adopting packages. More on this below. > > We have inactive package maintainers, no doubt. > > Judd, Dorphell, Aurelien, Gregor, Woody, Arjan > > > > It's time to cleanup [current]. > > Orphan all packages of Judd, Dorphell, Aurelien, Gregor > > 1 week of time to grab what packages you wanna have. > > Keep in mind it's your job then to test and ensure that the package works! > > Please one of the enablers do this, or give me the permission to orphan > > them. This could make sense, however I would like to state that a single maintainer of a package may be the wrong way to think about this, even before we do any kind of repository reorganization. If two people want to maintain a package, that should not be an issue as long as people don't have problems when people touch "their" packages. By the way, a lot of Judd's packages are marked out of date- someone should take a look at some of these and update if necessary. > > After that period, look whats left if noone feels responsable for a package > > make a list of possible drops or try to find one on ML who wants to > > maintain it. It's better to have 1 maintainer for just 1 package who is > > active and knows the package well, then 1 who just cross updates because he > > saw the version bump. I might disagree with part of this- a roving maintainer that knows and can test the packages he is updating is still a good thing. On 5/8/07, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Well, I see the point. Perhaps there too much packages in [current] and > [extra] for too few devs. (compare: there are less packages in [community] > but we have more active TUs than Devs) I brought up this exact point a while back and it died on the ML: <http://archlinux.org/pipermail/arch-dev-public/2007-April/000517.html> > I don`t see any problem in stripping down [current] and [extra] to only those > packages which are really used. E.g. there are some experimntal ones like > beryl, several unstable kernels like ck, beyond, mm etc. which will do well > in [community]. I agree with this- extra is gigantic right now. Anything that we no longer feel belongs in extra should get announced to the TU list, where anyone can claim it if they use it. If not, drop it down to unsupported. > Perhaps there should be a guideline which package has to be part of the core > distribution. For example: if a TU becomes a DEV he often moves all his > packages to extra. Esspecially for Arch64 this causes some problems because > we TUs wont be able to help by porting those packages. I don't think that this should be the norm. On 5/8/07, Andreas Radke <a.radke(a)arcor.de> wrote: > Am Tue, 8 May 2007 14:33:04 -0700 schrieb Tobias Kieslich <tobias(a)justdreams.de>: > > 4. Arch64 is a 2 man show, Andy and ise. There should be some more > > support for them. I really think we should add some people here. ISE, > > write a mail to Jason to get access to current. Andy, Ise, how many > > people do you want and do you have suggestions? > > we both already have cvs access to all repos. we are still not allowed > to maintain packages. we are not listed in the dashboard. but if this > would change we would have to decide how to make i686 devs rebuild the > packages that are maintained by x86_64 devs. I tacked this on as a postscript in one of my other emails and no one responded. I feel like we should not exclude our x86_64 devs from maintaining packages. This requires a few changes in thought: 1. When you are the maintainer of a package, you are in charge of the package as a whole in addition to your own architecture. This means seeking out patches if necessary, etc. 2. People need to release a little control sometimes and not treat a package as their own. It is the community's package, any capable dev should be able to decide what is best for the package. If there is disagreement, then bring it up on the ML. > also i got dissapointed by some fresh x86_64 users we brought up here > that left us quicker than we thought. This should be a big role in deciding future dev/TU consideration, hopefully, especially for those brought on as package maintainers. -Dan

1 0

[arch-dev-public] [opening] Koffice maintainership
by Alexander Baldeck 08 May '07

08 May '07

Hey all, I took over many packages including X.org and thus my number of maintained packages went up to 280. So, I have a few packages to give away that are basicly the Koffice environment. I don't do the office kind of thing all that often anymore. Then again, I don't want to orphan them, nor do I want them to be moved to the AUR. Also, it would be nice if there was somebody new to maintain them. Send me a mail and we can talk about it. List of Packages: koffice koffice-doc koffice-l10n-ca koffice-l10n-cs koffice-l10n-cy koffice-l10n-da koffice-l10n-de koffice-l10n-el koffice-l10n-en_gb koffice-l10n-es koffice-l10n-et koffice-l10n-eu koffice-l10n-fi koffice-l10n-fr koffice-l10n-hu koffice-l10n-it koffice-l10n-ja koffice-l10n-lv koffice-l10n-ms koffice-l10n-nb koffice-l10n-nl koffice-l10n-pl koffice-l10n-pt koffice-l10n-pt_br koffice-l10n-ru koffice-l10n-sk koffice-l10n-sl koffice-l10n-sr koffice-l10n-sv koffice-l10n-tr koffice-l10n-uk koffice-l10n-zh_cn koffice-l10n-zh_tw

1 0

[arch-dev-public] pacman 3 to current
by Dan McGee 08 May '07

08 May '07

If there are no objections in the next half-day or so, we (Aaron and I) would like to push pacman 3 to current. This is the only possible showstopper I know of that is not fixed in 3.0.3: <http://bugs.archlinux.org/task/7063> It is easily patched on the package building end, rather than release a 3.0.4 release. Let us know ASAP if this shouldn't happen tonight. -Dan

2 1

[arch-dev-public] Beyond is discontinued.
by James 07 May '07

07 May '07

It was fun while it lasted, but it's come down to this. I simply no longer have the time, or motivation to develop beyond. Uni and life are taking up more of my time, and I'd rather spend what time i have at the computer pursuing things of interest. I no longer see the point in beyond, and have not used for any extended period for months. I'm sick of the kernel. It's crap. Every release breaks something new, and every release is as poorly tested as the last. (not you tpowa, I mean upstream -- you do a good job with what you're given by them) The stable tree, isn't stable. I want something that works and won't break. This email was not sent on a whim, I've thought about this for a while, and have realised, that there's not going to be a decent release in the near future and i'd prefer to not lead people on any further. Honestly, I don't think I've put out a good release in over 6 months. It's hard to drop a successful 2 year old project. I didn't want this to happen, but unless someone steps up to maintain beyond, it's now discontinued. Sorry guys. James Addendum: z4ziggy & dtw: kernel26 now has unionfs and squashfs. It's also somewhat more stable and reliable than beyond ever was. Consider it the successor. I know it doesn't have fbsplash... but you could build a patched version, and if you only add fbsplash, it should retain compatibility with the modules. Beyond name & maintainership: I still hold these, please email me personally if you're interested in taking over. I don't want some stupid ricer full of omgoptimised using the beyond name. Users: sorry guys. Maybe someone else will step up? I don't plan to put any of the other patch sets in the repository in place of beyond. If someone else maintains beyond to an acceptable standard, maybe i'll update it. -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2 1

[arch-dev-public] [objectives] Package triage on current + extra (archstats)
by Dan McGee 07 May '07

07 May '07

I know we weren't supposed to rush into the objectives here before settling on the goals, but I think this is an important one to examine, especially with a change in the repository structure happening in the coming months. How many of the devs are using archstats, let alone users? After looking at it a bit more today, I realized this could be a great asset to finding areas where devs should be spending their time with regard to package maintenance. It would also help us out greatly when it comes to determining which packages should no longer be maintained by us and dropped back to the TU level and/or unsupported. However, a few things need work: 1. The current website <http://www.archlinux.org/~simo/archstats/index.php> is in dire need of an overhaul. Using the old website theme is the least of our worries- things like the package listing are at this point rather unusable and only suck 223 MB of memory in Firefox once fully loaded. I have a lot of ideas for this here- enable breakdown by pkgname only (so it actually looks like people are running kernel26), limit number of results on the page unless someone actually selects to see them all, etc. 2. The archstats database. It contains several one-time system updates, and several systems that haven't updated since 2005 or earlier. This is clearly junk data, and to make archstats useful we should probably just start fresh, and find a way to cut down on spurious commits, which leads into... 3. The archstats program itself. In the last week, I've had no problems with it, but have had problems before (some of the spurious commits above were definitely my fault). Configuration should probably be editable in a conf file (the current /etc file has a big fat warning saying do not edit by hand- this seems not the Arch Way). Setting it up as a cron job is straightforward, but if we want people to use it we should probably think of a way to make it even easier. Comments on any of this? I know its yet another project idea to be thrown out there, but this one could prove very helpful and in the long run vastly reduce dev maintenance of package when we realize very few users are actually using a package and it should be maintained elsewhere. -Dan

5 9

[arch-dev-public] lingering x86_64 mythtv bug
by Paul Mattal 05 May '07

05 May '07

Can the Arch64 folks compiling mythtv have a look at this bug? It seems only to be a problem in the Arch64 binary package. http://bugs.archlinux.org/task/5944 - P

1 0

[arch-dev-public] Linuxtag: Staff meeting Saturday 12th 4pm CEST
by Christoph Neuroth 05 May '07

05 May '07

Hi, anyone who wants to help making Linuxtag a nice event again, please try to make it to Freenode/#arch-lt on Saturday 4pm Berlin time so we can discuss remaining topics, as there are: * Arrival/Departure schedules (someone needs to set up and dismantle the booth) * Poster printing * Organizing some shirts with arch logos so vistors know who they can talk to * CD Burning, CD sleeves * other needed stuff Feel free to bring up any other topics you can think of. Also please make sure that I have your full name so I can order exhibitor passes for you. Currently, I ordered passes for Alex, Andreas, Tobias and Jan. And finally if you need some tickets for your friends to be able to visit the fair, I have been given 24 e-tickets that I can share. As in the last years, I will need the full name and a valid email address to send them to you. chris

3 2

[arch-dev-public] On vacation
by Varun Acharya 04 May '07

04 May '07

I'm taking a big long break from 5th-24th May, during which I probably wont have access to even an internet connection. 32bit TU's please help out with community64 if you can .. the difflist is here http://www.archlinux.org/~andyrtr/pkg_diff.html. Thanks, Bye, Varun

1 0

Re: [arch-dev-public] [arch-dev] [goals] i18n
by Jason Chu 04 May '07

04 May '07

On Thu, May 03, 2007 at 11:18:15PM +0200, Andreas Radke wrote: > i'm against offering any localization from the devs. it's a big amount > of packages we don't know how important they are or better how often > they are used*. Is there some way we can find this out instead of just guessing one way or the other? > arch is developed and documented primarly in english and so we should > concentrate to offer a good en_US.utf8 base. nothing more from the core. I don't see why we can't also have good i18n support. > i suggest to lay i18n packages back into the community's hand. those > packages are often easy to maintain but a hell of work for the > rebuilders. Don't the people who maintain these packages have scripts that will just build them all? Jason

1 0

[arch-dev-public] [goals] i18n
by Dan McGee 03 May '07

03 May '07

And why was this on arch-dev and not the public list? Forwarding it there. ---------- Forwarded message ---------- From: Dan McGee <dpmcgee(a)gmail.com> Date: May 3, 2007 6:03 PM Subject: Re: [arch-dev] [goals] i18n To: Development Discussion for Arch Linux <arch-dev(a)archlinux.org> On 5/3/07, Andreas Radke <a.radke(a)arcor.de> wrote: > i'm against offering any localization from the devs. it's a big amount > of packages we don't know how important they are or better how often > they are used*. > > arch is developed and documented primarly in english and so we should > concentrate to offer a good en_US.utf8 base. nothing more from the core. > > i suggest to lay i18n packages back into the community's hand. those > packages are often easy to maintain but a hell of work for the > rebuilders. > > Andy > > > > *we should improve archstat to show summarized output for the amount of > one pkgname. that could help a lot for our wanted repo cleanup. Quick thoughts on this, and not sure of the full implementation but it seems like a good idea in my head. Why don't we have an [i18n] repo, just as community and extra are repos? This should be administered under a separate set of permissions, so those that update these packages are not necessarily either TUs or Devs, but other users that have taken on the responsibility of maintaining localization packages. Key to this is some kind of permissions based thing- perhaps a certain user should only be able to modify FR localization packages, for instance. The system should support that, and it seems like pre-commit hooks in nearly all VCS systems should be able to enforce these permissions on a package or repo-level basis. This is another topic though. -Dan

1 0