Change release schedule 4.2 and schedule for 4.3

Pau Garcia i Quiles pgquiles at elpauer.org
Tue Sep 9 22:10:46 BST 2008


Quoting Chani <chanika at gmail.com>:

> if it was "always summer in trunk", features would not be allowed in
> until they're already reasonably stable. people could develop in a
> branch (requiring a VCS that does cheap branches, ideally local
> branches because nobody wants to see my "this is a mess, let's try
> again next week" commits) and stabilise as they go, not having to
> worry about a feature-freeze deadline.

If with "local branches" you mean "a branch located in my PC (i. e.  
private branch) instead of KDE's DVCS repository", I disagree.

In fact, I do want to see your "this is a mess, let's try again next  
week" commits.

Why?

a) Because in case your laptop breaks or is stolen, or you pass away,  
or an earthquake shakes your house, your code would still be  
available. Otherwise, we may be waiting for a feature to arrive, then  
the worst happens, and development of that feature needs to be started  
from scratch.

See, for instance, what happened to Jacob Rideout last year: he had  
this really nice feature for Sonnet (language autodetection:  
http://blog.jacobrideout.net/2007/01/language-detection-works.html),  
he suddenly disappeared and we were left with no code for that. If  
code had been committed to KDE's repository, even to a "hey, this is  
99% broken" branch

b) Because my feature might depend on your feature and, even if your  
code is broken, it's still good for me to start with my development.  
Sure, I can pull this or that branch from your repository, but

c) Because if your code is not available in the KDE repository and I  
do not read planetkde, dot.kde.org and all the mailing lists, it might  
perfectly go unnoticed. We do have that risk now but it will increase  
exponentially if people start working in private branches. It is very  
frustrating to work on some code only to find the day before you  
intended to make your code public, someone comes with the same exact  
feature (or 90% the same).

d) Because I like to see what you did wrong to avoid doing that  
myself. Learning from others' errors is very useful.

e) Because I'm curious :-)


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)





More information about the kde-core-devel mailing list