mitchell_neill wrote:

This is working on an older wiki running MW 1.19 and SMW 1.7 with SQLStore2. So it looks like this is definitely a break.

Just checked (by hand, don't have time to write a test for this) with:

MediaWiki 1.19.7
Semantic MediaWiki (Version 1.9 alpha-3) (SQLStore3)

LocalSettings (before any extension specification):

define("NS_FOO", 160 );
define("NS_FOO_TALK", 161 );
$wgExtraNamespaces[NS_FOO] = "Foo";
$wgExtraNamespaces[NS_FOO_TALK] = "Foo_talk";
$wgNamespacesWithSubpages[NS_FOO] = true;

SEMANTIC MEDIAWIKI

...

$smwgNamespacesWithSemanticLinks = array(

NS_FOO   => true,

)

Adding a page Foo:WgExtraNamespaces with [[Has test on::WgExtraNamespaces]] will yield for [1] a WgExtraNamespaces#160# entry. 160 indicates NS_FOO and it also shows that SMW has successfully annotated the page WgExtraNamespaces (namespace NS_FOO) with a "Has_test_on" property.

[1] api.php?action=browsebysubject&subject=Foo:WgExtraNamespaces

<?xml version="1.0"?>
<api>

<query subject="WgExtraNamespaces#160#" serializer="SMW\Serializers\SemanticDataSerializer" version="0.1">
  <data>
    <property property="Has_test_on">
      <dataitem>
        <value type="9" item="WgExtraNamespaces#0#" />
      </dataitem>
    </property>
    <property property="_MDAT">
      <dataitem>
        <value type="6" item="1/2013/10/29/13/11/30" />
      </dataitem>
    </property>
    <property property="_SKEY">
      <dataitem>
        <value type="2" item="WgExtraNamespaces" />
      </dataitem>
    </property>
  </data>
</query>

</api>

mitchell_neill wrote:

Hi.

I've replicated your set up and the Has test on property is not set :(

I notice you are running an alpha version of SMW 1.9.3. I'm running the stable release version - 1.8.0.5.

Another example is [1] where the "Demo" custom namespace is used therefore functionality is provided with the current SMW master (1.9).

For further help, see [2].

Until a specific example is provided where the custom namespace functionality does not yield expected behaviour, this bug is being set to be invalid.

Feel free to reopen this bug with an appropriate unit test or a repeatable test description against SMW master (1.8.x is no longer under active development).

[1] http://semantic-mediawiki.org/wiki/Demo:Berlin

[2] http://semantic-mediawiki.org/wiki/Help:Troubleshooting#Missing_data_on_custom_namespaces

mitchell_neill wrote:

Hang on, you can't just close this! Two people have reported this regression on the current stable release version of SMW.

SMW 1.9 is not released. A lot of people are using 1.8.0.5 and will be going forward. So are you saying all support for the current release version of SMW has now been dropped?

Neill: Comment 4 asked to provide a reproducible testcase that can be triggered against SMW master. It is up to developers to decide which versions they still support, and as written, 1.8.x is no longer under active development.

Closing as WONTFIX for 1.8.x for the time being (feels slightly more appropriate than INVALID) until it has been shown that the problem still happens in more recent versions.

To add to this: I cannot confirm this problem. Just two weeks ago I set up a custom namespace including semantic capability with and the same setup (SMW 1.8.0.5, MW 1.20.8, PHP 5.3.3, MySQL 5.1.66 on Store3 and I am able to set properties galore.

Are you sure you defined the custom namespace *before* the inclusion of Semantic MediaWiki and set the namespace with semantic links parameter e.g.

$smwgNamespacesWithSemanticLinks[NS_PRIVATE] = true;

*after* the inclusion of Semantic MediaWiki. Make also sure that you do not set an array for this, since this indeed does not work. This parameter must be set individually for every namespace (regular as well as talk) in LocalSettings.php.

After an upgrade to MW 1.21.3 everything is still running smooth.

(In reply to comment #5)

SMW 1.9 is not released. A lot of people are using 1.8.0.5 and will be going
forward. So are you saying all support for the current release version of SMW
has now been dropped?

I have stated that "1.8.x is no longer under active development" which means that any issues reported are only verified against the current SMW master implying that functionality and fixes are provided for SMW master only.

In general only security fixes are back-ported but any developer is free to provide fixes and back-ports for any release but the developer should make sure that fixes are compatible with the current master as it runs a "battery" of unit tests [1] which do not exists in releases before SMW 1.9.

[1] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki

mitchell_neill wrote:

Perhaps I'm getting a bit old school, but I feel there is some fundamental principal of software engineering being missed here.

The issue was raised against the current stable release version of SMW as detailed here: http://semantic-mediawiki.org/wiki/Help:Download

This is not "active development", it is bug fixing. People cannot always run the latest and greatest versions of everything on their servers, especially when there are a number of interdependencies involved. The stable release version is going to be around for a while yet and should never get left hanging out to dry. Reported issues should not just be closed out of hand.

If the issue is not present with the SMW master that's great, but the bug was not raised against SMW master so providing a test case is not relevant to the report.

I think some clarity is required here. Are you suggesting that people have to constantly update their instances to SMW master in order to receive bug fixes going forward?

What is going to happen when SMW 1.9 is released and you start working on 1.10? Are you then not going to do any bug fixing on the newly released 1.9?
Will be users have to use the 1.10 branch to receive fixes for any issues that arise with 1.9?
If this is a new policy going forward, then I think people need to be made aware of this right now before committing themselves to a path that may not be suitable for them. I suggest further discussion should be made on the mailing list and a support policy published.

I'm curious as to who the developers being referred to are? I thought SMW was a community project? So in this spirit, I am re-opening this issue in case there is someone running the current stable release version with the time and interest to investigate and fix if required. If the bug is closed, it will not be seen by someone who might like to contribute. If the issue is not solved, or becomes irrelevant going forward we can review.

I'm not trying to be difficult here. I just really don't want to see SMW adopting the constant beta model practised by the likes of Google et al. Quality inevitably suffers and people get fed up and lose interest. Perhaps I've misunderstood and this is not the path that has been chosen.

kgh - Thanks for your suggestions, but my set up looks correct. The issue started after upgrading to from 1.8alpha to 1.8.0.5. Perhaps it is an upgrade issue.

(In reply to comment #9)

This is not "active development", it is bug fixing. People cannot always run
the latest and greatest versions of everything on their servers, especially
when there are a number of interdependencies involved. The stable release
version is going to be around for a while yet and should never get left
hanging
out to dry. Reported issues should not just be closed out of hand.

This was not the case no examples were provided that would allow to verify the claim made, on contrary examples were cited that showed a working functionality leaving the bug to be closed based on the given evidence rather than a "out of hand" manner.

If the issue is not present with the SMW master that's great, but the bug was
not raised against SMW master so providing a test case is not relevant to the
report.

If no test case is provided and the reported error can't be verified with the current master, how would you decide and test that a problem is fixed or not. A unit test exists to verify an assumption about an expected behaviour.

I think some clarity is required here. Are you suggesting that people have to
constantly update their instances to SMW master in order to receive bug fixes
going forward?

I'm not suggesting anything, I stated that "any developer is free to
provide fixes and back-ports for any release" which means you are free to install which ever version works best but software patches (if provided) should be "compatible with the current master".

What is going to happen when SMW 1.9 is released and you start working on
1.10?
Are you then not going to do any bug fixing on the newly released 1.9?

If you ask me personally, once 1.9 is released I will focus on other tasks that are not related to 1.9 (but this is just me).

Will be users have to use the 1.10 branch to receive fixes for any issues
that
arise with 1.9?

Again, "any developer is free to provide fixes and back-ports" which means that if a developer sees the need for a back-port he/she is free to do so.

If this is a new policy going forward, then I think people need to be made
aware of this right now before committing themselves to a path that may not
be
suitable for them. I suggest further discussion should be made on the mailing
list and a support policy published.

Please feel free to do so, it is a community project and I hope that people will commit themselves to a broader support infrastructure and more developers take up the opportunity to be involved but please don't expect core-developers to restrict themselves to invest their volunteer time on issues they might not seem relevant to them.

See also [1].

I'm curious as to who the developers being referred to are? I thought SMW

My previous statement "any developer is free to provide fixes and back-ports" includes all developers who want to provide software improvements (back-ports, fixes, new developments etc.).

It is a volunteer and community project therefore anyone is encouraged to extend and improve the software.

Having said this, probably most core-developers will focus on evolving the current master aiming towards objectives stated within the roadmap [1].

was a
community project? So in this spirit, I am re-opening this issue in case
there
is someone running the current stable release version with the time and
interest to investigate and fix if required. If the bug is closed, it will
not
be seen by someone who might like to contribute. If the issue is not solved,
or
becomes irrelevant going forward we can review.

Maybe the bug title should reflect that is an issue with 1.8.x (but apparently it is not citing the example of kgh).

I'm not trying to be difficult here. I just really don't want to see SMW
adopting the constant beta model practised by the likes of Google et al.
Quality inevitably suffers and people get fed up and lose interest. Perhaps

This is why I ask for "an appropriate unit test or a repeatable test description" so that it can be verified, fixed, and tested to improve overall quality and stability.

I've misunderstood and this is not the path that has been chosen.

SMW is a volunteer project, expecting a support infrastructure like that of a commercial product is more suited and left to specialised service providers [2] (this is not a hidden advertisement as I'm not involved in any professional support).

[1] http://www.mediawiki.org/wiki/Backporting_fixes

[2] http://semantic-mediawiki.org/wiki/Roadmap

[3] http://semantic-mediawiki.org/wiki/Professional_support

PS: I will further excuse myself from this bug in order to focus on more pressing issues.

alj62888 wrote:

I too had this very same problem after an upgrade to SemanticBundle 1.8.0.5.

But, I was able to finally get it to work with kgh's suggestions, specifically:

"...set the namespace with semantic links parameter e.g.

$smwgNamespacesWithSemanticLinks[NS_PRIVATE] = true;

*after* the inclusion of Semantic MediaWiki. Make also sure that you do not set
an array for this, since this indeed does not work. This parameter must be set
individually for every namespace (regular as well as talk) in
LocalSettings.php."

On a side note: I completely agree with Neill's comment #9... but his expectations are not "old school" at all, but proper and axiomatic.