On 05/17/2011 12:48 PM, Stephen Kelly wrote: > Sebastian Trüg wrote: > >> First off: I think the system does work. IMHO I am not the only one only >> thinking about these dates shortly before they arrive. Thus, the hard >> freeze is there to have time to fix issues like these. But that is just >> my personal opinion. > > Yes, the freeze is there to resolve these issues, as I wrote too, but if > such a big break appears on the day of freeze (a week before beta tagging) > after hibernating in a branch for 5 months, then *something* is broken. > That's just my opinion. > > I don't think having a 'Major feature freeze' and a 'Minor feature freeze' > is a sensible thing to do, but KDE developers should keep in mind that they > should introduce breakage or potential breakage months before freeze. So > there's probably no structural or scheduling solution, but only a community > one. > >> As for SDO: the cardinality change was long due. I agree that it should >> have been done sooner. But well, the harm is done. Reverting it is not >> possible > > How could reverting it not be possible? It seems perfectly possible to me. > It's just a revert in kdelibs and kdepim-runtime. > >> , the cardinalities are required. Introducing some hack in SDO >> is not a good idea IMOH since it would only be there for the one tool, >> namely nepomuk-rcgen. Thus, if anything was to be hacked, it would be >> that. > > Right. 3 of the solutions I proposed (the ones I prefer) are to hack rcgen. > > Are none of the solutions I proposed acceptable? > >> As far as dependencies go: KDE-PIM 4.7 does NOT depend on kdelibs 4.7 >> now since kdelibs <4.7 builds fine with SDO 0.7. Thus, it is perfectly >> possible to have SDO 0.7, kdelibs 4.6.x, and kdepim 4.7 on one system. > > Ok. > >> >> KDE-PIM < 4.7 is another problem as it does not build against kdelibs >> 4.7. But then again: who does that? > > Packagers apparently. They've raised the issue on the mailing list and on > IRC. Either KDE makes guarantees or KDE does not make guarantees. > >> I know that is not a great argument, >> but really, why would you update kdelibs and kde-runtime and friends but >> not kde-pim, now that we finally have a kde-pim release with the rest of >> kde again? > > A release alone doesn't make it usable for everyone. While most are happy > with it, some are not. See this comment on my blog: > http://steveire.wordpress.com/2011/05/15/kde-pim-4-6-rc1/#comment-2206. > > The comment is too vague to take any action, but it shows that people do > still have issues on the new stack. > > The fact is that the new platform does not work for everyone and does have > bugs and regressions, and people will want to use old versions of kdepim > with new kdelibs. > > The release is a development milestone less than a bugfix milestone. > > Apparently I was not correct about kdepim4.4 working with kdelibs4.7, so > that is relevant. > >> If someone wanted to do that there are two ways to make that happen: >> 1. Create another release of kde-pim <4.7 which introduces the mentioned >> #ifdefs. >> 2. Patch nepomuk-rcgen to always generate both set and add methods. >> > > Ok, this looks like the list I created, but with different numbers, which > can only add to confusion. Your (1) is my (5). Your (2) is my (3) or (4), > depending on what you have in mind. > > As I said, I'd be fine with my (2), (3) or (4). You say my (2) is not a good > idea because it is only relevant to rcgen. That leaves my (3) and (4). What > solution do you propose? When can we expect a fix to be written, reviewed > and tested? Keep in mind that beta 1 tagging is supposed to happen on > Thursday.
Like I already said: patching rcgen seems like the best solution to me and that is so trivial I can have finished it today. Cheers, Sebastian
