Re: X.org release engineering?
jspran...@awlship.com wrote: Trying to build Kdrive and I receiving the following errors: kinput.c: In function ‘KdEnableInput’: kinput.c:340: warning: passing argument 1 of ‘NoticeEventTime’ from incompatible pointer type kinput.c: In function ‘KdQueueEvent’: kinput.c:1675: warning: passing argument 2 of ‘mieqEnqueue’ from incompatible pointer type kinput.c: In function ‘ProcessInputEvents’: kinput.c:2182: warning: old-style function definition kinput.c: In function ‘NewInputDeviceRequest’: kinput.c:2318: error: too few arguments to function ‘ActivateDevice’ kinput.c:2319: error: too few arguments to function ‘EnableDevice’ kinput.c:2326: error: too few arguments to function ‘ActivateDevice’ kinput.c:2327: error: too few arguments to function ‘EnableDevice’ kinput.c: In function ‘DeleteInputDeviceRequest’: kinput.c:2345: error: too few arguments to function ‘RemoveDevice’ make[3]: *** [kinput.lo] Error 1 make[2]: *** [install-recursive] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 can anyone point me to where I need to read to find out what I'm doing wrong? If you really need kdrive, this needs fixing. Adding ,TRUE to args should do the job. If you don't or don't know, don't build it. It's disabled by default. Cheers, Simon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Tue, Jun 09, 2009 at 03:04:19PM +, jspran...@awlship.com wrote: Trying to build Kdrive and I receiving the following errors: kinput.c: In function ‘KdEnableInput’: kinput.c:340: warning: passing argument 1 of ‘NoticeEventTime’ from incompatible pointer type kinput.c: In function ‘KdQueueEvent’: kinput.c:1675: warning: passing argument 2 of ‘mieqEnqueue’ from incompatible pointer type kinput.c: In function ‘ProcessInputEvents’: kinput.c:2182: warning: old-style function definition kinput.c: In function ‘NewInputDeviceRequest’: kinput.c:2318: error: too few arguments to function ‘ActivateDevice’ kinput.c:2319: error: too few arguments to function ‘EnableDevice’ kinput.c:2326: error: too few arguments to function ‘ActivateDevice’ kinput.c:2327: error: too few arguments to function ‘EnableDevice’ kinput.c: In function ‘DeleteInputDeviceRequest’: kinput.c:2345: error: too few arguments to function ‘RemoveDevice’ make[3]: *** [kinput.lo] Error 1 make[2]: *** [install-recursive] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 can anyone point me to where I need to read to find out what I'm doing wrong? Please don't hijack threads. I have patches for this in my local tree, they will be merged soon. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Mon, Jun 08, 2009 at 04:20:00PM -0400, Adam Jackson wrote: Security is handled out of band like any other project. We'll release patches for at least the most recent release, probably do a point release for same, and anyone shipping anything older gets to backport. In practise, this didn't happen though. I don't care about most other parts, but this one is and was a huge regression compared to the monolithic word. Another issue is of course the undocumented incompatibility. Typical example: you can build xf86-video-intel against xorg-server-1.4.x Trying to use it shows all kinds of trouble. Proper failure in this case is better than all kind of mysterious bugs. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
Joerg Sonnenberger wrote: On Mon, Jun 08, 2009 at 04:20:00PM -0400, Adam Jackson wrote: Security is handled out of band like any other project. We'll release patches for at least the most recent release, probably do a point release for same, and anyone shipping anything older gets to backport. In practise, this didn't happen though. I don't care about most other parts, but this one is and was a huge regression compared to the monolithic word. Which part doesn't happen? I don't see any difference in our patch releases compared to monolithic days, and don't know of any security bugs we know of and have failed to release patches for. Point releases, we only really did one in the monolithic days, 6.8.1, since they were so much harder to do then, and while we don't always do them now, I think we've done more than one since. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
Joerg Sonnenberger wrote: On Tue, Jun 09, 2009 at 07:05:47AM -0700, Alan Coopersmith wrote: Joerg Sonnenberger wrote: On Mon, Jun 08, 2009 at 04:20:00PM -0400, Adam Jackson wrote: Security is handled out of band like any other project. We'll release patches for at least the most recent release, probably do a point release for same, and anyone shipping anything older gets to backport. In practise, this didn't happen though. I don't care about most other parts, but this one is and was a huge regression compared to the monolithic word. Which part doesn't happen? I don't see any difference in our patch releases compared to monolithic days, and don't know of any security bugs we know of and have failed to release patches for. The part of point releases never happened and the process of what patches are needed was quite a bit easier for the monolithic tree. E.g. the patches for the monolithic tree effectively replaced the point releases. I can point at least to the libXfont-1.3.1 release and the buffer overflow with the readlink usage that never was addressed via patch. Assuming you mean http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=5bf703700ee4a5d6eae20da07cb7a29369667aef the patch is available from git, like all other changes. I can't find much discussion in the xorg_security list mail in my inbox archives (list archives obviously aren't public) but it looks like no one declared that they believed it was an exploitable security issue, just a bug, so we didn't go through the security release process for it. (There was no CVE or security alert issued either.) -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Tue, Jun 09, 2009 at 08:13:03AM -0700, Alan Coopersmith wrote: Assuming you mean http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=5bf703700ee4a5d6eae20da07cb7a29369667aef the patch is available from git, like all other changes. See earlier part about following git history :) I can't find much discussion in the xorg_security list mail in my inbox archives (list archives obviously aren't public) but it looks like no one declared that they believed it was an exploitable security issue, just a bug. I wouldn't care about most off-by-one issues. This one is under full user control though as xset can be used to make the server process arbitrary directories (e.g. under /tmp). Anyway, it is an issue of the past. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X.org release engineering?
Where are the release engineering schedule, policies, and steps documented? Note: I have done at least three official X.org component releases (at least three different modules). (Official is defined as: I increased number for release version, did tests, tagged in git, created tarballs, maybe uploaded tarballs?, created checksums, and PGP email to announce on xorg-announce.) (I am writing about release engineering processes. If you'd like to help document release engineering processes specifically for X.org or different project or generically, please let me know.) The testing plan at http://www.x.org/wiki/XorgTesting is out of date. It is about monolithic make world. It doesn't define testing plan for modular X.org components. The TestGroup and XorgTesting wikipages talk about emailing list before code changes and reporting test results. I don't see either of this. The RepoPolicy says Write access to other branches is controlled by the branch owner. The release manager is the owner of the release branch. Who are the branch owners? Who are the release mamagers? Where is this documented? How are they assigned or how do they volunteer? ReleaseWorkingGroup mentions a 6 months cycle. I assumed that is for X.org as a whole and not for invidual components. Nevertheless I don't see any 6 month cycle for X.org or xorg-server. That wiki page also points to a list URL for proposed schedule. but the URL appears to be an unrelated archived list email. The ReleaseHOWTO wikipage doesn't appear to go into detail for specific module release engineering scheduling and coordination for the xorg-server and X.org as a whole. Some of the wiki has deadends -- links that go to This page does not exist yet. and many wiki pages are redirected. So maybe the wiki does have the release engineering schedule, policies, and steps documented, but they aren't followed, adequately explained, are disjointed (steps not organized or linked from same place), are very out-of-date and not applicable, or I just simply can't find them (missing links?). Basically I am looking for documented X.org details for release engineering for individiual components/modules/packages, xorg-server, X.org as a whole: - who is responsible? who helps? - release dates and/or deciding when to release - release schedule (locking tree, locking APIs/ABIs, builds and tests, merging fixes, etc.) - regression testing and quality control. Required tests before and during release. - X.org specific source code control: naming policies for releases, etc. - required communication with end-users and outside packagers/vendors - triaging bug tickets for release engineering planning/scheduling - version numbering policies, alphas? betas? release candidates? - library version numbering policies - distribution of test builds and final releases - documentation policies required by release engineering - security and how it pushes or overrides normal release schedule - and since X.org is very modular and broad: communication about backwards incompatible API and ABI changes and the effects on X.org, xorg-server, and the various components. - what has the elected board discussed for improving or changing the release engineering processes and scheduling? (I know this is just a simple overview and each of these have many details.) Jeremy C. Reed p.s. While I am pointing out problems, I don't want this thread to target anyone. My goal is to be proactive and get the release engineering policies defined (if needed) and well documented here. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Mon, 2009-06-08 at 12:24 -0500, Jeremy C. Reed wrote: - what has the elected board discussed for improving or changing the release engineering processes and scheduling? Just to address this one point, recall that the Board is explicitly not a technical body. It exists to govern the organization, not the code. Now, with my board hat off. De facto technical governance has been somewhere between meritocracy, junta and hazing ritual since approximately the 4.4/6.7 split. The release engineering goals have been fairly loose guidelines rather than strict policy. We could certainly use more rigor, but I suspect that's more about people actually getting off their butts and doing the work than about writing it down. I mean, we say we do katamari releases every six months, but we clearly don't; writing it down and underlining it strenuously isn't going to make it suddenly better. So instead we have a moderately demand-driven release model that happens to trigger the guilt reflex after about nine months. Individual components sync up with whatever server they think is convenient, but practically speaking there's only like five of those, and they're pretty much always buildable against at least the most recent server release and git master. The server goes to ridiculous effort to avoid breaking ABI and bumps a major number internally when it does. The library interfaces never break, ever, with minor exceptions for non-app-facing libraries like libXfont that really deserve to die painfully. Testing is... informal is the polite word. Nobody's stepped up to do it rigorously, so no one does it. Security is handled out of band like any other project. We'll release patches for at least the most recent release, probably do a point release for same, and anyone shipping anything older gets to backport. The actual server release is typically a two or three month cycle of the release engineer branching, cherry-picking fixes from master while skipping nonsense, and either cajoling other people into fixing showstoppers or (more realistically, although unfortunately) superheroing it themselves. Eventually they get sick of it and call it 1.7.0. Then people actually test and you do a 1.7.1 a month later. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Mon, Jun 8, 2009 at 1:20 PM, Adam Jacksona...@nwnk.net wrote: Testing is... informal is the polite word. Nobody's stepped up to do it rigorously, so no one does it. Peter poked me a while ago to work on autotooling xtest. I have it just about working nicely to where you just run make check and sit back while tons of tests fail. Should be ready for public consumption in a week or so even if some of the edges are still pretty sharp. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
