2012/1/29 Calvin Morrison <mutantturkey@...>: > > On Jan 28, 2012 5:21 PM, "Darrell Anderson" <humanreadable@...> wrote: >> >> > Git migration >> > >> > Qt3/TQt3? >> > >> > CMake - what's left >> > >> > Observations/Concerns >> > >> > Bugs: >> > what is high priority? >> > should we mark certain bugs blocker bugs? >> > >> > Qt3 - do we have any problems with Qt3 right now >> > (performance or otherwise), that we should change? now is >> > the chance with an ABI change. >> > >> > Artwork - seriously, we need to figure this out. Dead >> > serious. no more joking around >> > >> > Website - is this even an issue? >> >> How do we audit the bugzilla? What is a blocker to one person might be a >> non issue to another. For example, a bug related to compiling a package >> might affect only certain distros. Nonetheless, I think all >> compiling/building bugs should be bumped to blocker. > > Build bugs should be marked as a blocker. It blocks compilation. > >> >> The real challenge is which usability bugs are blockers, critical, normal >> or just a nuisance? How do we collectively decide that? > > I think we mark blockers ones that are fundamentally broken, or something > that effects a wide userbase. > > >> >> There are dozens of paper cut bugs that must be resolved for R14. Almost >> all of them went untouched with 3.5.13. Those types of bugs affect >> perception of the project. We still have four months to go before the >> tentative release date, which is a lot of time to address those kinds of >> bugs. I don't mind if the release date is postponed to quash a majority of >> those bugs. There are several people involved here who could resolve those >> kinds of bugs while Tim addresses the more difficult bugs. I wish that would >> happen. :) >> > > We are making good progress already. A good amount of bugs have been closed > since 3.5.13 and many more will be. Many are marked Patch available. > >> Perhaps we should have a check box in the bugzilla that identifies a bug >> as a paper cut candidate. >> > >> With respect to the web site, I thought others were working on that. Is >> that not going to happen? >> > > L0ner has noted serious interest in the website. > Fact. I even have a proposal for new layout and undelying engine/structure. But I'm busy too much with exams/PKGBUILDs for arch to continue work. I'll work on the website more after I finished PKGBUILDs. Oh, and layout can bee seen here: http://l0ner.github.com/html/ Please note that it is unfinished, I need to polish it a little. >> tdebindings. Whether tdebindings is overhauled is not as important in the >> short term as much as everybody is able to build the package. Can anybody >> build tdebindings? I was able to under 3.5.13 but not since GIT. > > I would say the priority is somewhere around that of koffice and khtml. Who > cares about kdebindings anyway? > >> cmake. Just about everything needs to be converted. tdesdk and tdewebdev >> were started and they should be candidates for the next wave of conversions. >> We once discussed that we should focus on two to three conversions per >> release. Unless somebody has devised a fast way to convert without >> sacrificing quality we probably should remain with that agreement. >> >> If we had a cmake conversion how-to at the wiki some of us could help >> convert packages to cmake. Those of us who haven't yet done that could start >> with smaller packages. >> >> We need a quality assurance check list to ensure cmake conversions do not >> leave out any component or build option. >> >> Regarding window managers, I prefer that discussion take place post R14. >> We have enough on our plate now. I think I read somewhere that to be fully >> XDG compliant that any window manager is allowed to be used, but we should >> discuss whether that is a project goal. >> > > Xdg is a specification. A guideline. Not an API or a hard target. This is > low priority. An enhancement bug has been filed. > > Calvin