Slashdot Mirror


Criticisms of KDE 3 Release Process

An anonymous submitter sent in a link to a recent email from the kde-devel list, criticizing the release process. Hopefully the KDE guys can work out any problems and keep up the good work that we've seen in the past. Update: 03/10 14:20 GMT by M : One of the comments below points out that another KDE developer has made an extensive response to the original criticisms.

5 of 187 comments (clear)

  1. Professionalism == Bad by lkaos · · Score: 5, Insightful

    The best part of developing free software is that it is low stress. People tend to get all bent out of shape about it. I think this is a pretty good example of what happens when people get stressed out about something that people are for the most part doing because they enjoy it.

    So the KDE guys got together and were inspired to perform lots of last minute hacking. More power to them! So what if the 3.0 release is delayed or has a few issues. I think these three guys who signed the letter were just jealous because they weren't involved in the process.

    I don't use KDE, and never liked it, but I have to stand up for the developers here. Just enjoy developing the software and stop bitching because there aren't 'hard freezes' before a release.

    --
    int func(int a);
    func((b += 3, b));
  2. Not Release Problems by BadlandZ · · Score: 5, Insightful
    Look at the artical, it criticizes decisions made, but it's not criticizing KDE itself, or any release of KDE. It's critical of the _process_ not the _release_!

    It's a failing of leadership (if the criticism is true). I think it's important to remember 2 things here:

    • KDE releases are important to the acceptance of Linux on the desktop. More judgement of the FINAL PRODUCT should be focused on, not just some little pain in the ass details about getting it ready.
    • OK, thousands of programmers coding for you, for free can't be a bad thing, ever.

    In light of this lack of management discovery, maybe a couple programers will start to see all the recent criticizm's of software managers (as in recent stories here) may be not as useful as trying to actually support managers of projects (espically OSS ones) a little more.

  3. This happens in large projects. by JanneM · · Score: 5, Insightful

    This is in no way unique to KDE; large development projects sometimes stumble even with the best of intentions by those involved. The Open Source community is unique in that everyones dirty laundry gets aired in public. This can make the process seem unruly, haphazard and chaotic compared to closed development - the truth is that the same kind of conflicts, friction and occasional disasters occur there as well, but hidden from view.

    I'm not a KDE user myself (I prefer gnome), but I'm confident and hopeful that the KDE development team will get past these problems and produce another good release. They've done very good releases in the past, and there's no reason for them not to do it again.

    /Janne

    --
    Trust the Computer. The Computer is your friend.
  4. Re:Professionalism == Good by Arandir · · Score: 4, Insightful

    Professionalism is a Good Thing(tm). However what your PHP calls professionalism might just be artificial. Sticking to a release date no matter the state of the code is unprofessional.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  5. Re:Hello! by Anonymous Coward · · Score: 5, Insightful

    1) Packages missing from the release entirely

    Release Candidate != Release

    2) Rampant compile problems

    Really? Compiles fine here and elsewhere. Of
    course, if it doesn't compile for you the proper thing
    to do is report the specific problem to
    the mailing lists immediately.

    3) Last-minute changes to build requirements that cannot be met by
    many developers without an operating system upgrade


    Hehe, this one was funny. He was complaining
    about a requirement for developers compiling
    out of cvs
    to upgrade to gnu autoconf > 1.50.
    Those compiling from the release tarballs won't
    even be affected, and the "operating system upgrade"
    consists of downloading autoconf and
    compiling it. Took me literally 3 minutes.

    4) Many outstanding bugs

    Well sure, all software has bugs, even when released.
    Released software shouldn't of course have
    critical bugs so when you find them, you
    should report the specific problem to
    the appropriate forum (mailing lists at this late
    date in the cycle) immediately.

    This whole thing was just an overation from 3
    developers who felt left out when they weren't
    invited to the recent KDE hacking session. It's
    unfortuate, but the sky is not falling.

    The best way to help KDE is not complain but
    to download the release candidates, compile
    them (yeah, you can do it - ./configure; make;
    make install), test, and report bugs.