28 Jan
2012
28 Jan
'12
8:29 p.m.
Followup: 2/3 PM EST? Or back such as 12 PM EST?
Also, can we get a list of topics?
The few ones I can think of (I detached myself from Trinity stuff the
past few months):
Git migration
Qt3/TQt3?
CMake - what's left
Observations/Concerns
--
later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu
28 Jan
28 Jan
8:53 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
On 28 January 2012 15:29, Robert Xu <robxu9(a)gmail.com> wrote:
Followup: 2/3 PM EST? Or back such as 12 PM EST?
Also, can we get a list of topics?
The few ones I can think of (I detached myself from Trinity stuff the
past few months):
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?
10:20 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
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
11:38 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
On Jan 28, 2012 5:21 PM, "Darrell Anderson" <humanreadable(a)yahoo.com>
wrote:
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.
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.
L0ner has noted serious interest in the website.
> 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
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
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. :)
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?
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.
29 Jan
29 Jan
6:01 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
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? 
6:51 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
Darrell Anderson wrote:
I care. I care about koffice too.
What's the problem with kdebindings? The kmozilla & other xpart
infrastructure is part of that too. I've been developing with the 3.5.13
release sources though, so I may have missed the issues because of that.
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?
8:08 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
What's the problem with kdebindings? The kmozilla
&
other xpart
infrastructure is part of that too. I've been developing
with the 3.5.13
release sources though, so I may have missed the issues
because of that.
Yup, go back a few threads. I can't build tdebindings from GIT with qt3 or tqt3. I can
build 3.5.13 too. :) Everything else in GIT builds.
Darrell
6:53 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
2012/1/29 Calvin Morrison <mutantturkey(a)gmail.com>om>:
On Jan 28, 2012 5:21 PM, "Darrell Anderson" <humanreadable(a)yahoo.com>
wrote:
Build bugs should be marked as a blocker. It blocks compilation.
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.
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?
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.
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
8:09 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
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.
8:18 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
> L0ner has
noted serious
interest in the website.
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.
Please remember this etherpad: :)
http://trinity.etherpad.trinitydesktop.org/24
28 Jan
28 Jan
9:33 p.m.
New subject: [trinity-devel] [Cross-Post] Meeting 01 Feb 2012
Robert Xu wrote:
Followup: 2/3 PM EST? Or back such as 12 PM EST?
Also, can we get a list of topics?
The few ones I can think of (I detached myself from Trinity stuff the
past few months):
Git migration
Qt3/TQt3?
CMake - what's left
Observations/Concerns
Also window managers maybe, based on the kwin discussion previously on
the list.
4479
days inactive
4480
days old
10 comments
5 participants
participants (5)
-
Calvin Morrison -
Darrell Anderson -
Julius Schwartzenberg -
L0ner sh4dou -
Robert Xu