On Friday 11 November 2011, Aaron J. Seigo wrote: > hi Kevin, > > first, let's back off from the unecessary rhetoric. for instance, i don't > think calling people hypocrites is going to get anyone anywhere other than > annoyed, upset and divided. i hope we can agree on that. > > On Friday, November 11, 2011 04:58:09 Kevin Kofler wrote: > > You cannot really FORCE volunteers to work on what you want them to work > > on. > > no, but we can decide to work together and coordinate instead of working > against each other, particularly when we share the same final interests. > note that your statement is the same as saying that as a volunteer i can > then commit anything i want to your application / library, which is, > obviously, not true. there are means of process control, particularly > maintainership. > > note that the decisions which i am simply repeating and asking people to > respect were made this past summer in a meeting of some 30 libs > contributors and then brought here to k-c-d for further discussion. to > ignore would be disrespectful of the time honoured principles in KDE.
I'd prefer if there wouldn't be a separate mailing list for the frameworks effort, but if it would use k-c-d instead. IMO this _is_ kde core development. This would make it more public (yes, it is completely public, but still a bit hidden if you didn't subscribe the frameworks list). ... > this is the same argument people used for 3.4 and 3.5. it marred the early > 4.x releases (along with a few other related issues). we can avoid > repeating those mistakes by learning from them. now, 5 is not 4, and this > also makes a difference as to why we should shift more focus to > frameworks. why? well: > > * Qt5 is not Qt4: it isn't a huge burdon to port things over. the code and > API is essentially the same. > > * we aren't going for "add lots of huge new functionality blocks" (e.g. > solid, phonon, threadweaver, sonnet, etc. etc. etc.); this is a > maintenance reorganization, an opportunity to merge functionality into Qt5 ... and into CMake, which is making good progress btw. :-) > (which has a definite time deadline, btw, which we need to meet or else we > lose that opportunity entirely) and a chance to alter some behaviour in > our code that is most appropriate for a major release (though some things > of this nature could be done post 5.0 as well) ...also for our buildsystem :-) Alex