Fedora Insight testing

Paul W. Frields stickster at gmail.com
Tue Jun 8 12:40:29 UTC 2010


On Tue, Jun 08, 2010 at 12:42:34AM -0700, Robyn Bergeron wrote:
> 2010/6/7 Drak <drak at zikula.org>:
> > Possibly OT, but I saw a ticket relating to EZComments.  We released a new
> > version of EZComments 2.0.0.  Can you notify the maintainer please?  It
> > would be good if the maintainers can follow out extDB xml/rss feeds, or,
> > possibly we can assist the maintainers by autopackaging for Fedora with out
> > CI server (http://ci.zikula.org/).  All we need to do is add an XML build
> > file to each module project according to the maintainers wishes and it can
> > be all sorted out automatically.
> 
> For reference, the EZComments ticket in fedora:
> https://fedorahosted.org/fedora-infrastructure/ticket/2207
> 
> Getting us to EZComments 2.0 appears to be the following process
> (please excuse my non-coder descriptions, folks, and I may be wrong
> about some / all of this):
> * Upgrade to another version of php (I'm not clear on all the details
> here, but I'm pretty sure this is on the list.)

Nope, we don't need to do this after all, per Drak's earlier comments
on the list.  This was a mistake on the Zikula website.

> * Upgrade to zikula 1.2.3

Yes, via the new RPM that David Nalley has prepared.

There are some additional fixes that RPM needs, that Stephen Smoogen
discovered and was discussing with him.  I'm not sure those fixes are
in the 1.2.3 RPM that's currently available, but they can be added
later without affecting us greatly.

> * Upgrade / add in EZComments 2.0 module (this may be part of zikula
> 1.2.3, I don't know, and can't tell offhand)

It's not.  The RPM is a separate RPM, maintained by Mel Chua
apparently:

https://admin.fedoraproject.org/pkgdb/acls/name/zikula-module-EZComments

Mel Chua was the only person who has access to do that packaging.
I've just added myself to the list to get these changes moving, since
I assume that she didn't mean to silo that work.

There are a few modules that are part of Zikula itself, and the rest
are separate packages:

[pfrields at publictest6 ~]$ rpm -qa zikula-module\*
zikula-module-crpTag-0.1.3-3.el5
zikula-module-scribite-3.2-3.el5
zikula-module-fedora-fasauth-0.3-1.el5
zikula-module-News-2.4.1-3.el5
zikula-module-pagemaster-0.3.1-3.fc11
zikula-module-EZComments-0.1.61-1.el5.fedora.infra  <-- *we'll upgrade this
zikula-module-MultiHook-5.0-4.el5
zikula-module-filterutil-0-0.3.20090915svn15.el5
zikula-module-advanced_polls-1.5.1-1.el5

If you substitue those package names with the link I provided above,
you should be able to find out if we have any similar "SPoF"
situations with any of these modules.

> * Patch back any changes made over the weekend WRT AuthFAS stuff,
> etc.

Since the AuthFAS module is provided in a separate RPM, it won't be
affected by the upgrade.

> * Copy over our existing settings

No need, the Zikula DB already contains all the settings and should
upgrade cleanly.

> * Hope we don't have anything customized that is tied to existing
> version of zikula - if we do, then deal with that as well.

We can check using 'rpm -V zikula'.  I found that other than our
/etc/zikula/config.php file (expected differences), there's a change
that's been made directly on /usr/share/zikula/includes/ZLanguage.php.

I want to remind our Zikula friends that making these changes directly
on the system is *discouraged* since we use packaged software from
EPEL to deploy Zikula.  This may be a patch that was tested and simply
not removed.  If that kind of change is not documented, however, it
raises the risk of regressions when we upgrade.

Drak, can you check that this change is included in Zikula 1.2.3?

======================= ** diff follows ** ===========================
--- /tmp/zikula/usr/share/zikula/includes/ZLanguage.php 2010-02-28
04:44:59.000000000 +0000
+++ /usr/share/zikula/includes/ZLanguage.php    2010-04-19
03:35:46.000000000 +0000
@@ -277,8 +277,8 @@
     function searchOverrides($domain, $path)
     {
         $lang = ZLanguage::transformFS($this->languageCode);
-        $prefix = $_SERVER['DOCUMENT_ROOT'] . pnGetBaseURI();
-        $override =
"$prefix/config/locale/$lang/LC_MESSAGES/$domain.mo";
+        $prefix = realpath(realpath(dirname(__FILE__))
. DIRECTORY_SEPARATOR . '..');
+$override = "$prefix/config/locale/$lang/LC_MESSAGES/$domain.mo";
         return (is_readable($override) ? "$prefix/config/locale" :
	 "$prefix/$path");
     }
======================================================================

> * Test, test, test functionality.
> 
> I'm guessing that that process would take at least a week - probably
> more, particularly given that a number of us are going to be at an
> event this Wednesday - Sunday/Monday. Tuesday is our 6/15 deadline for
> having a functional version of Fedora Insight up and running.
> (Incidentally - I may be entirely overestimating the time for
> upgrading.  I don't know if it's possible to throw together something
> in the next day or two so that we can test this functionality in 1.2.3
> w/EZComments 2.0 on a publictest machine.)

We should be able to get this going today.

> I didn't see any ticket related to this phenomenon in the list of all
> tickets, open and closed, for EZComments.  I can file a ticket -
> albeit against EZComments 1.6.1. I'm wondering, however, if this is
> something that works properly in EZComments 2.0 - either "just works,"
> or was a bug that was never documented and is fixed, etc.  I've asked
> in the forums for some help / confirmation / verification that this
> isn't user error -
> http://community.zikula.org/module-Forum-viewtopic-topic-57991.htm -
> if it's not user error, I'll file something.
> 
> Not to jump the gun on any feedback I might get there - but I expect
> we're going to wind up in one of four situations:
> 
> 1: Someone gloriously tells Robyn that this is an easy configuration tweak.
> 2: We get confirmation that an upgrade will solve our problems; we
> upgrade over the next week, problem is fixed.
> 3: We upgrade over the next week and find out that this is still an
> issue.  We'll need to file a ticket against EZComments 2.0, and wait
> for a fix.
> 4: We get confirmation that an upgrade will not solve our problems,
> and we need a fix.  We'll then have to decide if / how long we want to
> wait, or if we want to modify our moderation requirements.
> 
> I would like to avoid Situation #3 altogether.  I'm not a fan of
> asking people to commit time, in an emergency fashion during a
> terribly busy week, to a solution that may not solve anything at all.
> IMO, we need to get answers that put us in Situations 1 or 2 (or even
> 4) by, I'd say, Wednesday (Paul, are we moving the FI meeting to back
> one day to Wednesday, as some of us are out Thursday?). If we do not
> have answers, I suggest we make some decisions on Wednesday.

I'll send that email today.  I think we should meet on Wednesday since
as Robyn notes some of us (herself, me) will be out or traveling on
Thursday to Southeast LinuxFest.

> Decision options include:
> * How long will upgrade realistically take - including testing, etc.?
> (This is more of a need an answer than decision, but..)
> * Assess whether we want to rethink moderation - we could temporarily
> not have moderation, and use spam filters, etc.  Or, moderate
> -everything-.  If we're willing to make accommodations here, we could
> upgrade and then hope it works, if not, plan M (modify moderation).
> Basically - is this a blocker?

We can always leave comments off for now.  I don't consider this a
blocker.

> * Moving out deadline to accompany possibility that we will need a
> fix, that upgrades will not be smooth, and give the lot of us on
> travel a few days of breathing room.

We have the same problem the week after this deadline -- several of us
are going to be gone for the Red Hat Summit in Boston.  We set up a
milestone so that we could accurately judge how much effort our team
was able to devote to Insight.  If we don't make this simple
milestone, I think we should use that information to inform our next
move.

> * Put FI on hold and go back to the drawing board.

We need to realize that some of the things we're dealing with right
now -- maintaining the platform and modules, testing functionality --
are going to be the same needs regardless of our choice of platform.

> In the meantime, I will be keeping my fingers crossed that this is a
> configuration error or something that can be confirmed as working in
> EZComments 2.0. :D  I'd also add that some experienced eyeballs
> looking at the existing configuration settings would be welcomed, to
> make sure I'm not insane (this has been known to happen... pretty much
> daily....)

It doesn't seem to be a config error, there have been substantial code
changes upstream that we need to package and test.  I'll put some more
time into this today.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
          Where open source multiplies: http://opensource.com


More information about the logistics mailing list