Hi
how about pushing smack a bit ahead by applying the patches in DOC-1722 and running them in teh custom build enviroments we are having. If a patch is invalid, we may document it in the DOC-1722 and jira.
As a starter I have posted the latest smack from trunk together with some patches here
Walter
Well. I can probably test smack builds, though maybe i won’t be smart enough to test what has been fixed I usually specialize on GUI and simple user features of the client (Spark). Also, do i have to replace those files in my Spark 2.6.0 Beta 2 installation or in the latest SVN? And do i have to replace only those 2 files. I think there were more files when cstux was uploading his custom smack fix.
Hi,
you can drop the jar files in the lib folder of your installation (maybe after a copy of the old ones 
). You may also exchange the jars in the SVN for a custom build.
The fix of cstux will go into the community edition of Smack. I had screwed the links in DOC-1722 but these are fixed now. I’ll do a a recompile of smack with the generics patch.
Walter
Hi Walter,
good initiative! Have you asked the Jive developers whether they would grant you commit access the repository to drive this community development forward? Or do you think it will be necessary to fork?
Cheers,
Christopher
Jive is giving the management of the projects to community. Slowly though. So, to get commit rights one has to show his skills to other community members and prove he can be trusted. In the other words there is a mentorship program here. Though, it can be hard to find a mentor, as there are not many active community members here.
Hi Wr00t,
I think you are absolutely right. Jive is moving in this direction, but I think the pace is too slow. It has been more than 6 months since the last release and only a handful of patches have been committed. The project I am working on has been telling our users that a fix for working with Google Talk is coming, but since it does not look like a release is happening soon I think Walter is right.
You will have noticed that I started a community patch repo at
so that the community can take Smack forward, if they choose so. It seems to me that a decentralized version control system like Git is more appropriate for the kind of project that Smack is.
Christopher
Yes, i have noticed your fork I have nothing against forks, but i think most of the users won’t notice it and still be looking on the main site. I think this has to be an official fork, so Jive will change the project, forums pages and point users to the alternative repo. Once we were talking about forking everything, say at sf.net. Then Jive became afraid and started working (patches, releases), but that didnt last long. So, we have to frighten them again or just take everything and move This is indeed gets very frustrating to see how these things freeze.
As about decentralized repo. How would you control the quality if everyone can commit? It can become a mess after some time. Unless there will be only 2-3 commiters
I would not call it a fork. At least it is not my intention to split the Smack project. The community is here at Jive, the bug tracker and discussion boards and everything. Rather** **I need a bug-fixing release (just as Walter did), but I need it now.
About managing with a decentralized repository: It is not my intention to grant commit access to this repository to anybody, but rather encourage everyone in the community to create their own repository by cloning the community repository. I am certainly willing to apply patches or pull from other repositories for all changes I deem appropriate. In any case, once we start using Git, the repository at repo.or.cz is nothing special, you can just clone it again, put in your patches, tell people about it and if they trust you they can pull your changes from you instead of tracking my repository.
This way not the leadership of a project decides who can be trusted, but the community does.
Christopher
I see. Interesting approach. Though, maybe you shouldnt remove SMACK issues out of the waiting for a trunk table and just add the comment that this is fixed in the alternative repo.
wroot wrote:
maybe you shouldnt remove SMACK issues out of the waiting for a trunk table and just add the comment that this is fixed in the alternative repo.
Done!