Upgrade to 0.44.1 broke our site

[Caio Tiago Oliveira]

On 07/25/2013 08:16 PM, Ewout ter Haar wrote:
> 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.
Anything you add to your sources.list other than the default stable
distribution is actually a backport.
Even Debian recommends a lot of them if you want to use the stable
distribution on a end user desktop, you just need to check the
installation guide.

For a rock solid package you would use a Noosfero package as old as the
Debian distribution, with security fixes [more at the end].

> 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.

For a package to be considered rock solid it ought to be tested by a lot
of different people in different environments, for a long period of time.
You can't consider any newly released package, with new features added,
to be bug free.

> 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?

I would say that perfect solutions doesn't exist. Although bug fixes
versions tend to get better with the minor number increase, there is no
guarantee that a X.1 is bug free.
Also, it is possible that ten different people say something is OK and
you would still have a major bug on your environment.
I am not saying this bug was hard to find, the flaw in the process
should be fixed, but one should not blame the main devs on open source
projects with open communities.
Even though Colivre does most of the development, the process is open,
on gitorious and everyone is welcome to help to develop and test.
One testing package or any other way of doing quality assurance checks
would be terrific. Sadly, currently we have none.

On the former OpenOffice.org, any change had to be tested by the
developer and by a QA member (which would run a huge set of tests on the
whole module for the change) before being integrated in the master.
Then, it would be sitting for at least two weeks, before being released
in a developer snapshot. For a version release, there was a code freeze
of more than two months, with no new feature added neither big changes
introduced. Before the fisrt public early release one even bigger set of
tests was run (more than 10 hours of testing) was done for each of the
tier 1 languages. Before each public early release, the same set of
tests mentioned earlier was run, with focus on the most important features.
Yet, lots of bugs were discovered on the release candidate phase,
including major ones. What next? Some major bugs were found after a
stable release.

Although Noosfero is orders of magnitude smaller than OOo, the community
around it and the number of users are also much smaller.
I would say that test instances (e.g.: clones of the virtual machines)
are the cheaper and most effective way of blind one system. Also,
automated tests for the major features of the system are of great help.
If there is no code change or plugin added, at least the user
interface/interaction should be tested.