[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: How things work in KDE once in code freeze mode [Was Re: ISO/IEC  14652  and localization]
From:       Ming Poon <gexcfxyy () umail ! corel ! com>
Date:       2000-04-01 0:00:08
[Download RAW message or body]

Cristian Tibirna wrote:

> On Thu, 30 Mar 2000, Ming Poon wrote:
>
> I think there wasn't any decision on this direction. I, however, believe
> and hope that no unstable branch will be created. KDE-2 needs a lot of
> work as is. All help we can get should be gently directed into polishing
> KDE-2 very very well.

We will see what we can do once we are more up to speed with the KDE 2 stream
of code. The other possibility is that we can host these new KDE control panel
modules temporarily at opensource.corel.com until KDE  2 is done. We are still
working on the spec on these new open source modules.

> Only kdelibs freezes now. Please look at
> http://developer.kde.org/development-versions/kde-2.0-release-plan.html
>
> Freezing doesn't mean that no code modif is possible. It's just that only
> bug fixes are accepted.

We will definitely share some load on bug fixing once we are up to speed.

> > On several side notes, I have also secured half a dozen of our full time
> > QA people to help you folks with the KDE 1.9 cycle. That is the least we
> > can do for now to contribute to KDE 2.0 until our developers catch up
> > with your stream of code. So do expect a lot of bug reports from us
> > whenever your beta cycle is ready.
>
> Excellent. Ah! And no need to wait for the beta cycle. Any help we get now
> is very welcome.

We can probably start in two weeks. The person that will be doing the nightly
builds will be away on training the whole next week. Then he will probably
need a week to ramp up to set up the automated builds. Once that happens
automatically every night, then our QA folks can start to learn and explore
KDE 2 and report bugs back.

> Hmmm! As one of the main maintainers of that page, I wonder what you mean.
> I just added two jobs  a few days ago. True that both were just taken away
> immediatly, but what can I do if there is such a large interest in KDE?
> :-)

That is right. You guys are too fast. We just got rejected by KurtG too on the
task of maintaining kBiff which only opened for about 48 hours. To be honest,
we did not volunteer for any of the KOffice stuff ;-).

> Anyways, the page is pretty carefully maintained. If there are problems
> inthere, please let me know directly.
>

Almost all the non KOffice stuff are all taken or done as we were told anyway.

> > We have also finally hired a full time UI designer for KDE to help you
> > folks with any UI design issue. His name is Tom Heferek and he is a very
> > senior UI designer with lots of experience. However, he is new to Linux
> > and KDE so give him some time to ramp up and he will join the kde
> > look&feel group as soon as he settles in. (He only started with us two
> > days ago.) It took us almost 6 months to find a good and experienced UI
> > designer for KDE.
>
> Excellent thing. Thanks, Corel. Could we get some press coverage on this -
> using Mr. Heferek's credentials as arguments -  ?

We can once Tom actually starts to join the KDE discussion. We are giving him
a couple of weeks of orientation to convert him to Linux, KDE, and the whole
new open source model.

> > We are also looking into integrating our Windows and NFS connectivity
> > code with KDE 2.0 as well but I don't expect we will have a good
> > solution on this soon enough for KDE 2.0.
>
> Well, kde-2 already has good SMB support. I need to understand what you
> mean by NFS connectivity. NFS is transparent for the user, normally.

We played with konqurer stuff a bit. It did not work very well on our network
that has over 3000+ nodes and different domains. We support NFS sharing and
I think it is mostly UI work that needs to be merged in the NFS case.

> There is a discussion about reorganizing the standard hierarchy in
> KControl going on on the kde lists. Please, invite on our behalf your
> experts in KControl to join the discussion.

Sure, they are already monitoring the discussion and learning the new kcontrol
module architecture. The developer who hacked the kpanel (where some of
kicker's ideas came from) is also in the process of studying KDE 2 in detail
to come with an architecture document. It is only about a week since he
started this. Once his document is more concrete, we will pass it upon all you
KDE experts for review. The main purpose of this doc is to get some new
developer who is not familiar with KDE to become familiar in a less amount of
time. If you are guys are doing this too, then please contact him so we can
share the load of work. His name is Alexei Rousskikh (alekseir@corel.com).

> About the Corel kcontrol modules, Corel developers will find out the
> technology changed quite a bit, but the porting isn't rocket science. An
> essential thing about KControl modules is that they need to be portable.
> We planned to add a KDE main package containing only Linux code, and
> perhaps Corel involvment will help us to get this done faster.
> Unfortunately, there could be problems even with Debian-to-other-Linuces
> portability, so this will have to be carefully planned.

But at least if we put our code up in your CVS tree, then it is a good start.
People can then put in enough #ifdef stuff in to make it work with other
Distros too. There was some guy from Red Hat who contacted us a while ago that
they are taking all of our changes in KDE 1.1.2 and making it run on  Red Hat
in their next version. Let us know how you would like to proceed. We can do it
slowly too and put one up at a time.


["mingp.vcf" (text/x-vcard)]
-- 
The address in the headers is not the poster's real email address.  Do not send
private mail to the poster using your mailer's "reply" feature.  CC's of mail 
to mailing lists are OK.  Problem reports to "postmaster@umail.corel.com".  
The poster's email address is "mingp@corel.com".


[prev in list] [next in list] [prev in thread] [next in thread]