[arch-dev-public] Status Report 24-09-2007
Hey all, One of the things I plan on doing, for myself and for all of us, is sending out a little "what's going on in devland" status report ever Monday.
So here's the very first one! Please, if you can, split off any discussion to other threads, and only use this one for missed milestones that I may have forgotten.
So without further ado:
----------------- ArchLinux Status Report, 24-09-2007
== Completed Tasks ==
* PHP Modularization Pierre completed a rehash of our php package, making it smaller, more agile, and modular. The full details can be found in another thread on the private list. Pierre, would you mind pushing the details somewhere so the public can see?
* Move to [core] Repo
I want to send a special "Thanks" out to everyone who participated in this. It was a long time coming, and it definitely gives us more of an idea of what's going on overall. So thanks guys, you all deserve it!
* ISO Naming Scheme decision
We will be using YYYY.MM-REL for ISO versioning, where REL is the release number of this ISO. For internal and testing ISOs, we will use the point release scheme popularized by the x86_64 architecture. For instance, 2007.12-1.5 is the 5th internal/testing release.
To prevent complication, we will start with release 0 for these testing releases, so 0.1 should be the first internal release
* GNOME 2.20 in [testing]
If you are a GNOME user please take the time to test this, and let Jan know if there are any issues - please put them in the bug tracker.
* X.org 7.3 in [testing]
This release will probably need a lot of testing, especially with nvidia and fglrx drivers. Please test if you can.
== Pending Tasks, Short Term ==
* New Round of Package Cleanup
Eric will be leading the charge here. This will mostly be internal to the developers as we will get rid of packages that are not compatible between architectures and packages which no longer build or are just broken.
* DVD and Additional Package ISOs
We need to decide on what exactly we're shipping on these "extra" iso images. Thomas seems to have the idea mostly in hand, so I'd like him to lead the discussion here (if that's ok with you)
* Unified chroot build tools
I am in the process of creating a script to aid us all in building packages in a clean chroot. We should all be doing this whenever possible.
I told you all I'd get this out by this weekend, but I failed. Sorry. I will spend tonight getting this prepped. Again, I apologize.
* Use vendor_perl for pacman perl packages
This is an easy bug to fix, it's just tedious. http://bugs.archlinux.org/task/8082
If someone has the time, I'd like to see this accomplished sometime this week. Any volunteers?
* Move all Arch related projects to gerolde
This is just a reminder - mainly to myself and Jason, and maybe Paul. We'd like to get all Arch oriented projects in a common location so we can all work on them and users can peek at things to see if they could contribute at all.
http://bugs.archlinux.org/task/7789
* Next ISO Release Date
I'd like to remain in the loop here. Could anyone project the next kernel release date and how long the ISO will take from the time of release? I'd like to start with (see above) a -0.1 release for internal and testing stuff, and give that a few days, then release a -1 version.
* Upcoming Rebuilds
Andy mentioned some incoming rebuilds for some libs and things like db. Is there any word on the schedule for these releases? Andy, could you fill us in?
* DB Script Rewrite
Our DB scripts are kinda messy and are in a serious need of a rewrite. Thomas and I have planned to sit down and fix these things, but if anyone else is interested, I'd like to start planning a "sprint", if you will, shortly.
* Orphan Packages
This is another one Andy brought up. We have A LOT of orphan packages. We need someone to evaluate all of these orphans, to see if we should 1) still support them or move them "down" to community/unsupported 2) get someone to maintain them.
Seeing as Andy is concerned with this, could you take the reins here? Collaborating with Eric on the package cleanup is probably a good thing too.
== Pending Tasks, Long Term ==
* Pacman 3.1 Release
Dan and I are going to be working towards a 3.1 pacman release. Please attach bugs you feel are critical to this here:
http://bugs.archlinux.org/task/8109
Dan and I will sort it out.
* Official pacbuild usage
This is Jason's boat. I'd like to get him some help here. The more hands we can get in pacbuild, the faster we can start using it.
* 'Continuous Integration' setup / machine
This is a pipedream of mine. I'd like to setup a CI server somewhere. For those unfamiliar with the term, what this means is that the server will, periodically, check out our PKGBUILDs and try to build ever single package. Clean chroots don't matter, what we're checking is whether it will build as the instructions say. I guess a pacbuild instance COULD be used here, but this should be a simple bash script. If anyone wants to do something fun, feel free to jump on this one, but otherwise it's not important.
* Multiple Maintainers on the Dashboard
Yeah yeah this has been around for a while. We need to hack at our django code, so we can have multiple maintainers per package. Right now Eliott and Simo are the only ones with their hands in this code. If anyone else has the desire to jump into this code, please help out with this. It's something we are in dire need of.
* Multiple Architectures on the Dashboard
This is the same as above, BUT we need support for packages in all architectures, AND the ability to assign different maintainers to each architecture (not all of us can build for more than one arch).
* ArchCon 2009: Big Baaad Idea
So Tom K started this one, and, well, let's just throw it out there. http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html
The tentative idea, which might be just a pipedream, is to get all the devs and users, or as many as possible, together for a big-ol' meet up.
Let's see how this pans out. -----------
Well, there it goes. Monday status report for Arch devland.
I threw a few questions in there, feel free to use this thread for that, but lets not pollute things with long-winded discussion - break those off and help make our mail clients happy.
Thanks for all your hard work guys, Aaron
Monday 24 September 2007, Aaron Griffin wrote: | "what's going on in devland" status report ever Monday.
you rock!
that's what i am doing in another project of mine (but biweekly) and it really helps keeping the team focused. i was thinking that doing it in arch would help, but always thought that we can also without, since it is small and everybody keeps updated anyway... but we have grown over the years and i must say, i welcome your initiative!
one miniscule remark: can you change the date in the subject to 2007-09-24 respectively YYYY-MM-DD, please? :)
- D
On 9/25/07, Damir Perisa damir.perisa@solnet.ch wrote:
Monday 24 September 2007, Aaron Griffin wrote: | "what's going on in devland" status report ever Monday.
you rock!
that's what i am doing in another project of mine (but biweekly) and it really helps keeping the team focused. i was thinking that doing it in arch would help, but always thought that we can also without, since it is small and everybody keeps updated anyway... but we have grown over the years and i must say, i welcome your initiative!
one miniscule remark: can you change the date in the subject to 2007-09-24 respectively YYYY-MM-DD, please? :)
Hah, sure. I originally just had DD-MM and tacked the year on later, not thinking about it.
Monday 24 September 2007, Aaron Griffin wrote: | * Orphan Packages | | This is another one Andy brought up. We have A LOT of orphan | packages. We need someone to evaluate all of these orphans, to see | if we should 1) still support them or move them "down" to | community/unsupported 2) get someone to maintain them. | | Seeing as Andy is concerned with this, could you take the reins | here? Collaborating with Eric on the package cleanup is probably a | good thing too.
@ Andy, Eric:
I'm planning to do some cleanup on my pkgs and also take some orphans maybe in the next 10 days. I would like to be informed if you plan to do something on the subject... maybe i can give a hand or another, since i'm doing it anyway :)
- D
On Tue, 25 Sep 2007, Damir Perisa wrote:
Monday 24 September 2007, Aaron Griffin wrote: | * Orphan Packages | | This is another one Andy brought up. We have A LOT of orphan | packages. We need someone to evaluate all of these orphans, to see | if we should 1) still support them or move them "down" to | community/unsupported 2) get someone to maintain them. | | Seeing as Andy is concerned with this, could you take the reins | here? Collaborating with Eric on the package cleanup is probably a | good thing too.
@ Andy, Eric:
I'm planning to do some cleanup on my pkgs and also take some orphans maybe in the next 10 days. I would like to be informed if you plan to do something on the subject... maybe i can give a hand or another, since i'm doing it anyway :)
- D
In the repo cleanup, I'll first focus on the orphans packages as I guess a lot of the old/obsolete stuff is probably there. If you see possible candidates for removal while you browse the orphans list, add them to the repo cleanup list in the dev wiki. I've started to glance at the current orphans but I will probably do more later this week.
Eric
Tuesday 25 September 2007, Eric Belanger wrote: | In the repo cleanup, I'll first focus on the orphans packages as I | guess a lot of the old/obsolete stuff is probably there. If you | see possible candidates for removal while you browse the orphans | list, add them to the repo cleanup list in the dev wiki. I've | started to glance at the current orphans but I will probably do | more later this week.
ok, thanx, i will do so
is there an easy way to move a pkg to community? ideally to keep the history ...
- D
On 9/25/07, Damir Perisa damir.perisa@solnet.ch wrote:
Tuesday 25 September 2007, Eric Belanger wrote: | In the repo cleanup, I'll first focus on the orphans packages as I | guess a lot of the old/obsolete stuff is probably there. If you | see possible candidates for removal while you browse the orphans | list, add them to the repo cleanup list in the dev wiki. I've | started to glance at the current orphans but I will probably do | more later this week.
ok, thanx, i will do so
is there an easy way to move a pkg to community? ideally to keep the history ...
I wouldn't say it's _easy_, but you can move the RCS file directly. CVS is weird like that.
Try it somewhere else first just so we don't break extra or whatever, but, if you move, say: cvs-arch/arch/foo/PKGBUILD,v to cvs-community/community/foo/PKGBUILD,v
That should keep the history and everything - just be careful. 8)
Tuesday 25 September 2007, Aaron Griffin wrote: | > is there an easy way to move a pkg to community? ideally to keep | > the history ... | | I wouldn't say it's _easy_, but you can move the RCS file | directly. CVS is weird like that. | | Try it somewhere else first just so we don't break extra or | whatever, but, if you move, say: | cvs-arch/arch/foo/PKGBUILD,v | to | cvs-community/community/foo/PKGBUILD,v | | That should keep the history and everything - just be careful. 8)
i was more of thinking about a script to do it in the back.... automatically. ;) ... especially when we want to manage the community->extra extra->community transitions while keeping history, it may be helpful that a unified process is established and done.
CVS magic :)
- D
On 9/25/07, Eric Belanger belanger@astro.umontreal.ca wrote:
On Tue, 25 Sep 2007, Damir Perisa wrote:
Monday 24 September 2007, Aaron Griffin wrote: | * Orphan Packages | | This is another one Andy brought up. We have A LOT of orphan | packages. We need someone to evaluate all of these orphans, to see | if we should 1) still support them or move them "down" to | community/unsupported 2) get someone to maintain them. | | Seeing as Andy is concerned with this, could you take the reins | here? Collaborating with Eric on the package cleanup is probably a | good thing too.
@ Andy, Eric:
I'm planning to do some cleanup on my pkgs and also take some orphans maybe in the next 10 days. I would like to be informed if you plan to do something on the subject... maybe i can give a hand or another, since i'm doing it anyway :)
- D
In the repo cleanup, I'll first focus on the orphans packages as I guess a lot of the old/obsolete stuff is probably there. If you see possible candidates for removal while you browse the orphans list, add them to the repo cleanup list in the dev wiki. I've started to glance at the current orphans but I will probably do more later this week.
Any reason we aren't using the package cleanup list in the public wiki? This doesn't seem like something we should or need to hide from the user base. In addition, the history feature of a real wiki is much more relevant and useful for this kind of thing.
-Dan
On 9/25/07, Dan McGee dpmcgee@gmail.com wrote:
On 9/25/07, Eric Belanger belanger@astro.umontreal.ca wrote:
On Tue, 25 Sep 2007, Damir Perisa wrote:
Monday 24 September 2007, Aaron Griffin wrote: | * Orphan Packages | | This is another one Andy brought up. We have A LOT of orphan | packages. We need someone to evaluate all of these orphans, to see | if we should 1) still support them or move them "down" to | community/unsupported 2) get someone to maintain them. | | Seeing as Andy is concerned with this, could you take the reins | here? Collaborating with Eric on the package cleanup is probably a | good thing too.
@ Andy, Eric:
I'm planning to do some cleanup on my pkgs and also take some orphans maybe in the next 10 days. I would like to be informed if you plan to do something on the subject... maybe i can give a hand or another, since i'm doing it anyway :)
- D
In the repo cleanup, I'll first focus on the orphans packages as I guess a lot of the old/obsolete stuff is probably there. If you see possible candidates for removal while you browse the orphans list, add them to the repo cleanup list in the dev wiki. I've started to glance at the current orphans but I will probably do more later this week.
Any reason we aren't using the package cleanup list in the public wiki? This doesn't seem like something we should or need to hide from the user base. In addition, the history feature of a real wiki is much more relevant and useful for this kind of thing.
Eric recommended an internal cleanup right now for _technical_ issues. Packages that are incompatible with different architectures, packages which don't build anymore, etc etc
I mean, I guess we could reuse the wiki for this, but it's really not something that's opinion based.
I'm pretty neutral on the issue. If someone feels strongly about it, let me know.
Monday 24 September 2007, Aaron Griffin wrote: | * Multiple Maintainers on the Dashboard | | Yeah yeah this has been around for a while. We need to hack at our | django code, so we can have multiple maintainers per package. | Right now Eliott and Simo are the only ones with their hands in | this code. If anyone else has the desire to jump into this code, | please help out with this. It's something we are in dire need of. | | * Multiple Architectures on the Dashboard | | This is the same as above, BUT we need support for packages in all | architectures, AND the ability to assign different maintainers to | each architecture (not all of us can build for more than one | arch).
i have no django experience at all, sorry, but i have maybe some thoughts that may be helpful...
since i have a 64bit installation on my new laptop (no 32bit chroot because of lack of space), find myself being over the day able to build 64bit pkgs and in the evenings sometimes 32bit pkgs on my old machine (that has no display any more).
i have around 300 pkgs i maintain. most of them are easy, since they do not change API or deps or anything crucial at all. however, with my current situation (i am looking for a bigger sata 2.5 harddrive - it needs to support parking the heads without flushing the cache), i have my pkgs out of synch for some time. i update it in 64bit but then only after some days in 32bit repo. with pacbuild, this could be helped also, but my suggestion is another:
instead of having one maintainer for pkgs per arch, why not have/assign two? what i mean is:
pkg XY i686: name 1, name 2 x86_64: name 3, name 4
means: for the pkg XY, for the i686 pkg, name 1 is maintainer together with an optional second person name 2 analogue it applies to the x86_64 pkg.
in most of the cases, this is not filled and one name is standing behind both archs... but in some cases, it may be helpful and is also giving credit. :)
- D
On 9/25/07, Damir Perisa damir.perisa@solnet.ch wrote:
instead of having one maintainer for pkgs per arch, why not have/assign two? what i mean is:
pkg XY i686: name 1, name 2 x86_64: name 3, name 4
It's the same concept. From a "software architect" perspective, if we design it simply so we could have as many maintainers we want, it will be better in the long run. We can artificially enforce a two person limit ourselves, if we want to do that.
in most of the cases, this is not filled and one name is standing behind both archs... but in some cases, it may be helpful and is also giving credit. :)
I just have a feeling that setting a limit of 2 seems artificial, BUT, as I said, we can discuss that later, but the code shouldn't limit it to 2, that's just silly.
Tuesday 25 September 2007, Aaron Griffin wrote: | I just have a feeling that setting a limit of 2 seems artificial, | BUT, as I said, we can discuss that later, but the code shouldn't | limit it to 2, that's just silly.
sure, even better not limiting it to 2. having a matrix without limit in size makes sense, but i was afraid that this would need changes too complex to make.
of course i didn't have a look at the code, so i cannot tell. great we have some software-architecture-point-of-view people around!
- D
participants (4)
-
Aaron Griffin
-
Damir Perisa
-
Dan McGee
-
Eric Belanger