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. Cheers, Steve.
