On Tue, November 30, 2010 11:37 am, John Layt wrote: > On Tuesday 30 November 2010 10:18:39 Kevin Ottens wrote: >> Sorry if the wording turned out unfortunate it wasn't my intent there. >> It >> was more about a reality check: >> a) I can't devote much time to it on a regular basis (it's rather low >> on >> my priority list), and I think I'm not the only one with that problem >> since I hear this "let's move KDateEdit to kdelibs since *at least* >> 4.3"; >> b) Until it's in kdelibs people will keep doing stuff in their own >> corner, >> so the work I did so far will need to be done again for missing features >> and so on, David's mail actually illustrate that well... The feature he >> refers to wasn't there when I started. :-/ >> >> But OK, looks like I missed the window by a couple of weeks, so let's >> make >> it for a "later release". >> >> Regards. > > OK, so if it can't be in 4.6, how's this for a plan: > * Merge Kevin's changes into the kdepim version so they are not lost and > kdepim gets the benefit in the interim. > * I bug fix the merged version in kdepim to fix the localization problems > * Advertise loudly to all the projects with forks of KDateEdit that they > may want to update their copy from kdepim. > * When trunk reopens, we move to kdelibs and I'll start hacking on it
This sounds reasonable, provided no existing features in the kdepim version are lost. (I'm thinking of the maximum/minimum date facility which isn't in Kevin's version.) Doing things this way will mean that we won't be stuck with API deficiencies due to too little time in the wild to try it out and tweak it. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
