From Fedora Project Wiki
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
i'm going to try using this page to keep track of work | i'm going to try using this page to keep track of work, and generally failing miserably | ||
= working on: = | = working on: = | ||
* 2.6.33 on | * 2.6.33 on F-12. | ||
* 2.6. | * 2.6.34 on F-13. | ||
* 2.6.35-pre on rawhide. | * 2.6.35-pre on rawhide. | ||
Revision as of 19:04, 16 June 2010
i'm going to try using this page to keep track of work, and generally failing miserably
working on:
- 2.6.33 on F-12.
- 2.6.34 on F-13.
- 2.6.35-pre on rawhide.
todo:
- aesni-intel issues with dm-crypt (https://bugzilla.redhat.com/show_bug.cgi?id=589390) <= rawhide
- try to clean up the kernel wiki pages a bit.
- r8169 issue for dgilmore (https://bugzilla.redhat.com/show_bug.cgi?id=538920)
- http://koji.fedoraproject.org/koji/taskinfo?taskID=2149616
- emailed upstream maintainer
- fat issue from fedora-devel-list (https://bugzilla.redhat.com/show_bug.cgi?id=587126)
- spot's graphics lockup issue?
- squashfs ppc64 (https://bugzilla.redhat.com/show_bug.cgi?id=534080)
- radeon on F-13 (https://bugzilla.redhat.com/show_bug.cgi?id=588921)
- clmulni ghash noise (https://bugzilla.redhat.com/show_bug.cgi?id=586954)
solved:
- fill out fesco questionnaires (https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations)
- perf timechart doesn't work? (https://bugzilla.redhat.com/show_bug.cgi?id=570821)
- http://kyle.fedorapeople.org/upower-cache-units.diff
- squashfs-tools fix (https://bugzilla.redhat.com/show_bug.cgi?id=523504)
- https://bugzilla.redhat.com/show_bug.cgi?id=560031
- backporting nhorman's patch to sane kernels for abrtd.
- aesni-intel issues with dm-crypt (https://bugzilla.redhat.com/show_bug.cgi?id=571577) <= F-13 workaround
FESCO Election Questionnaire (WORK IN PROGRESS)
- Posted by Bruno: What is your take on the granting exceptions to Fedora packaging rules for Mozilla products in order to use their trademarks? For context, see the recent Thunderbird discussion on the devel list.
- I believe these things have to be addressed on a case-by-case basis. While I believe that the Mozilla trademark policy may harm us by delaying us from occasionally shipping patches, I believe it would harm the distribution worse to not have the name recognition and icons of the Mozilla project. Perhaps some passive aggressive push back could encourage the Mozilla Foundation to change their policy, but I do not believe stripping the icons and names as Debian has done with iceweasel is beneficial for our users either.
- Posted by Bruno: What is your take on guidelines for packagers with respect to adding new features into supported releases? I expect there will be exceptions, but there should be some guidance for what is generally expected.
- As a kernel developer, I prefer to err on the side of cautious and conservative updates, and the principle of least surprise for the end user. That said, the kernel is probably one of the worst cases for this. Mind you, they live for a very very long time in updates-testing before being pushed anywhere near updates. That said, aside from bugs, which will always occur, the kernel's feature set does not change much from release to release unlike much more visible packages like desktop environments, etc., so the same rules may not apply as directly. In general, I think it depends entirely on the maintenance policy of the upstream project, the competence of the packager/maintainer, and the expectations of the users. We, as a project, do not attach a technical competence requirement to packagers to be able to fix bugs in their own packages, so expecting them to be able to backport security fixes from possibly vastly divergent development branches may be a tall order. In summary, I would prefer conservative updates, but there are many factors that effect that, so in effect "it depends."
- Posted by Paul: What are three things you intend to work on and complete during your time on {the Board,FESCo} -- in other words, personal goals for your term?
- There are three things I would like to see from FESCo this year.
- Foster an environment of technical leadership from FESCo. Not issuing edicts, but helping set the technical direction of the Fedora OS.
- Push for a Fedora Technical Lead who is trusted by the developers and FESCo in the same way that the Fedora Project Leader rallies the community, this is related to #1, obviously.
- Less redundant work for FESCo, there's no reason every provenpackager request must be voted on by FESCo. I confess at least to probably not being the most qualified person at Fedora packaging to be able to vote on them, whereas I think I have the experience to serve in other capacities.
- There are three things I would like to see from FESCo this year.
- Posted by Paul: (FESCo nominees) Name a new technical capability that you feel the Fedora distribution does not include now, but should have by the release of Fedora 15.
- It would be supremely excellent if KMS was working to a point where we had proper oops-over-X display working.
- Posted by Paul: (Board nominees) Other than the general idea of better communication, name a specific improvement you think would help one or more Fedora teams work more efficiently, either individually or together.
- N/A
- Posted by Michael: How are you going to represent the Fedora community (the voters) on {the Board,FESCo}: They vote once, you decide for the period of your appointment - or you ask for input and base your decisions on that?
- I believe that in electing me, the developers who vote have put their trust in me to base my decisions on my experience. That said, my opinion is rarely ever made up, and I would welcome anyone to contact me publicly or privately with issues they may want to see addressed.
- Posted by Michael: What is your hidden agenda behind running for {the Board,FESCo}? (Asked with a wink, may be answered with one ;) )
- Taking over the world, obviously. ;-)
- Posted by David: (for both FESCo and Board) There appears to be a disturbing increase in the amount of flames/annoyance/anger/frustration within the the Fedora project of late. To what do you attribute this, and how do you plan on addressing?
- I attribute this to a lack of a coherent direction for the project. Half of the packagers seem to be content making something for their own consumption, whereas the other half believe our direction should be producing a coherent and consistent operating system, as opposed to a collection of packages we collect and ship every six months. I'm not sure what the best way of addressing this, as it reflects a fairly deep schism in the community. It seems no matter what is done, half (obviously it isn't a fifty/fifty split, but it serves the purpose of illustration) the community will be unhappy with either direction, so perhaps more tolerance of the opinions of others with some offline reminders to people when they cross the line would avoid the confrontational and long winded email threads which have been occurring.