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