Hi,
We should reintroduce the Resolved state in the issue workflow, and it
should work like this:
- When closing an issue, it will go in the Resolved state, which means
that somebody provided a fix and it is committed in the repository.
- Somebody else can test (manually) that the issue is indeed
fixed/implemented, and it works as expected. If no, then it goes back
to Open, otherwise it goes to Verified.
- When all the needed tests and documentation are written, the issue
can be closed completely, entering the Closed state.
This should improve the way we write code, meaning that we don't just
commit some quick fix code which nobody sees, and claim that the issue
is fixed. Right now we're trying to do peer reviewing either by first
attaching patches to the issue and have somebody review it, or by
hoping that someone is reading the commit mails and notices if
something is wrong. We should never make a release that has issues in
the Resolved state, as it has unverified code, probably with missing
documentation and proper tests. We should reserve a few days before
each release for moving any Resolved issue to the Closed state, by
verifying, testing and documenting it.
Verifying issues can be done by outsiders, too, so we could involve
the community more. Perhaps it would be a good idea to require two
verifiers before moving the issue to verified, as testing on different
systems can spot some bugs, like the full screen editor not working in
Safari issue.
Sergiu
--
http://purl.org/net/sergiu
The XWiki Watch development team is pleased to announce the release of
XWiki Watch 1.0 Milestone 2.
You can grab it here :
http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiWatch
Reminder : XWiki Watch is a collaborative RSS/Atom feed reader that allows
teams to read, tag, comment and flag articles in a AJAX/GWT interface
integrated inside the wiki. Features include also filtering, text
analysis, press reviews generation, English and French user interfaces,
and more! Note that Watch is delivered as a full Watch+Wiki or as a XAR
package installable in a standard XWiki 1.1 or 1.2
This release include both bug fixes and new features, among which you can
find :
- A Wiki integration : now every data collected/created (feeds, fetched
feed articles, tags, keywords and groups) through the AJAX/GWT UI is
accessible via classical XWiki pages
- UI improvements/bugfixes : Editing and deleting feeds is easier,
filtering both keywords + groups has been fixed, the feed tree does not
collapse unexpectedly anymore
- A m2 build matching the XWiki development process : now developers can
build XWiki Watch with a single line command
- Other bug fixes and improvements
You can read the full release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWatch10M2
And the installation guide :
http://www.xwiki.org/xwiki/bin/view/Code/Watch
Have fun!
The XWiki Watch development team
Here's the result:
* 3 +1 (+1 non binding vote from Anca)
* 0 0
* 0 -1
I will make it on trunk after 1.2 branch and 1.2 first RC release
(planned for this Friday). So this will be the first new 1.3 feature
:)
2007/11/22, Thomas Mortagne <thomas.mortagne(a)xwiki.com>:
> Hi all,
>
> Having xwiki document with no extension in the files names is a real
> mess for subversion and IDEs like Eclipse and IntelliJ IDEA and it
> will also be very useful in any editor that takes extension to
> determine the content or simply for most OS Explorers/Finders.
>
> As the XWiki maven xar plugin now support files with any name when
> creating the xar package (see
> http://jira.xwiki.org/jira/browse/XTOOLS-19) I propose to add .xml
> extension to exported document files names.
>
> Import document with any names is already supported by xwiki core
> importer plugin since at least svn1387 (October 2006) and I think
> since it's creation so it seems it will not break older version
> import.
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
On Dec 3, 2007, at 4:26 PM, hritcu (SVN) wrote:
> Author: hritcu
> Date: 2007-12-03 16:26:54 +0100 (Mon, 03 Dec 2007)
> New Revision: 6263
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> xmlrpc/ConfluenceRpcHandler.java
> Log:
> Testing that I can commit (updated comment)
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/xmlrpc/ConfluenceRpcHandler.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> xmlrpc/ConfluenceRpcHandler.java 2007-12-03 14:59:03 UTC (rev 6262)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> xmlrpc/ConfluenceRpcHandler.java 2007-12-03 15:26:54 UTC (rev 6263)
> @@ -83,6 +83,7 @@
> // -- user management could be a part of the test setup
>
> // Q: Where are access rights checked ? Ensure they are !
> + // Vincent discovered that they are not checked ... was it fixed?
Not across the board, just in getDocFromPageId().
-Vincent
Hi,
Marius has asked me for commit access to the sandbox since he's
working with Jerome and Ludovic on the new space manager feature.
Since Marius has been providing good patches and this is only an
access to the Sandbox, I'll go ahead and give him access.
Note that this does not allow Marius to commit elsewhere yet (a vote
will be needed for that). However since we only have coarse-grained
permissions at this stage Marius would be able to commit elsewhere but
he shouldn't do that (I talked to him and he knows that).
Thanks
-Vincent
The XWiki development team is pleased to announce the release of
XEclipse 1.0.1
You can find it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiEclipse
XEclipse is an Eclipse plug-in that allows the user to interact with
an XWiki server directly from within the Eclipse IDE. It comes in two
flavors: as an Eclipse plugin that can be directly integrated in the
Eclipse IDE or as a standalone RCP application.
This release is mostly a maintenance release that fixes some serious
bugs that prevented XEclipse version 1.0 to work correctly.
Main changes from 1.0:
* Solved XMLRPC issues when connecting to XWiki version 1.2
* Solved problems in XWiki Explorer structure visualization.
* Added some minor user interface improvements (e.g., page loading
progress bars).
Thanks
-The XWiki dev team
Hi,
As previously proposed, today (Friday 30th) is the planned day for the
first 1.2 Release Candidate. There are still a few issues remaining
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010…
which I'd like to see fixed before noon (CET), when I'll start the
release process.
There will probably be another RC shortly, as there are a few more tasks
that should be fixed for improving the stability of the 1.2 version of
XE, but there should be a final 1.2 before Javapolis.
Thanks,
Sergiu and my +1
Hi,
I'd like to move the current trunk (1.2-SNAPSHOT) to a branch right
after the release planned for today, given the fact that after the first
RC no new features or major changes in the code can be committed. The
only projects that need to be branched are platform-core, platform-web
and products-enterprise, as the others will not see major modifications
in less than two weeks. However, if someone does need to commit new code
in a dependency for XE/platform, we can create a branch on the fly.
Thanks,
Sergiu and my +1