El vie, 01-09-2006 a las 10:33 +0200, Jörn Nettingsmeier escribió: > Thorsten Scherler wrote: > > El jue, 31-08-2006 a las 20:05 +0200, Joern Nettingsmeier escribió: > >> Thorsten Scherler wrote: > >>> Hi all, > >>> > >>> I will now merge back the ac branch into the trunk. This means all > >>> custom pubs need an update! > >> grmbl. > >> > >> as much as i appreciate your work, i think you could have asked first. > >> what's the problem of letting the users decide when to do a svn switch? > > > > Just for the protocol: > > Well, I asked to test more then a week ago. Not only once, I did it many > > times. > > my project happened to lie in tatters during that period, and i spent > all of my time fixing it. if the migration to uuids had been a little > less painful, i'd have been one of the first testers to grab your branch > and try it.
The problem lies in would and could, to get on with work we need will and have. I personally have to move on with other projects and gave people reasonable testing time. > > > Since I did not get a single reply to this threads I assume lazy > > consensus. > > that's why i hollered :) Which is perfectly alright. > > > I did all the work in the branch to not break trunk. The merge will > > *not* break the trunk AFAIK > ^^^^^ > > get real. this code will have bugs. every piece of code has bugs. and > access control code tends to have *subtle* bugs. but even if it hadn't, > you should still assume it does, that's best practice :) Sure every code can contain bugs, but me and josias did an extended test session yesterday, which helped to screen the biggest bugs. > > > just forces the user to update their ac > > config file. I gave clear instructions and examples how to update. > > > > You ask why, because branches should be merged quickly when stable! > > > >> for the first time since mid-june, i've been able to get my project in a > >> state where it will work well enough to allow basic debugging, and here > >> goes the next big source of instability. > > > > Thanks for calling it like this. It would be not such a "big source of > > instability" if more people would help to test like Josias did. > > i'm looking forward to test it, but as i said, my test setup has only > been fully usable for the last 24 hours after manually migrating most of > the content... hmm, I have at least 2 different lenya instance of the trunk on my computer. One where I develop and one clean checkout. This way I can test always the HEAD trunk against my modifications. > and please don't take the remark about instability as a personal insult. No, I did not. > it's a major rewrite, and of course it will have bugs. and at a time > where i try to understand and test the last big rewrite, i can't cope > with another. regression testing quickly becomes useless when the change > rate is too high. That is the problem of trunk. Many changes very quickly. > > unfortunately, you are now getting the heat that accumulated during the > uuid episode. that's tough luch :) > but the difference is that there was a consensus about uuid being a > necessary evil to tackle before 1.4. there was no such consensus for the > ac rewrite. That is not true, we discussed the AC rewrite a couple of times and it is a often requested feature. Since it is not closely comparable with such a big change as the UUID and needs just a small update of the config I do not see any problems why it should not go into the release. > > >> i'd have loved to try the stuff over the weekend *without* being forced > >> to... > > > > hmm, sorry but to be honest if you have a custom project you should use > > a revision where you know that it is working. Nobody forces you to use > > HEAD for your project. ... > > please. i want to see a re-written ac subsystem as much as you do. but i > have remarked time and again that this came a little out of the blue, it > was never on the list of critical milestones before 1.4 and should wait > until 1.4.1, with the option for the brave to switch manually. -1 There is no reason to wait for the merge rather then not to force the user to update their ac policies (which is a simple small task). The restricted ac is IMO a big improvement regarding access control on single documents and subtrees. > afaik, it does not address currently existing security problems (which > would be a point in favor of a merge), but it will potentially introduce > new ones (which is a point against). Like you say potentially, Josias and I agree that the code is good enough to merge, we tested it and can measure the potentiality of this issues. I still would like to merge the code today and advice all to note they current revision number. I would like to hear the opinion of others. salu2 -- Thorsten Scherler COO Spain Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
