[arch-dev-public] Driver Maintainers
Hey all, as you may have noticed I picked up X.org from Jan to take some load off of his shoulders. I'm very proficient in doing the whole X.org thing since I've done so over a phase of like 3 years in a professional environment. Then again, testing quickly became a problem. I can't possibly come up with all the hardware to actually more than just build-install-test most in x11-drivers. I would suggest that we assign TUs who have these chipsets as testers or even maintainers. We could even drive this further with other packages where we didn't do so yet: * lirc * madwifi * wlan-ng aso. It would further go into the direction of packaging divisions and raise quality of our packages. Opinions? Ideas how this can be implemented without changing our system to much and everybody still being fine with it? Cheers, -I
On 5/11/07, Alexander Baldeck <kth5@archlinuxppc.org> wrote:
Hey all,
as you may have noticed I picked up X.org from Jan to take some load off of his shoulders. I'm very proficient in doing the whole X.org thing since I've done so over a phase of like 3 years in a professional environment.
Then again, testing quickly became a problem. I can't possibly come up with all the hardware to actually more than just build-install-test most in x11-drivers. I would suggest that we assign TUs who have these chipsets as testers or even maintainers. We could even drive this further with other packages where we didn't do so yet:
* lirc * madwifi * wlan-ng
aso.
It would further go into the direction of packaging divisions and raise quality of our packages. Opinions? Ideas how this can be implemented without changing our system to much and everybody still being fine with it?
I like the idea of having a group of "testers" for hardware stuff. To get the ball rolling, perhaps we could start a simple wiki page where a user can come in and list the hardware and arch packages they use that may be unique - we can figure out a plan of attack while gathering this data. For right now, I'd say lets only as TUs and devs for information, just to ensure some chain-of-command remains. Here's a random idea (and part of the original reason too) - The "hidden" arch-commits list which tracks cvs commits can be used to track commits to the driver packages, and shoot off an email to the "testers" that a new version is in CVS. It'd be fairly easy to do, actually. I could throw something together (emails would come from my gmail though probably) pretty quickly if I'm thinking this through right.
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/11/07, Alexander Baldeck <kth5@archlinuxppc.org> wrote:
Hey all,
as you may have noticed I picked up X.org from Jan to take some load off of his shoulders. I'm very proficient in doing the whole X.org thing since I've done so over a phase of like 3 years in a professional environment.
Then again, testing quickly became a problem. I can't possibly come up with all the hardware to actually more than just build-install-test most in x11-drivers. I would suggest that we assign TUs who have these chipsets as testers or even maintainers. We could even drive this further with other packages where we didn't do so yet:
* lirc * madwifi * wlan-ng
aso.
It would further go into the direction of packaging divisions and raise quality of our packages. Opinions? Ideas how this can be implemented without changing our system to much and everybody still being fine with it?
I like the idea of having a group of "testers" for hardware stuff.
To get the ball rolling, perhaps we could start a simple wiki page where a user can come in and list the hardware and arch packages they use that may be unique - we can figure out a plan of attack while gathering this data.
Yeah, I've brought this on some time ago too after finding that dead page on devwiki. Also, it will greatly help in cases when confirmation of a bug is needed.
For right now, I'd say lets only as TUs and devs for information, just to ensure some chain-of-command remains.
Here's a random idea (and part of the original reason too) - The "hidden" arch-commits list which tracks cvs commits can be used to track commits to the driver packages, and shoot off an email to the "testers" that a new version is in CVS. It'd be fairly easy to do, actually. I could throw something together (emails would come from my gmail though probably) pretty quickly if I'm thinking this through right.
Good idea. -- Roman Kyrylych (Роман Кирилич)
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
To get the ball rolling, perhaps we could start a simple wiki page where a user can come in and list the hardware and arch packages they use that may be unique - we can figure out a plan of attack while gathering this data.
Yeah, I've brought this on some time ago too after finding that dead page on devwiki. Also, it will greatly help in cases when confirmation of a bug is needed.
Started - as it says, it's a stub. I just threw out ideas - no need to discuss it, if you think my ideas are dumb, go ahead and change it. I'll do some procmail magic tonight and start sending mails to myself with this. http://wiki.archlinux.org/index.php/Driver_Testing
On 5/12/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
To get the ball rolling, perhaps we could start a simple wiki page where a user can come in and list the hardware and arch packages they use that may be unique - we can figure out a plan of attack while gathering this data.
Yeah, I've brought this on some time ago too after finding that dead page on devwiki. Also, it will greatly help in cases when confirmation of a bug is needed.
Started - as it says, it's a stub. I just threw out ideas - no need to discuss it, if you think my ideas are dumb, go ahead and change it. I'll do some procmail magic tonight and start sending mails to myself with this.
Oh cool :) How about we take the suggestion a little bit further, create an [arch-testing] mailing list, where we can send a mail, so that people who use a package, can know it's in testing. Currently there's no notification if something goes into testing, so it nearly always goes in without people knowing. If people knew, then they'd be able to selectively take things from testing, pacman -S testing/package and give us feedback. If not, we could at least extend that wiki page to more than drivers. James -- iphitus // Arch Developer // iphitus.loudas.com
On 5/11/07, James <iphitus@gmail.com> wrote:
On 5/12/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
To get the ball rolling, perhaps we could start a simple wiki page where a user can come in and list the hardware and arch packages they use that may be unique - we can figure out a plan of attack while gathering this data.
Yeah, I've brought this on some time ago too after finding that dead page on devwiki. Also, it will greatly help in cases when confirmation of a bug is needed.
Started - as it says, it's a stub. I just threw out ideas - no need to discuss it, if you think my ideas are dumb, go ahead and change it. I'll do some procmail magic tonight and start sending mails to myself with this.
Oh cool :)
How about we take the suggestion a little bit further, create an [arch-testing] mailing list, where we can send a mail, so that people who use a package, can know it's in testing.
Currently there's no notification if something goes into testing, so it nearly always goes in without people knowing. If people knew, then they'd be able to selectively take things from testing, pacman -S testing/package and give us feedback.
That would be useful, and probably very easy to do (arch-commits does the exact same thing, but doesn't respect tags... I'd have to figure out how to handle that...)
If not, we could at least extend that wiki page to more than drivers.
The problem is that hardware related stuff has it's own separate set of kinks, to the point where I'd like to see some extra level of information here. For example, the new xf86-video-intel may work on most cards, but tester Joe has an old card that seems to segfault. Package notification for testing though is a good idea, but I think the actual hardware issue is a different beast, and it'd be nice to know who is testing and what hardware they have.
2007/5/12, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/11/07, James <iphitus@gmail.com> wrote:
On 5/12/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 5/11/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/11, Aaron Griffin <aaronmgriffin@gmail.com>:
To get the ball rolling, perhaps we could start a simple wiki page where a user can come in and list the hardware and arch packages they use that may be unique - we can figure out a plan of attack while gathering this data.
Yeah, I've brought this on some time ago too after finding that dead page on devwiki. Also, it will greatly help in cases when confirmation of a bug is needed.
Started - as it says, it's a stub. I just threw out ideas - no need to discuss it, if you think my ideas are dumb, go ahead and change it. I'll do some procmail magic tonight and start sending mails to myself with this.
Oh cool :)
How about we take the suggestion a little bit further, create an [arch-testing] mailing list, where we can send a mail, so that people who use a package, can know it's in testing.
Currently there's no notification if something goes into testing, so it nearly always goes in without people knowing. If people knew, then they'd be able to selectively take things from testing, pacman -S testing/package and give us feedback.
That would be useful, and probably very easy to do (arch-commits does the exact same thing, but doesn't respect tags... I'd have to figure out how to handle that...)
If not, we could at least extend that wiki page to more than drivers.
The problem is that hardware related stuff has it's own separate set of kinks, to the point where I'd like to see some extra level of information here. For example, the new xf86-video-intel may work on most cards, but tester Joe has an old card that seems to segfault.
Package notification for testing though is a good idea, but I think the actual hardware issue is a different beast, and it'd be nice to know who is testing and what hardware they have.
How about extending that page for purposes of kernel package testing as well? This will include chipset, built-in sound & network and PCI, PCI-X (mostly RAID controllers) and ISA cards that all are supported by modules included in kernel package. -- Roman Kyrylych (Роман Кирилич)
participants (4)
-
Aaron Griffin
-
Alexander Baldeck
-
James
-
Roman Kyrylych