28 Jan
2012
28 Jan
'12
10:20 p.m.
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.
The real challenge is which usability bugs are blockers, critical, normal or just a
nuisance? How do we collectively decide that?
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. :)
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?
tqt3. Good long-term idea but for R14 I would like to see tqt3 become a secondary issue as
long as everybody can build against qt3. Unless there have been certain design decisions
already made otherwise, I would like to see qt3 phased out in favor of tqt3 after R14.
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.
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.
Darrell