Upgrade to 0.44.1 broke our site

[Ewout ter Haar]

I think the root cause of my disappointed and probably too exalted
tone is a mismatch of expectations. I expected the packaged debian
version of noosfero (on the next to last stable debian platform, which
people use for its reputation to be rock-solid), to be rock-solid. I
expected to be able to do apt-get upgrade at any time. But now I
understand  that is not how Colivre sees it.

My original idea for our test instance was to be an development
instance, hooked up to the "tip" of noosfero git repo, making
contributions, etc. I didn't think it was necessary to have a test
instance (see above, debian-stable, rock-solid). That is not how it
worked out. We were not able to contribute code, and as it turned out,
and we did need a quality assurance instance, so that is what we have
now.

So fine, I will re-align my expectations. I won´t upgrade until
someone says it is ok. Still, I think is surprising that the noosfero
package on debian-stable is not stable. I understand it would cost
more in human resources, but shouldn't we have  a noosfero package in
testing, and one in stable?

More inline


On Thu, Jul 25, 2013 at 7:17 PM, Antonio Terceiro
<terceiro at colivre.coop.br> wrote:
> On Thu, Jul 25, 2013 at 03:28:20PM -0300, Ewout ter Haar wrote:
>> On Thu, Jul 25, 2013 at 3:10 PM, Bráulio Bhavamitra <braulio at eita.org.br> wrote:
>>
>> > The magic was actually due to a bug in the code I submitted. I haven't
>> > checked for nil or preloaded with a default value. In cirandas this value is
>> > not nil, that's why the problem doesnt happen there.
>>
>> My question remains: why did the quality control tests not catch it
>> before the release went out?
>
> Because no QA in the world is able to catch all problems all the time.
> Because no two systems are the same. Stuff that works here will break
> elsewhere.
>
> Isn't the whole point of you having a test system to be able to catch
> eventual problems that we didn't catch before such problems reach your
> production system? Guess what, it works! :-)
>

See above. I expected the packaged version of noosfero to be
rock-solid. Now I understand it not, and should not expect it to be.

> If you were to assume that the upstream Noosfero QA process is 100%
> effective, you would not have a test system. It's good that you know
> better than that.

I only converted our development instance to a test instance after the
rails security update / noosfero incompatibility episode.

>
>> > About the escaped html, I still don't get the problem. It seems that the
>> > debian rails has a different behaviour than the official rails (2.3.15), the
>> > one used in cirandas.
>>
>> I think Terceiro has some explaining to do. As I understand it, his
>> argument for using the debian rails and debian package management
>> system is so that administrators can use their debian managements
>> skills to mantain their sites. Well, it seems that reality is
>> different: twice now an apt-get upgrade broke my site: first when the
>> debian rails became incompatible with the debian noosfero (a few
>> months ago) and now because the debian noosfero (stable!) just broke
>> for some reason.
> 3) escaped HTML in a blog. Did it work OK before? Is it a regression?
> There was some work on performance issues that touched the blog, that
> might have caused a regression.
>
> Now this has something to do with the Rails version. As we already found
> out, there are some differences in the behavior of Debian Rails
> 2.3.5+security patches and the Upstream Rails 2.3.15, specially with
> regard to handling the potentially unsafe HTML. We have been working
> hard to fix all the problems caused by this, while also trying to
> advance to Rails 3. I still believe using APT for managing dependencies
> is a good thing, but well, nothing comes with no disadvantages.
>

Here we agree. Maybe when finally we can migrate to debian-stable (the
current one) we can have two noosfero development tracks: one for
established sites, rock-solid, and one for smaller sites, with newer
functionality.


> I just pushed a fix for the escaped HTML problem. It will be released
> with 0.44.2.

But I still need to disable the two plugins, right?

>> Am I missing something?
>
> You are missing to realize that problems might happen, and when they do
> happen, pointing fingers in what is in my opinion a disrespectful way
> ("WTF, Colivre?", "Terceiro has some explaining to do") does not help
> to solve the problem.

Yeah, the first one is just internet slang, and the second one was a
reference to the earlier debian/apt vs bundle discussion. Anyway, I'm
sorry to have sound angry. But I must admit to be irritated, first
because of my expectations not being met and second because Colivre
did not speak up. But sure, I understand that the first is a problem
with my expectations, and the second is probably due to time
pressures.

>
> If there are problems, let's work together on fixes, and discuss how we
> can avoid the same type of problem happening in the future. For example
> I think we must put a policy to not allow any plugins without at least
> one functional or acceptance test.

My suggestion is to have fewer releases in debian-stable, and give
sites who need the latest and greatest another deploy option.

But before that suggestion is implemented, we need to be on
debian-stable and rails3, I guess. We are on 0,41 now and still have a
lot of escaped HTML problems.

Ewout
>
> --
> Antonio Terceiro <terceiro at colivre.coop.br>
> Colivre - Cooperativa de Tecnologias Livres
> http://www.colivre.coop.br/
>
>
>
> _______________________________________________
> Noosfero-dev mailing list
> Noosfero-dev at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-dev
>



-- 
http://social.stoa.usp.br/ewout
F. 30916696