Author: JT Smith
Category:
Author: JT Smith
Category:
Author: JT Smith
Category:
Author: JT Smith
Category:
Author: JT Smith
List: kde-core-devel Subject: Re: KDE Development Policy From: Dirk MuellerDate: 2002-03-09 12:03:28 [Download message RAW] On Fre, 08 Mär 2002, Neil Stevens wrote: Hi, > 1) Packages missing from the release entirely (1) That was correct for a few hours after the rc1 announcement, in which I took a round of sleep. I fixed the problem immediately after waking up and talking with Stefan Westerfeld for coordinating the version number increase. > 2) Rampant compile problems Like ? Indeed there are problems on non-gcc platforms, which made us require updating the admin directory to a newer libtool version. However, thats your point 3 already. > 3) Last-minute changes to build requirements that cannot be met by > many developers without an operating system upgrade (2) Sorry? Let me put the facts straight: - The libtool update got necessary because of the RPATH encoding problems in the previously using libtool version. Furthermore the previously used libtool version was a dead end as well. It was the heavily self-patched version of a forked version of an outdated libtool development branch that never made it into any libtool release IIRC. - The libtool update was indeed very late, thats correct. But you have to remember that the _preparation_ of the update took some time as well (integrating libtool HEAD, fixing all the bugs in it, testing compilation under many setups). I personally can not judge about if this step was "good" or not, but I have to trust Michael Matz and Stephan Kulow upon this decision. - the libtool update does _not_ require an operating system upgrade. autoconf is a perl and m4 based package of less than 1MB size in source. compiling and installing it takes less than 5 minutes, it is compilable out of the box on about each and every broken system you can think of. Furthermore many newer distributions ship it by default anyway. If you upgrade your operating system instead of updating autoconf its your decision and not forced by KDE itself. - The build requirements update was a step to do anyway. We simply can not keep the compatibility with autoconf 2.1x and 2.5x over a longer period of time. For my personal opinion, adjusting the build requirements is better done for a major release like 3.0 instead of a "normal" release like 3.1. - autoconf is only required during make -f Makefile.cvs, which is not supposed to be run by the user who compiles KDE from source. They will download the tarballs and configure it just like all the tarballs before, even if you have an older version of autoconf. - If you think about it, almost all Linux distributions had to replace our outdated build system because it did not support many of platforms people want to use KDE on, like ia64 in example. - If you really consider the libtool update to be a problem, then feel free to: a) fix libtool to work with older autoconf versions b) maintain an "admin.old" directory with the older checkout for people to download and use. However I almost bet that replacing the admin dir before compiling is even more work than updating autoconf. > 4) Many outstanding bugs (3) Again, let me put the facts straight: - The incoming flow of bugreports is greater than the rate of fixed bugs for quite a while already. so its quite natural that there are many outstanding bugreports. - Many of the incoming bugreports are reported against KDE 2.2.0 or 2.2.1 and not reproduceable with CVS HEAD any more for quite a while. Do you really want to delay the release of 3.0 even more to collect even more bugreports about "obsolete" KDE versions that almost nobody (except Laurent from Mandrake) develops against ? - If you have a look at bugs.kde.org, you will realize that the amount of open bugreports went down rapidly during KDE III meeting. With the exception of khtml, which has about 800 open bugreports, and konqueror with about 380 open bugreports, every package has less than about 50 open bugreports, with many many less than 10 open ones. Except for khtml problems I would say KDE is in a pretty good shape right now, if you measure it by looking at the amount of open bug reports. - With the size of KDE and the amount of apps and the amount of users its unrealistic that you will reach the "open bug reports == 0" aim at _any_ time. If you have a better solution for scheduling the KDE release for a time when there are no open bugreports (or a way to achieve that), please let me know. > 1) When users and developers cannot build KDE, they cannot test KDE Those who can not build KDE and think its a KDE problem, should report the problems so that we can fix them. > 3) When the credibility of the KDE release policies are called into > question, users and developers are less likely to feel that > testing is of value, and stop participating. Okay, this might be painful for you to realize now, but what do you think we should do? update it after 3.0 ? screw kdevelop users who will not realize that their next minor update will have a new admin directory that is incompatible to their older one ? Wait for 3.1, which is probably not to be out before christmas ? Screw all the platforms then that need the newer libtool ? The only solution I see currently is providing a "configure" script for "make -f Makefile.cvs", that will pick up the "right" admin dir. I will ask Stephan and Michael to consider this. > The credibility of the release policies are further damaged by the > manner in which the decisions are made. For instance, the major > change to libtool, there was a minimum of discussion, with no > compelling bugs or reasons shown for making this drastic change. There were always major changes in the build system before a release to overcome certain platform incompatibilities. > The only remedy left for these KDE 3.0 ailments is to apply a "hard > freeze" to the KDE 3.0 source, release a third beta, to begin allowing > serious testing of KDE in real situations. Well, I'm actually doing that. Maybe even more people. I can't "dictate" anybody to do that though. > For KDE 3.1, however, more can be done. Having identified the > failures of KDE 3.0, we can trace the causes of these failures, and > avoid causing them again. As was already stated, the difference > between KDE 3.0 and recent releases has been changes in the "freeze" > policies in the period leading up to the final release. Again, let me put the facts straight: - KDE 2.0 development was in large ways different to KDE 3.0 development. There were _big_ architectural changes in kdelibs. We had to concentrate on getting it to work a lot more than with KDE 3.0, which is basically a port of KDE 2.0 with a considerable amount of fixes and improvements, but no major achitectural changes. - The mail with Waldo / Mosfet you quoted in your mail was _exactly_ about _long_ _freeze_ periods and the way it annoyed the developers. Therefore I tried to learn my lesson and made the 3.0 release schedule more open for developers. This was for example the case with the feature plan and the shorter "deep freeze" period. I do want to give the developers a bit more freedom, to keep them happy and not feeling pissed by my "the release coordinator has spoken" - rants. Maybe I was too loose this time, so probably we find the golden way of doing things for KDE 3.1. - I'm really pragmatic about the freeze. I do see commits on kde-cvs that I "don't like" either, but I usually don't try to rant the people, but instead check out the diff and try to review it. I actually do find bugs in the commits then from time to time, but usually I don't, mainly because I'm not familiar with the code in particular. In my opinion, if more people would do the same we would have a much higher level of quality ensurance than enforcing with brute force a "freeze period". the code doesn't fix itself nor does it become better if you don't touch it for a while. the stuff only moves forward if there are people who are motivated enough to constantly _push_ _it_ _forward_ instead of let it rot in the state it is. Unfortunately I see far too few replies to "broken" commits on kde-cvs, but again I'm not in the position to change it myself. I'm not a dictator of KDE and I don't want to be. Therefore, a freeze period is supposed to be a "mental barrier" for developers to make them think "lets make sure it works" instead of "lets implement this new cool feature". It doesn't necessarily mean that the amount of commits is going down, at least not IMHO. > >From the time of one week before KDE 2.2, until the final release, all > changes to the source had to be reviewed on the KDE mailing lists > (save, of course, trivial changes whose differences are included in > the log message). (4) The same is currently happening as well. Of course there are some patches that are so obvious that they don't require a review (this is a difficult rule though. as somebody might think something is safe while another one knows that it will horrible break things). > The justification for these changes was > explained very well by the KDE 2.2 release coordinator Waldo Bastian > in a mail to the developers (5), in which he said "[Y]ou will have to > respect release freezes" if you put your code into KDE. Hmm, I always tried to express that more gently, but if you find Waldo's mail okay, I will quote it in my next regular-rant mail ;) > In contrast, the time leading up to KDE 3.0 RC 1 is best described as > a flood of un-reviewed changes to the sources. (6) I don't agree here. > The flood was met with excitement, to be sure, because the flood > came from a rare opportunity for roughly 20 KDE developers to meet in > person and develop. This opportunity was not to be passed up, but it > could have been handled differently. I'm sorry. But sitting together in front of the same computer and hacking and discussing the same sourcecode is a lot _more_ efficient than making a patch, posting it, realize there was an error in it, and then remake it. We were also greatly influenced by a tool that allowed to rebuild KDE in a distributed way. this way a complete KDE rebuild only took a few minutes instead of several hours. I understand that it might have been difficult to keep up witht he commit rate at that time, but still I think it was worth it, because KDE benefited from it over all. Remember, putting so many developers in the same room also made us realize regressions _much_ earlier. For example people were notified about errors in their commits within a minute range instead of hours/days range during the usual "development". > If the developers in in the meeting felt that avoiding the mailing > list was the best way to maximize use of the meeting, then they easily > could have proposed a delay in the KDE 3.0 release, to allow for more > time to stabilize after the meeting, to allow for testers to catch up > with their time of great productivity. Well, the 3.0 release dates are not fixed, they are suggestions. In general it will be delayed when necessary (that is when people indicate in mails or irc messages to me that they urgently need more time). If you remember, you suggested a delay of 3.0 release by one week, and it happened afterwards, didn't it ? Is it not okay that I don't decide this on my own but instead wait for people asking me to actually have more time ? > Some have suggested a failure in the community-recognized leadership > of the KDE 3.0 release. While Dirk Mueller is respected throughout > the community, his ability to step in and enforce the policies and > release plans that everyone agreed to in the past has not been shown. Sorry ? Isn't it _you_ that is asking for _changing_ the release schedule that we agreed on before ? Again, please remember that I'm not the one who will sit there with a loaded gun and waits for somebody breaking the schedule. If you want a dictator or a person who manually confirms every commit or every change to KDE, then I am not the right person for this. In addition I claim that you will find nobody else in the KDE developer community that is going to do that and will be accepted. So, as a result of that, all I can do is trying to keep the people reasonable and establish the communication between the developers with different interests. Therefore I would not have ignored or refused a message from you telling me about your concerns with the libtool update (as an example). But instead you decided for a public rant, that makes the KDE development community look like a heap of fools who can't organize themselves. Again, I can't prevent anybody from doing that, but in general I would like to suggest to actually _try_ it the _regular_ way before starting to rant. It would make us look a bit more professional. Please don't understand the release coordinator job as a dictatorship role. It is clearly not. > Many in the community rely upon KDE, and as Bastian wrote, development > of the KDE release carries responsibilities as much as it does > privileges, and Mueller has not held the developers to these > responsibilities. The responsibilites have to be accepted by all developers. I can try to be more strict about enforcing the rules, but not so long ago I can remember somebody who tried to sneak in a new plugin for noatun just because "somebody else did something similiar". In my opinion this is not a form of being fair to the other developers. I have to pay my bills even though there might be other people who don't pay theirs. > New leadership for KDE 3.1 is needed. I'm sorry, but you again misunderstood "release coordinator" == "KDE leader". There is no such thing as "KDE leader of the day". > The KDE releases are the legacy of the entire KDE community, and > making sure those releases are good is the responsibility of every > developer and tester. This requires that all developers, regardless > of their social status, obey the written and unwritten rules of the > KDE development community. A mistake by a well-known developer can > break the release as badly as a patch from a novice, and the rules > were agreed upon with this fact in mind. Only by keeping the written > and unwritten agreements can all KDE developers and users continue to > enjoy the success they enjoy now I'm very happy that we agree on that. So lets please try to accomodate in this way, instead of fighting each other for no apparent reason. Dirk
Category:
Author: JT Smith
ACloakIt v1.1.0 Adds security to your Apache Web Server! The world wide web has become a “dog-eat-dog” arena allowing Cyber thieves to steal your Web Pages!
What makes ACloakIt unique?
ACloakIt displays your REAL meta tags and body content only to search engine spiders, but when your competition or anyone surfing your web site now views your source file, they will only see the body content you want them to see!
Top positioned web pages listed at Search Engines are the most powerful way to generate hits for your web page. These listings are very difficult to obtain and hold on to. Because many so called “Webmasters” are unable to get one of these top listings at the Search Engines, they have are stealing your web pages and editing them to their own theme. Then they submit their pages, but not with your URL and in many cases bump your top listing right out off the top 10 results!
ACloakIt is Shareware, but you can download a copy and test drive it before you decide to register it.
Author: JT Smith
When the evidence is brought together, the current state of KDE 3.0's development is easy to call a failure. Release Candidate 1 and current cvs are plagued with problems including: 1) Packages missing from the release entirely (1) 2) Rampant compile problems 3) Last-minute changes to build requirements that cannot be met by many developers without an operating system upgrade (2) 4) Many outstanding bugs (3) While these problems are bad enough, they in turn throw up further obstacles to a stable release: 1) When users and developers cannot build KDE, they cannot test KDE 2) When developers are locked out of KDE builds, they cannot contribute fixes. 3) When the credibility of the KDE release policies are called into question, users and developers are less likely to feel that testing is of value, and stop participating. The credibility of the release policies are further damaged by the manner in which the decisions are made. For instance, the major change to libtool, there was a minimum of discussion, with no compelling bugs or reasons shown for making this drastic change. In cases like this, the whims of a few dictate large change for the masses. The only remedy left for these KDE 3.0 ailments is to apply a "hard freeze" to the KDE 3.0 source, release a third beta, to begin allowing serious testing of KDE in real situations. For KDE 3.1, however, more can be done. Having identified the failures of KDE 3.0, we can trace the causes of these failures, and avoid causing them again. As was already stated, the difference between KDE 3.0 and recent releases has been changes in the "freeze" policies in the period leading up to the final release. >From the time of one week before KDE 2.2, until the final release, all changes to the source had to be reviewed on the KDE mailing lists (save, of course, trivial changes whose differences are included in the log message). (4) The justification for these changes was explained very well by the KDE 2.2 release coordinator Waldo Bastian in a mail to the developers (5), in which he said "[Y]ou will have to respect release freezes" if you put your code into KDE. In contrast, the time leading up to KDE 3.0 RC 1 is best described as a flood of un-reviewed changes to the sources. (6) The flood was met with excitement, to be sure, because the flood came from a rare opportunity for roughly 20 KDE developers to meet in person and develop. This opportunity was not to be passed up, but it could have been handled differently. If the developers in in the meeting felt that avoiding the mailing list was the best way to maximize use of the meeting, then they easily could have proposed a delay in the KDE 3.0 release, to allow for more time to stabilize after the meeting, to allow for testers to catch up with their time of great productivity. Some have suggested a failure in the community-recognized leadership of the KDE 3.0 release. While Dirk Mueller is respected throughout the community, his ability to step in and enforce the policies and release plans that everyone agreed to in the past has not been shown. Many in the community rely upon KDE, and as Bastian wrote, development of the KDE release carries responsibilities as much as it does privileges, and Mueller has not held the developers to these responsibilities. New leadership for KDE 3.1 is needed. The leader's role is to gather the views of the entire KDE development community, summarize them in the form of release plans, enforcing the plan when it is ignored, and updating the plan when it falls behind. The KDE releases are the legacy of the entire KDE community, and making sure those releases are good is the responsibility of every developer and tester. This requires that all developers, regardless of their social status, obey the written and unwritten rules of the KDE development community. A mistake by a well-known developer can break the release as badly as a patch from a novice, and the rules were agreed upon with this fact in mind. Only by keeping the written and unwritten agreements can all KDE developers and users continue to enjoy the success they enjoy now, and KDE 3.1 needs a release coordinator who well help the entire KDE community achieve that. Signed, Ryan Cumming Charles Samuels Neil Stevens
Category:
Author: JT Smith
Category:
Author: JT Smith
Category:
Author: JT Smith
Category:
