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.
Since I did not get a single reply to this threads I assume lazy
consensus.
that's why i hollered :)
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 :)
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...
and please don't take the remark about instability as a personal insult.
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.
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.
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.
well, you are right. the thing is that a lenya developer told me in
autumn 2005 that lenya would be ready by christmas (2005), and i've been
chasing head ever since, too timid to cut my losses ;-D
*but*, imnsho, part of the mess that the trunk is currently in comes
from the fact that people use mostly trivial test cases:
we have no routine tests for templated publications (my project uses
templating heavily, and i've been filing reports and fixing stuff that
nobody else seems to have noticed).
we have no tests for non-root servlet deployment (i tried it and ran
into problems, there are still a few minor bugs where root is assumed).
we have no tests for i18n (default pub uses it but you can't even switch
languages, so nobody will notice problems).
there are still many places where SoC is violated in modules (most
notably xhtml). you only realize that when you try to get serious work
done with HEAD, not when you click through some default pub documents
and assume all is well.
botom line is this: we need serious testers for trunk. that means trunk
must be in a testable state. that has been rare lately, and even more so
when you take into account the problems with migrating custom publications.
what we don't need is people snickering "i told you so" when testers
fall on their face while trying to keep in sync with HEAD. running
projects on HEAD provides valuable feedback and timely information about
regressions that the default publication cannot provide.
*.*
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.
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).
best,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
