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

List:       kde-core-devel
Subject:    Upcoming 2.2 release schedule, bickering and bugs
From:       George Staikos <staikos () kde ! org>
Date:       2001-06-21 6:11:50
[Download RAW message or body]


   I think we can all agree that some very unfortunate things have happened 
recently.  Many of you are quite upset over this.   I can understand this...  
some of these licence issues have impacted my work as well.  However, I don't 
think it's worth fighting, arguing or complaining about.  Let's just salvage 
what we can and move on.  Code can be rewritten.  In fact, rewriting it 
generally tends to fix it anyways.  It's not fun, but it's more productive 
than writing email.

   Now this brings me up to my major point.  I really feel that we should 
delay the release of 2.2 by approximately another month (or even more if 
necessary).  2.1.2 is quite stable and usable as released.  People can wait  
for most of these new features in 2.2, and quite honestly, I think 2.2 still 
needs to cook.  I've seen all kinds of new code crammed in at the end here, 
and I'm sure it's not all done or "bug free" (whatever that means) yet.  I 
know that my SSL code is certainly incomplete and if I don't get the last 
bits done before the release date, then I am faced with removing a major 
feature and roughly 1500 lines of code and many many hours of work.  This is 
not my main concern though.  I'm most concerned with the design and future of 
KIO in general, and some of the slaves.

  - We have issues with kio_smtp and kio_pop3 licencing, if I'm not mistaken. 
 These are critical components and must be fixed.
  - kio_smtp _really_ needs to be implemented in KMail.  I know that Aaron is 
working on this and he _must_ need more time.  We need to support SMTP Auth 
and it would be very nice to see SSL and TLS support too.  Also, we all know 
that having two copies of the same code, one of which is non-reusable, is a 
waste of effort.
  - KSASL was removed.  This needs to be rewritten.  I don't think it's a 
huge undertaking but once again, we need this.
  - kio_http and kio_ftp (along with ldap and nntp which are not much of a 
concern right now) are not using TCPSlaveBase.  This means they are 
duplicating a lot of code, and quite honestly, some of the code in kio_http 
is outdated.  I don't plan to update the SSL code there.  Porting to 
TCPSlaveBase will fix a fair amount of this.  In addition, kio_http is 
becoming very unmaintainable very quickly.  We've seen many bugs pop up 
recently and code get broken due to the spaghetti nature that is evolving.
  - Proxying may still need more work.  Dawit can provide more feedback on 
this, but I'm betting that we still don't support SSL proxies very well.

   This is just KIO alone.   This should be enough evidence that 2.2 needs 
more work.  I don't think any of these are really new features.  They're 
cleanups and bugfixes by my definition.  (and of course licence fixes)  
Again...  We don't have an urgent reason to get 2.2 out the door right away.  
Let's hold back and clean things up some more.  I'm sure the docs and 
translation teams won't mind either.  I know that portions of KDE are 
undocumented (either for users or developers) so it would even be a time for 
others to catch up too.  I'm not promoting adding any new features.  Just 
cleaning up what we have... tying up loose ends...  finishing incomplete code.

   I really don't want to see a big 2.2.1 patch shortly after 2.2.0 fixing 
all the bugs that we could have fixed 2.2.0 but couldn't because we rushed it 
out the door.  I think this would also give us a chance to sort out kwin 
issues.  I don't know much about this code, but judging by the mailing list 
traffic, I think a few problems have surfaced there.  Let's give the kwin 
coders some time to reorganise and put together a plan to deal with this.  I 
imagine there are many little things that could be fixed in khtml and it's 
components too.  Need I continue?

   I say again....  Let's slow things down, think over our plans for 2.2 and 
what we wish it to be, and fix the things that really need to be fixed.  2.2 
will be the third major release (2.0,2.1,2.2) in less than a year.  That's a 
very impressive release schedule.  I don't think anyone can complain if it's 
closer to the end of that first year.



   Finally, on a related note pertaining to the future, I think we should 
start making more detailed release plans including target feature lists.  I 
know that many [perhaps most] features develop closer to the middle or end of 
the development schedule, but I think it would help give us a better picture 
of where each release is going and what should be focussed on.  People who 
work on various components always have ideas on where things should go and 
can at least give some input on what should be targetted for an upcoming 
release.


-- 

George Staikos

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