We are going to end up releasing M1 with a *lot* of broken tests, I have not seen anyone volunteer
to fix or look at any yet.
see: http://dev.xwiki.org/xwiki/bin/view/Community/ReleasePlans#HFixfailingtests
Going forward to M2 we are going to need a major stability drive and I think this is a good time to
introduce the "stable branch" as per the branching strategy laid out here:
http://nvie.com/posts/a-successful-git-branching-model/
#1. Bug fixes are committed against the stable branch and forward ported to the development branch.
#2. New features are committed against the development branch and then merged back to the stable
branch only after we are assured they have not broken any tests or introduced bugs.
Here's my +1
Caleb
I offered to take over the release since Jerome was unable to do it and right now we have 38 test
failures.
16 selenium1 tests,
6 selenium2/ui-tests
16 webstandards tests.
We have 3 options:
1. We can release now and accept bugs in the release.
2. We can have volunteers to take over tests and get them passing for tomorrow so tomorrow I can
release.
3. We can opt to postpone the release. If I work on these alone I expect it to take about 1 week as
long as nobody commits code which introduces further regressions.
I don't think postponing the release is wise at this point and #2 is contingent upon volunteers
claiming ownership of specific tests so I think #1 is the lesser of the evils.
Do I hear any objections/volunteers?
Caleb
Hi devs,
I'm going to start working on a XWiki extension repository.
The idea is to provide a repository of extension like you can do with
maven repository but with a lot more possibilities like commenting on
extensions, grades, statistic, direct search...
The (work in progress) reference design page is
http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerXWikiRepository.
the general idea is to have the following modules:
- server (jar): basically a collection of rest resources allowing to
manipulate extensions
- server UI (xar): allow to administrate the repository itself
- client (jar): extension manager repository handler for XWiki
repository which communicate with server module using REST
the plan is to provide for 3.1 a first version with at least the
following characteristics:
* server side
** extension are in wiki pages (even extension themself as
attachments, it's not the design long term goal it's simply the
quickest for 3.1)
** REST interface will provide what extension manager already support
in maven repositories plus:
*** search extensions (probably just simple search for now)
** UI will have a livetable of extension and not much more
** will try to integrate it to extension.xwiki.org
* client side
** extension manager API will be added with search capabilities
** add a search filed in the existing extension manager admin UI
** the XWiki repository handler module of course
Thanks
--
Thomas Mortagne
Hello,
I want to download the source code in order to build from source.I cant
find a zip file which contains the source.Can someone help me?
Thank you!:D
Hello community, Hello Google Summer of Code students,
First of all, congratulations on your applications and your activity
during the selection period, and welcome in the XWiki development team.
Before guiding the accepted students to their next steps, we'd like to
thank again all those who showed interest in XWiki for this Summer of
Code. We had a lot of good applications this year, with professional
approaches and interesting ideas, and it was very difficult to choose
only 3. Unfortunately, some very good students, with great potential,
were not accepted. So, to those interested in getting involved anyway,
without Google's implication, I renew the invitation to put your ideas
in practice under the guidance of the community. Even though the money
will be missing, you can still take advantage of the other GSoC
benefits: learning new things, gaining experience, earning recognition,
etc [1]. If you would like to do that, please let us know by replying to
this mail.
For the accepted students, here are some getting started hints:
= Community bonding period =
According to the program timeline [2], the next month (until - May 23rd)
is to be used for community bonding.
The first thing to do, sometime this week, is to present yourself and
your project on the dev list, so that everyone knows who you are and
what to expect from you (a precondition is to be subscribed to the list,
which you should do ASAP if you haven't already).
Also, you should continue getting acquainted with the code, the
practices and the developers. Please make sure you all read and
understand the following - very useful - documents:
- [3] http://purl.org/xwiki/community/
- [4] http://purl.org/xwiki/dev/
- [5] http://platform.xwiki.org/xwiki/bin/view/Features/
= Mentorship =
We prefer open mentorship. While your assigned mentor is the one
officially in charge with your guidance, almost all interaction should
be done 'in the open' as much as possible, on the IRC channel or on the
mailing list. You should choose the communication medium according to
the importance of the matters to be discussed: naturally, the less
important issues are to be discussed on IRC, while the design decisions,
important progress announcements and testing/feedback requests go on the
list. This way, the community is informed on the evolution of your
project, and other developers can come up anytime with useful ideas and
suggestions. Moreover, if your mentor is hit by a bus (the bus factor
[6]), another developer can take his place with little effort.
= Communication =
Sitting alone in your room, working secretly on your project is
definitely a bad approach. However, please keep in mind that too much
communication can also be harmful, as it distracts the others from their
own work. You need to be able to communicate just right:
- provide meaningful information about your progress,
- ask the community's opinion on non-trivial design or implementation
decisions
- avoid waisting a lot of time on a problem, when a more experienced
developer (or a student that fought the same problem) could quickly
provide you an answer; however, do try to find the answer yourself at first.
Wrong: "Where do I start? What do I do now? And how do I do that? Is
this good? It doesn't work, help me!"
Right: "Since a couple of hours ago I get a strange exception when
building my project, and googling for a solution doesn't seem to help.
Looking at the error, I think that there's a wrong setting for the
assembly plugin, but nothing I tried works. Can someone please take a look?"
Subscribe to the devs list (if you didn't do this already), and start
monitoring the discussions. It is also recommended to subscribe to the
users list, but not mandatory. The notifications list is a little too
high volume and technical for the moment, but it is a great knowledge
source.
= Development process =
The project's lifecycle is NOT design -> implementation -> testing ->
documentation. [7]
We invite you to adopt a test driven development [8][9][10] approach and
to experience agile development [11]. After the first coding week, you
must have some code that works. It won't do much, of course, but it will
be the seed of your project. Every functionality will be validated by
tests. The code must be properly tested and commented at the time of the
writing (don't think you'll do that afterwards, because in most cases
you won't).
Since we've recently moved our codebase to GitHub [12], you should
register an account there and fork some xwiki repositories, so that you
can try to build XWiki from sources, and be able to contribute bugfixes.
We'll add you to the xwiki-contrib organization [13], and we'll create
dedicated repositories for each project. We encourage you to do __at
least__ weekly commits (ideally, if you are well organized, you should
be able to commit code that works daily, so try to aim at daily
commits). This way, the code can be properly reviewed, and any problems
can be detected before they grow into something too difficult to fix.
One big code blob committed at the end, no matter how good it may seem,
is a failure at several levels.
A simple way of having something functional in the first week is to
prepare the maven build for your modules, which will give you the first
unit test for the first class.
= Next steps, in a nutshell =
- Get more familiar with the code and development process and try to
master Maven, JUnit, Selenium, component driven development, ...
- Continue fixing a few small issues, chosen so that they are __related
to your project__. You can ask on IRC for help selecting good issues, or
you can pick from the (non-comprehensive) list of easy issues [14]
-- This will help you get more familiar with the code your project needs
to interact with.
- Refine and organize the ideas concerning your project (you can use the
Drafts space [15]), and write several use case scenarios.
- Start writing the first piece of code for your project.
At the end of the community bonding period, you should have a clear
vision of the project, well documented on the xwiki.org wiki, you should
have the build infrastructure ready, and you should be pretty familiar
with the existing code you will need to interact with. And, of course,
you should be familiar with the community and the way we communicate.
Good luck, and may we all have a great Summer of Code!
[1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/
[2]
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/ti…
[3] http://purl.org/xwiki/community/
[4] http://purl.org/xwiki/dev/
[5] http://platform.xwiki.org/xwiki/bin/view/Features/
[6] http://en.wikipedia.org/wiki/Bus_factor
[7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
[8] http://en.wikipedia.org/wiki/Test-driven_development
[9] http://www.amazon.com/dp/0321146530/
[10] http://www.amazon.com/dp/0201485672/
[11] http://www.amazon.com/dp/0596527675/
[12] https://github.com/xwiki/
[13] https://github.com/xwiki-contrib/
[14]
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1…
[15] http://dev.xwiki.org/xwiki/bin/view/Drafts/
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hello,
Username: sbose78
Server name: nsec
I wish to host a student portal for my institution and therefore wish to
host it as
nsec.myxwiki.org
I am hosting something similar at nseccse3.appspot.com but now wish to take
advantage of XWiki's architecture .
The application would be used for academic collaboration among students.
--
Thanks and Regards,
Shoubhik Bose
IF I REST, I SHALL RUST.. SO, LETS SHARE THE KNOWLEDGE !
Hi, I am so glad that I have got accepted in xwiki for gsoc2011. Thanks
Marius, Sergiu, and all the other developers in dev mail list, you really
helped me a lot during this time.
Now, I want to go deeper in xwiki development, first to find some issues in
JIRA and send a patch. Is there any documents for how to do this?
--
Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University
Hello XWikiers,
Has anyone worked on the possibility of signing-up into an XWiki with external authenatications such as Facebook, Google, OpenID, or any such?
I don't seem to see this.
thanks in advance
paul
Hey,
I think I was successfully able to find a solution for the bug "
http://jira.xwiki.org/jira/browse/XWIKI-6491"
I have commented the place where the message can be entered that needs to be
displayed when no document for the specified tag is found. Also I have
limited the number of entries that would be displayed by the "Activity
Macro" to 1 when no document is found.
You can find the code at the folowing link, the modified code is given in
'red' . I have tried n tested the code on my localhost.
https://docs.google.com/document/pub?id=1wV5eM4QE8fF971EtrL2yC2WRzJWpOEhcMO…
--
Thanks,
Supreet