Largest medication site on net, Debian. Best prices for you!
Good afternoon.Everyone complains of the badness of his memory, but nobody of his judgment. Debian, searching for a site to purchase medication? To appreciate heaven well, it's good for a person to have some fifteen minutes of hell.Kings in this should imitate God, their mercy should be above their works.Gratitude is the most exquisite form of courtesy. We ship worldwide What else can you expect from a town that's shut off from the world by the ocean on one side and New Jersey on the other? Go here and get it You are completely anonymous! Artists to my mind are the real architects of change, and not the political legislators who implement change after the fact.Nobody can be as agreeable as an uninvited guest.
Bug#218169: "CGA snow" effect on Radeon 7500 at 24bpp
I have the problem described in this bug report and unfortunately the problem is still present now that I have upgraded to xserver-xfree86 4.3.0-7. >From my comment to the bug report on XFree86's site: (http://bugs.xfree86.org/show_bug.cgi?id=175) In 4.3.0 the problem has actually worsened. The SWcursor trick I described in my previous patch does not work anymore. Also, there's even more artifacts. I have actually taken a screenshot (in the literal sense since a screen capture would not show anything), and you can check it out there: http://fgouget.free.fr/tmp/img_2660.jpg For the screenshot I started a recursive ls to cause constant screen updates while I was taking the picture. Things are even worse than in the picture because the bands like the one that obscures the Slashdot entry below 'NY Holds Spam Scam Contest' keep moving around so that at any one time you see three or four of them. All in all this makes 4.3.0 unusable as is. I have performed some extra tests: * my screen is in 1920x1440 in 24bpp. The problem persists even if I lower the resolution all the way down to 1280x1024. * however as soon as I switch to 16bpp the problem goes away. * I tried the XaaNoScreenToScreenCopy and this time I still had the snow effect (in addition to the display becoming unusably slow) -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Bug#234025: port of milky screen patch to 4.3.0-7
I did a simple-minded port of the milky screen patch by Hui Yu that I
found at:
http://marc.theaimsgroup.com/?l=xfree86&m=105582853120655&w=2
I think it includes the following issues from what google has been able
to find:
274. Do not drop H&V sync during screen blanking for Radeon
(Bugzilla #320, Michael Breuer, Hui [EMAIL PROTECTED]).
273. Let out-of-limit pixel clocks only use the frequency below pll output
lower limit for Radeons (Bugzilla #262, John Vickers, Hui [EMAIL
PROTECTED]).
272. Add support for Radeon cards with DAC/TMDS wire up in different ways
from what the driver was originally programmed to; includes support
for dual DVI cards (Hui [EMAIL PROTECTED]).
271. Add Radeon DPMS handling for flat panels (Bugzilla #26, Hui [EMAIL
PROTECTED]).
270. Decreased the retry loops in DDC probing so that Radeon startup
time won't be too long in the worst case (Hui [EMAIL PROTECTED]).
269. Fix Radeon Asic bug in RMX unit of IGP chips (Hui [EMAIL PROTECTED]).
268. Fix Radeon register initialization for RGB offset to fix the
"milky-screen" problem (Bugzilla #351, Hui [EMAIL PROTECTED]).
267. Add support for new Radeon chips: R350(9800), RV350(9600,M10),
RS250(IGP7000), RS300(IGP9000), RV280(9200) (Hui [EMAIL PROTECTED]).
I have no idea if it works on any other card but mine, but it did fix my
problem. I would have liked to separate out just the milky screen fix,
but I have no idea where to start.
Wish I had seen the sw_cursor fix as that is a lot less work. Haven't
tried it to see if it works for me yet.
Here is the patch in case anyone is interested but if sw_cursor works,
that's a much safer fix.
Jon
diff -urN xc.orig/programs/Xserver/hw/xfree86/common/xf86PciInfo.h xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h
--- xc.orig/programs/Xserver/hw/xfree86/common/xf86PciInfo.h 2004-04-03 15:35:30.0 -0500
+++ xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h 2004-04-03 15:44:03.0 -0500
@@ -93,10 +93,20 @@
#define PCI_CHIP_R300_AE 0x4145
#define PCI_CHIP_R300_AF 0x4146
#define PCI_CHIP_R300_AG 0x4147
+#define PCI_CHIP_R350_AH 0x4148
+#define PCI_CHIP_R350_AI 0x4149
+#define PCI_CHIP_R350_AJ 0x414A
+#define PCI_CHIP_R350_AK 0x414B
+#define PCI_CHIP_RV350_AP 0x4150
+#define PCI_CHIP_RV350_AR 0x4152
#define PCI_CHIP_MACH32 0x4158
+#define PCI_CHIP_RS250_4237 0x4237
#define PCI_CHIP_R200_BB 0x4242
+#define PCI_CHIP_RS100_4336 0x4336
+#define PCI_CHIP_RS200_4337 0x4337
#define PCI_CHIP_MACH64CT 0x4354
#define PCI_CHIP_MACH64CX 0x4358
+#define PCI_CHIP_RS250_4437 0x4437
#define PCI_CHIP_MACH64ET 0x4554
#define PCI_CHIP_MACH64GB 0x4742
#define PCI_CHIP_MACH64GD 0x4744
@@ -146,6 +156,11 @@
#define PCI_CHIP_R300_NE 0x4E45
#define PCI_CHIP_R300_NF 0x4E46
#define PCI_CHIP_R300_NG 0x4E47
+#define PCI_CHIP_R350_NH 0x4E48
+#define PCI_CHIP_R350_NI 0x4E49
+#define PCI_CHIP_R350_NJ 0x4E4A
+#define PCI_CHIP_R350_NK 0x4E4B
+#define PCI_CHIP_RV350_NP 0x4E50
#define PCI_CHIP_RAGE128PA 0x5041
#define PCI_CHIP_RAGE128PB 0x5042
#define PCI_CHIP_RAGE128PC 0x5043
@@ -217,6 +232,10 @@
#define PCI_CHIP_MACH64VT 0x5654
#define PCI_CHIP_MACH64VU 0x5655
#define PCI_CHIP_MACH64VV 0x5656
+#define PCI_CHIP_RS300_5834 0x5834
+#define PCI_CHIP_RS300_5835 0x5835
+#define PCI_CHIP_RS300_5836 0x5836
+#define PCI_CHIP_RS300_5837 0x5837
#define PCI_CHIP_RV280_5960 0x5960
#define PCI_CHIP_RV280_5961 0x5961
#define PCI_CHIP_RV280_5962 0x5962
diff -urN xc.orig/programs/Xserver/hw/xfree86/drivers/ati/atichip.c xc/programs/Xserver/hw/xfree86/drivers/ati/atichip.c
--- xc.orig/programs/Xserver/hw/xfree86/drivers/ati/atichip.c 2004-04-03 15:35:30.0 -0500
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/atichip.c 2004-04-03 15:44:03.0 -0500
@@ -84,17 +84,23 @@
"ATI Rage 128 Mobility M3",
"ATI Rage 128 Mobility M4",
"ATI unknown Rage 128"
-"ATI Radeon",
-"ATI Radeon VE",
+"ATI Radeon 7200",
+"ATI Radeon 7000 (VE)",
"ATI Radeon Mobility M6",
"ATI Radeon IGP320",
-"ATI Radeon Mobility M7",
"ATI Radeon IGP330/340/350",
-"ATI Radeon 8500",
+"ATI Radeon 7000 IGP",
"ATI Radeon 7500",
+"ATI Radeon Mobility M7",
+"ATI Radeon 8500/9100",
"ATI Radeon 9000",
"ATI Radeon Mobility M9",
-"ATI Radeon 9700",
+"ATI Radeon 9000 IGP",
+"ATI Radeon 9200",
+"ATI Radeon Mobility M9+",
+"ATI Radeon 9700/9500",
+"ATI Radeon 9600",
+"ATI Radeon 9800",
"ATI Rage HDTV"
};
@@ -639,6 +645,10 @@
case NewChipID('C', '7'):
return ATI_CHIP_RS200;
+case NewChipID('D', '7'):
+case NewChipID('B', '7'):
+ return ATI_CHIP_RS250;
+
case NewChipID('L', 'W'):
case NewChipID('L', 'X'):
return ATI_CHIP_RADEONMOBILITY7;
@@ -675,6 +685,10 @@
case NewChipID('L', 'g'):
return ATI_
Bug#126519: obtrude
Stokes # The cablefilterz will allow you to receive all the channels that you order with your remote control* payperviews,aXXXmovies,sport events,special-events? http://www.8004hosting.com/cable/ bondage,been in bethphage.
Bug#241923: xbase-clients: Unable to figure out xmodmap syntax after heaving read the manpage several times
Package: xbase-clients Version: 4.1.0-16 Severity: important File: /usr/X11R6/bin/xmodmap Hi! The xmodmap's manpage is unclear, vague, and confusing, to say the least. I don't understand e.g. what the keysym columns are for--in one place, the manpage reads: | The first keysym is used when no modifier key is pressed in conjunction | with this key, the second with Shift, the third when the Mode_Switch key | is used with this key and the fourth when both the Mode_Switch and Shift | keys are used. But further on, I learned that: | [A]pplications that need a Meta key simply need to get the keycode and | don't require the keysym to be in the first column of the keymap | table. This means that applications that are looking for a Multi_key | (including the default modifier map) won't notice any change. | | % xmodmap -e "keysym Multi_key = Multi_key Meta_L" What the h*** is this? Yours Completely Confused, Jan. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux kontryhel 2.4.20 #1 SMP Sun Dec 15 01:30:10 CET 2002 i686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 Versions of packages xbase-clients depends on: ii cpp 2:2.95.4-14 The GNU C preprocessor. ii debconf 1.0.32 Debian configuration management sy ii libc62.2.5-11.2 GNU C Library: Shared libraries an ii libdps1 4.1.0-16Display PostScript (DPS) client li ii libfreetype6 2.0.9-1 FreeType 2 font engine, shared lib ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand ii libxaw7 4.1.0-16X Athena widget set library ii mesag3-glide2 [libgl1] 3.4.2.1-4 A 3-D graphics library which uses ii xlibs4.1.0-16X Window System client libraries pgplECydoTCdu.pgp Description: PGP signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
Around 11 o'clock on Apr 3, Andreas Schuldei wrote: > As i see it X differs mostly from apache in this regard: it is a > bitch because of the hardware. i would like to see the > machinepark and logistics to be able to compile and test all the > patches. It's precisely like the kernel in this regard; and the worst part of the kernel is always the device drivers because so few people can test each one. Fixes which affect only one video driver should be subject to significantly less scrutiny than fixes which affect libraries or the core X server itself. Of course, letting those drivers be released on an hourly basis would make this a lot less painful. Oh, ATI is working on building a sufficient infrastructure to test their cards. They do support the open source drivers, so it's quite reasonable to get their help in testing new releases for those chips. Any of you are also welcome to fix bugs upstream as soon as Debian migrates away from XFree86 4.3; I'm hoping that the combined efforts of SuSE, Debian and Red Hat will slowly whittle down the steaming pile of bugs which has accumulated over the years. -keith pgpt6zEx2P1ej.pgp Description: PGP signature
Why dont u try?
Dont go everywhere for all u needs WE have all Meridia Víagra Propecia Celebrex Soma Zyban Prozac Vioxx Penís Enlargement and Much more Best Prlce on Internet F.a.s.t And F.r.e.e Shlpplng http://www.medicalfhtjk.com/index.php?refid=shan05
Bug#241779: xterm's manpage has +/- swapped at vb option
The manpage and code appear to agree. One of us is not looking at this properly. -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
List 'slug' closed to public posts
Notice -- A message was recently received from your email address, addressed to the mailing list SLUG. Our list server does not recognize you as a list member (as identified by email address). Messages from non-members are "moderated", which means that your message will be posted after it has been approved by the list administrator. The reason for this policy is to prevent solicitations (spam) from being posted to the list. Because of the time required for the moderator to approve your message, there may be a delay before it gets posted. To avoid such delays in the future, you may join the list by sending mail to SLUG-Request at the host AI.SRI.COM with "Subscribe" as the subject. If you wish, you may join immediately, and then repost this message after you receive your membership acknowledgment. If you believe this message is in error, contact the list administrator at the address of SLUG-Admins at the host AI.SRI.COM Regards, SLUG list administrator --- Listar v1.0.0 - job execution complete.
Re: XFree86 4.3.0 and testing (was: when will the release release)
* Fabio Massimo Di Nitto ([EMAIL PROTECTED]) [040403 09:01]: > Testing the bug fixes. This is extremely important at this point in time. > Do not commit bug fixes without testing them. We are not in the position > to ruin uploads with FTBFS. Always try to test on as many archs as you > can. Of course there might be exceptions such as hardware restrictions > (eg: i can't test this or that because i do not have that specific version > of that card) but it must not be the normal case. You can still test that > it does not break anything already working. I highly recommends to add > information about the tests you have done to verify the bug fix whenever > you can, especially when you cannot test directly on a specific setup. Eg. > applied patch to fix ATI driver Y,Z but since we can't test on that > specific hardware it has been verified that it doesn't break with other > ATI cards. > and so on.. common sense applies here in how you report and track these > information. As i see it X differs mostly from apache in this regard: it is a bitch because of the hardware. i would like to see the machinepark and logistics to be able to compile and test all the patches. Apart from that i think highly of a more coordinated and team-spirited approach (think small-groups within debian - my talk at debconf3). for this i noticed in the meantime that a certain immediacy (more than mailinglists can provide, but irc does) is necessary to let the teamspirit develop. Try to get people not yet on irc but on the team to reconsider to hang out on irc regularly. /andreas
Bug#241008: libxft-dev: Same problem on alpha arch.
Package: libxft-dev Version: 2.1.2-5 Severity: normal Followup-For: Bug #241008 Hi, I get the same problem on alpha when upgrading form 2.1.2-5 to 2.1.2-6. Here's the relevant apt-get output: Preparing to replace libxft-dev 2.1.2-5 (using .../libxft-dev_2.1.2-6_alpha.deb) ... diversion of /usr/X11R6/include/X11/Xft/Xft.h to /usr/X11R6/include/X11/Xft/Xft1.h by libxft-dev Removing `diversion of /usr/X11R6/include/X11/Xft/Xft.h to /usr/X11R6/include/X11/Xft/Xft1.h by libxft-dev' dpkg-divert: rename involves overwriting `/usr/X11R6/include/X11/Xft/Xft.h' with different file `/usr/X11R6/include/X11/Xft/Xft1.h', not allowed dpkg: error processing /var/cache/apt/archives/libxft-dev_2.1.2-6_alpha.deb (--unpack): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/libxft-dev_2.1.2-6_alpha.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: alpha Kernel: Linux 2.4.24.am Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages libxft-dev depends on: ii libc6.1-dev [libc6-dev] 2.3.2.ds1-11 GNU C Library: Development Librari ii libfontconfig1-dev 2.2.2-1 generic font configuration library ii libfreetype6-dev2.1.7-2 FreeType 2 font engine, developmen pn libxft2 Not found. pn libxrender-dev Not found. pn xlibs-devNot found. ii zlib1g-dev [libz-dev] 1:1.2.1-5compression library - development -- no debconf information
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 06:58:02PM +0200, Fabio Massimo Di Nitto wrote: > On Fri, 2 Apr 2004, Daniel Stone wrote: > > > Re-reading the bug log and the thread I still cannot understand why you > > > downgraded the bug in the first place. There is no explanation in the BTS > > > and the downgrade was done before Branden investigation that would have > > > let X entering sarge in any case. You might want to excuse if i missed > > > something but i can't access emails on a daily base but i am sure you can > > > be so kind to give an explanation. > > > > I'll need to respond to this (later) in the morning. > > Ok. I just want to have a clear picture of the situation, since we are a > team and we should work as such I think certain decisions (like X or Y > should be handled in this way for this reason) should be agreed before > rather than after. I'll agree that I should've explained it, but I don't like the suggestion of package management by committee; we'll never get anything done. When I told Warren Turkal he was welcome to maintain libX11, I didn't tell him to run every commit through a build, to test on all the release architectures before he released, or whatever. All I said was to remember what he was working on, and decide accordingly. I think the XSF members have this much sense; just use your head. Anyway, back to the bug. It doesn't cause serious data loss, doesn't break unrelated apps, etc. It belongs as an important bug at most IMO; if 'the X server segfaults when I run it with this revision of a PCI Matrox' is important, then there's no way this bug should be higher. It's an occasional annoyance, and nothing more (IMO). > > > If you want at act as a release manager, you should in the first place > > > stop telling people that they are stupid or whatever and start to > > > cooperate with everyone, even with "clueless" people (this is not meant to > > > be an attack to Adrian at all, but a general reference to less experienced > > > users) and give good explanations to your actions wearing the RM hat. > > > > I said the suggestion was 'stupid', and I stick by it. I'm perfectly > > willing to co-operate with Adrian, but not to the point of yielding to > > his every suggestion - I have an opinion on some matters, and I'm not > > willing to let everyone trample all over it. > > We all have opinions, neither i say that we need to accept everything from > everyone, but upon a rejection I like to see a good explanation that makes > 'stupid' a certain suggestion. BTW, I never said Adrian was 'stupid', not at all. I was just stating my opinion on his opinion on the bug. > > The RM position is all yours if Branden agrees. > > This is where imho you miss the point. It is OUR decision who has to take > the position as RM inside OUR team. Noone until now has been stepping > forward and say: "hey i would like to take that responsability". > Now we are in the exactly the other situation with 2 candidates. I > believe that XFS should publically decide who can fit better that > position and with XFS i also mean our users and not just us. Ideally, yes, but I haven't traditionally seen this as how the XSF has managed. The only reason I put my hand up for it was because, as best I could tell at the time, no-one else had. I'll be relieved to escape the time pressure, tbh. I don't want to do it; I just said I would because no-one else was (again, as best I could tell). That kind of leaves you per default, no? -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Apr 03, 2004 at 08:43:59AM +0200, Fabio Massimo Di Nitto wrote: > On Fri, 2 Apr 2004, Daniel Stone wrote: > > but I'll just say that I have no confidence in the XSF as a team. Not to > > do with you, or Michel, or anything, but I have no confidence that it is > > a team in the true collaborative sense, or that it will ever be managed > > as such with the current leadership. Again, not a slight to you, Michel, > > or anyone else helping out with X. > > While you are at it, would you mind also to explain to the community which > are your reasons to candidate as XSF Release Manager while you do not have > confidence in the XSF as a team? Very badly worded on my behalf. I don't have confidence in the management of the XSF as a team, but that doesn't mean I don't want to help fix X in Debian. As no-one had stepped up (as far as I was aware), I decided I might as well do it, since -8 clearly needed to be done. > Recent changes in my Debian activities will soon give me the time and the > possibility to take over some bigger tasks than one I am handling now. > > As you all know I am part of the apache team and my main focus is on > apache1.3. Sarge will have apache2 as default web server (task: webserver) > and apache1.3 will be soon in a "release for sarge state" and probably, as > obvious next step, obsoleted any time after sarge. Cool, that's good news. > The combinantion of the 2 will free quite a lot of time in my Debian life. Right. > Due to the fact that I have learned a lot from my own mistakes in handling > apache (fixes to these mistakes will be on the way as soon as i will > complete my movement to the new house - simply because i can't handle a > full discussion in my actual net/resources conditions), plus the > experience I have built with cooperative maintaince and that I need to be > challenged to keep myself "alive", I would love to spend more energy > within the XSF. Project and team that i had to place in low priority until > now, mainly due to time restrictions. Please don't let me stop you: make your own judgements on what you want to do. I'm just presenting my opinion from my experience, but you will no doubt have yours, and I don't want to impose mine on you in any way. > Taking over some responsabilities/tasks from Branden will give him the > possibility to reallocate this time to other activities. Definitely. > The short term plan, and i doubt anyone will object to this, is to have X > in a release state for sarge. We need to focus our energy towards bug > fixing but we need to be extremely carefull with the release cycle. X is > not a package we can upload on a daily base. I think the right balance at > this point in time is a bi-weekly release or 10 bug fixes, which one comes > first, with the flexibility to decide to delay one upload when bug fixes > must flow into sarge asap or speeding up via urgency field. It is explicit > that no major changes should go in until they are absolutely necessary and > never prior discussion on the mailing list. Sure. > We will work together on a long term plan after sarge. There is no real > need for it right now imho. Well, we need to do it ASAP, IMO. If we start on this after sarge, it'll take even longer to do, and we'll need to maintain the old monolithic tree in the interim. As the 4.3 experience has shown us, this is not something we can viably keep doing. I'm working upstream to try to get the fd.o modular trees in good shape, which, along with uni, is sucking up all my time. After this, I intend to help out on the Debian side of things. > BTS is full of things to do... no doubts about it. There are almost 900 > bugs. a bit more than 500 marked as upstream. As a Release Manager i would > like to see one person working only on packaging issues, while at least 2 > persons taking care of the upstream ones (or at least a similar ratio). > Of course XSF should find the best delegates for these tasks and any > volunteer or sporadic help will be appreciated. I don't necessarily see this as an exclusive task. Having a dedicated RM, and designated component handlers (e.g. xserver, xlibs, xapps, xfonts, xdocs, whatever) would be nice, though. > Testing the bug fixes. This is extremely important at this point in time. > Do not commit bug fixes without testing them. We are not in the position > to ruin uploads with FTBFS. Always try to test on as many archs as you > can. Of course there might be exceptions such as hardware restrictions > (eg: i can't test this or that because i do not have that specific version > of that card) but it must not be the normal case. You can still test that > it does not break anything already working. I highly recommends to add > information about the tests you have done to verify the bug fix whenever > you can, especially when you cannot test directly on a specific setup. Eg. > applied patch to fix ATI driver Y,Z but since we can't test on that > specific hardware it has been verified that it doesn't b
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, 2 Apr 2004, Daniel Stone wrote: > I'm in a hurry this morning, so I can't give a substantive response for > a couple of hours, Ok I am looking forward to a full response. > but I'll just say that I have no confidence in the XSF as a team. Not to > do with you, or Michel, or anything, but I have no confidence that it is > a team in the true collaborative sense, or that it will ever be managed > as such with the current leadership. Again, not a slight to you, Michel, > or anyone else helping out with X. While you are at it, would you mind also to explain to the community which are your reasons to candidate as XSF Release Manager while you do not have confidence in the XSF as a team? Here are my motivations to "candidate": Recent changes in my Debian activities will soon give me the time and the possibility to take over some bigger tasks than one I am handling now. As you all know I am part of the apache team and my main focus is on apache1.3. Sarge will have apache2 as default web server (task: webserver) and apache1.3 will be soon in a "release for sarge state" and probably, as obvious next step, obsoleted any time after sarge. The combinantion of the 2 will free quite a lot of time in my Debian life. Due to the fact that I have learned a lot from my own mistakes in handling apache (fixes to these mistakes will be on the way as soon as i will complete my movement to the new house - simply because i can't handle a full discussion in my actual net/resources conditions), plus the experience I have built with cooperative maintaince and that I need to be challenged to keep myself "alive", I would love to spend more energy within the XSF. Project and team that i had to place in low priority until now, mainly due to time restrictions. Taking over some responsabilities/tasks from Branden will give him the possibility to reallocate this time to other activities. The short term plan, and i doubt anyone will object to this, is to have X in a release state for sarge. We need to focus our energy towards bug fixing but we need to be extremely carefull with the release cycle. X is not a package we can upload on a daily base. I think the right balance at this point in time is a bi-weekly release or 10 bug fixes, which one comes first, with the flexibility to decide to delay one upload when bug fixes must flow into sarge asap or speeding up via urgency field. It is explicit that no major changes should go in until they are absolutely necessary and never prior discussion on the mailing list. We will work together on a long term plan after sarge. There is no real need for it right now imho. BTS is full of things to do... no doubts about it. There are almost 900 bugs. a bit more than 500 marked as upstream. As a Release Manager i would like to see one person working only on packaging issues, while at least 2 persons taking care of the upstream ones (or at least a similar ratio). Of course XSF should find the best delegates for these tasks and any volunteer or sporadic help will be appreciated. Testing the bug fixes. This is extremely important at this point in time. Do not commit bug fixes without testing them. We are not in the position to ruin uploads with FTBFS. Always try to test on as many archs as you can. Of course there might be exceptions such as hardware restrictions (eg: i can't test this or that because i do not have that specific version of that card) but it must not be the normal case. You can still test that it does not break anything already working. I highly recommends to add information about the tests you have done to verify the bug fix whenever you can, especially when you cannot test directly on a specific setup. Eg. applied patch to fix ATI driver Y,Z but since we can't test on that specific hardware it has been verified that it doesn't break with other ATI cards. and so on.. common sense applies here in how you report and track these information. My position will be to coordinate the people working on bug fixes and monitor their activities to ensure to stick with the plan and coordinate with debian-release management in order to allign XSF activities with Debian ones. Thanks Fabio PS: just a reminder. I will be offline for a couple of days at least (moving more stuff to the new house) as i already wrote and people should be aware of it by now :-) please be nice if i won't answer back in a millisecond.
