faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: So... this is 4.2?
by YAC on Saturday 03/May/2008, @09:46
|
The problem is that KDE releases never reach a high level of stability because new stuff is added that does not reach a high level of stability before the release.
IIUC, this standard method would avoid that problem, which is probably why it is a text book method.
There are other methods that also achieve this such as having a stable branch and an unstable branch. New stuff is always added to the unstable branch and then copied to the stable branch when it is sufficiently stable.
Any method that avoids including new and unstable code in what is supposed to be a stable release will work. Experience has shown that the current KDE method doesn't avoid that. Releases include code that isn't ready for prime time yet and the result has been that KDE does not become more stable with each release. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: So... this is 4.2?
by ac on Saturday 03/May/2008, @13:12
|
you realy have to stop spreading fud....
there is no standard "textbook" way of doing softwaredevelopment. and in the days of dvcses your proposal is long deprecated. if kde wants to use more branching, every new feature should get its own branch, which are merged back to trunk when the new code is stable.
though svn isn't meant to be used like that, so heavily using branches in the main repository is actually no option for kde today.
having more than one main-branch like you propose is a maintenence nightmare for big projects...
but thats not the point. kde already does what you want. its called the feature freeze, and like its name suggests, it doesn't allow new features in the repository when a new release is stabilizing.
|
[
Reply To This | View ]
|
Re: So... this is 4.2?
by JRT on Tuesday 06/May/2008, @06:57
|
It is not my intent to spread FUD. I am asking for higher quality. Or, stating that higher stability in releases is needed.
You are correct that there is NOT one standard textbook method of doing software development (one dead Straw Man) -- there are many. However, there objectives which they must meet.
I do not see that the idea is long deprecated since other OSS projects use other models which I believe are better.
Next Straw Man. I made no suggestion about using many multiple branches. That is something which you brought up.
I am suggesting EITHER earlier branching for release branches or (not my first choice) having a stable and an unstable release branch. Such an extra branch might actually make thing easier. Do you have a citation that would support your unsupported statement (is this just your opinion) that having another branch would be "a maintenence [sic] nightmare for big projects". Quite the opposite is, in general, true.
Small projects can use most any development method. It is large projects that need something more structured. The KDE project has grown and it now needs more structured methods. The proof of this is what I stated: lack of stability and regressions along with new features that were in releases before they were ready for prime time.
You seem to have missed what I said about a "feature freeze". I said that pre-alpha branching can replace a feature freeze. Obviously, I don't think that the feature freeze accomplishes what I think is necessary or I wouldn't have suggested that change was needed. Some of the new features added to KDE 3.x.y didn't stabilize enough before they were released.
So, your argument reduces to 'no you are wrong'. Do you have any suggestions? Or, are you just going to use rhetoric and logical fallacies to defend the status quo?
|
[
Reply To This | View ]
|
|
Re: So... this is 4.2?
by dkite on Saturday 03/May/2008, @13:16
|
How do we know whether something is stable or not. It is tested. Why is it tested? It is released. The challenge is to devise some means of broad testing of software. So far the best answer is to release it.
And pray tell, who is going to merge the unstable to the stable branches? That hurdle alone dooms the idea.
Free software isn't a product. It's a process. Methods that work (some of the time) in well funded turnkey solutions usually end up harming free projects.
Why do I say that? Write 10 rules, enforce them vigorously, and see how many developers you have after a year.
Derek
|
[
Reply To This | View ]
|
Re: So... this is 4.2?
by JRT on Tuesday 06/May/2008, @07:17
|
It is axiomatic that stable releases should not contain unstable code.
I believe that I have made two suggestions about how software can be released for testing without releasing a 'stable' release that isn't.
So, the Linux Kernel project is doomed? I think not. Who merges new features? Obviously, the person that wrote them and wants them included in the release.
Free software may be a process, but ultimately, it must deliver a product. If it doesn't ever deliver a stable product, then it is only entertainment for the developers.
NO! I would never try to rigidly impose rules. Commercial software companies have already found out that this is a bad idea. Having a good process and maintaining standards are different.
We have rules in the KDE project. Some of them are even written. I was told that I couldn't fix KView to conform to the KDE GUI standards because it would violate the rules to do so. But, most of our rules are unwritten. They seem to be enforced vigorously and we do loose developers because of them. Then we have the unwritten OSS rules that don't seem to be enforced and need to be.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
