Change release schedule 4.2 and schedule for 4.3

[Chani]

On Tue, Sep 9, 2008 at 2:10 PM, Pau Garcia i Quiles
<pgquiles at elpauer.org> wrote:
> 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 :-)
>

good points. you're right about that.
I actually didn't lose more than about an hour of the code I wrote at
akademy, because I had a habit of pushing all my branches to gitorious
:) now I just wish my notes had been in that repository too ;)

-- 
This message brought to you by evyl bananas and the number 3.
www.chani3.com