Rename plone.act to plone.rf, plone.robot or robotframework-plone

[datakurre]

Hi,

recalling the discussions at Plone testing / CI sprint at Barcelona, I think that the main reason for not releasing plone.act, after all, was the name.

At Arnhem, we thought that the name doesn't matter, but at Barcelona, @tisto was quite strongly against it, because it's misleading: not all robot tests are acceptance tests and not all acceptance tests are robot tests. Also, it was argued that the necessary features of plone.act should be merged in plone.app.testing (or plone.testing).

I'd still like to release the stuff in plone.act (variable conventions, remote keywords library and robot test server [act_server], saucelabs-support, and maybe also its user keyword library), but I'm not yet comfortable for adding them into plone.app.testing (and its not correct place for all the stuff in plone.act).

Therefore I'd like to rename the package before releasing (at first within this old repo and maybe later rename also the repo; also, there could be zope.deprecation-definition for plone.act).

Which name would you prefer?

plone.robot plone.rf robotframework-plone

Cheers, Asko

[tisto]

plone.robot

If the code is Plone specific it should be plone.app.robot, right?

plone.rf -1

Same problem as with plone.act, people don't get what it does by just looking at the name.

robotframework-plone +0

Name is ok, we usually use some kind of namespace if the code is Plone specific.

Maybe the name should be even a bit more specific, "robot" is still pretty generic and could mean something else. What about plone.app.robotframework?

In the end I'd say the decision is up to you, since you are writing the package.

[datakurre]

Thanks. There are both Plone specific and only zope.testrunner-specific code, but it would be easier to start with only one package (not both plone.robot and plone.app.robot).

Also "robotframework" would be better than just "robot" avoid accidental conflicts with Robot Frameworks main "robot" module.

My only issue with plone.app.robotframework is that it's a long name.

[tisto]

If I understand the naming conventions of the plone community correctly plone.robotframework would be a package created by the Plone community that does not depend on Plone itself. plone.app.robotframework would be a package created by the Plone community that does depend on Plone itself.

If we would create a plone.app.robotframework package there is no need to create a second plone.robotframework package. Most plone.app.* packages do not have a corresponding plone.* package.

[emanlove]

Asko Soukka wrote:

... Therefore I'd like to rename the package before releasing (at first within this old repo and maybe later rename also the repo; also, there could be zope.deprecation-definition for plone.act).

Which name would you prefer?

plone.robot plone.rf robotframework-plone

I prefer plone.robot over the other two. plone.rf is confusing in that you have to know what rf means in order to know what it does and I really prefer to tell people what this does at a quickglance [1]. I think this package should be within the plone namespace so I would not use robotframework-plone.

But would something like plone.robotframework or plone.robot.testing be even better than plone.robot?

Ed

[1] I once worked for TMW and there we, at TMW, had discussions about the internal verse external use of abbreviations for our products and our company name, TMW of course. We, TMW, came to realize that by using abbreviations, like TMW, we were preventing our customers and partners from immediatly recognizing us. So we made a real effort to drop the use of abbreviations. So I would prefer not to use RF and in my writing/work/communication about robotframework and selenium2library. I specifically type out those names over and over again so as not to lose people with RF and Sel2Lib or S2L. By the way, TMW stands for The MathWorks.

[datakurre]

https://saucelabs.com/u/parobotframework

[saily]

+1 for plone.app.robotframework

[datakurre]

I'm releasing p.a.robotframework during the next week. Should I merge the branch into master of plone.act or just release and clone it into a new repository without ever merging it into plone.act master? So, should I keep plone.act master in sync with p.a.robotframework for a while or just abandon it?

[saily]

+1 for adding something similar to MOVED_TO_NEW_REPOS.txt to current repos (as we do on svn.plone.org) and add a new one named plone.app.robotframework. Since we've never had a release yet, people should not be using plone.act in production environments and therefore +1 for abandon it.

[emanlove]

Asko Soukka wrote:

I'm releasing p.a.robotframework during the next week. Should I merge the branch into master of plone.act or just release and clone it into a new repository without ever merging it into plone.act master? So, should I keep plone.act master in sync with p.a.robotframework for a while or just abandon it?

Looking at the small number of forks off plone.act and tight circle of developers I think abandoning plone.act in the future is fine. Assuming the changes in the branch are applicable to both plone.act and p.a.robotframework (i.e. they don't change setup.py to say this is p.a.robotframework) I would merge in the branch one more time and then delete all leaving a README.rst pointing towards p.a.robotframework. That is as long as we don't lose history; which shouldn't happen but is always my fear when deleting.

Ed

[datakurre]

Thanks for the comments. setup.py has already been changed so I'll won't merge anymore. (Yet, my branch includes plone.act shortcut for plone.app.robotframework, but I may have done other incompatible changes already.)

@tisto, could you create a p.a.robotframework repo for me and give me ownership permissions for it?

The CMFPlone-tests written in Barcelona are now passing for Firefox, Chrome and IE at SauceLabs: https://saucelabs.com/u/parobotframework

Next, I'll start refactoring them for the common keywords to be included in p.a.robotframework. (I copied them into p.a.robotframework for that purpose.)

@emanlove There was one weird issue in CMFPlone tests and I'd like to have your opinion and thoughts on this:

The test in question publishes a document using dropdown workflow menu. The menu opens correctly, but "Click Link" for "Publish" won't work on Internet Explorer. Yet, combination "Mouse Over" + "Mouse Down" + "Mouse Up" works (but that won't work for Firefox).

Any thoughts? Both scenarios are now included in the test (and that combination usually passes for all three major browsers):

https://github.com/plone/plone.act/blob/datakurre-p.a.robotframework/src/plone/app/robotframework/tests/cmfplone/test_actions_menu.robot#L124

At Sauce Labs, use "Do a workflow change" as filter to view the test in question.

https://saucelabs.com/u/parobotframework

[tisto]

@datakurre

Done: https://github.com/plone/plone.app.robotframework

Let me know if you need anything else.

Regarding p.act: I'd leave it as it is just in case people still rely on it. Personally I'd be ok with an initial import into p.a.robotframework without the plone.act history.

[datakurre]

Cloned into p.a.robotframework.