Discussion about Community Contribution

General Discussion
1

I’ve decided to start such a discussion here after the latest Open Chat session on igniterealtime.org. For some time there were not much involvement in the open source projects from Jive staff. David and Daniel has left Jive and SparkWeb, Spark, Openfire are (or was?) in stagnation. Of course, one can say that Armando is now the new project lead for SparkWeb, but we havent heard anything from him for a while. WinSrev is doing some development on Spark in his spare time (community member, not a Jive developer), some other folks are submitting their patches, but this project still lacks speed in releases. Openfire part looks the same. Some community members are making the patches, but they cant submit them to a bug tracking system or even check it in the svn. Therefore it takes too long for a new version releases, security fixes. Community is willing to contribute. At least some of them. So, the purpose of this discussion is to form our proposition to Jive.

I have to say, that the current situation is upsetting many of the community members. There are even some talks about taking the source code and moving to some other project space. Jive wants to prevent Openfire project forking. Maybe that’s a sign we will come up with some agreement. Sounds like a blackmail, yeah?

On the bright side. Gato (Gaston Dombiak, Jive developer) has joined Open Chat today, after a long break. He is going to apply a lot of the provided patches, check the long standing security issues and probably release the new Openfire version this or next week. This is good. But this doesnt mean that we have to relax and wait till they (Jive) do all the job. We still want to contribute. Gato also mentioned that he will speak to Matt Tucker about the easier ways to submit patches. So, we are looking forward for their proposals.

Main Questions:

  1. What do the need? Some community member with rights to give Jira permissions, svn permissions, so this Provisor will give all the rights to those members he thinks right? Or maybe we should form a list of the developers/contributors with required rights and send it to Jive?

So far i can propose Coolcat (Jira/SVN), Guus (maybe he already has one or both), Walter Ebeling (Spark Jira, maybe even SVN), Daryl Herzman (Jira, probably already has / SVN). Nicklas Saefer (Spark Jira, SVN, probably has already). I can’t remember everyone right now.

  1. We need someone at Jive to push releases. As i understand, now we are very depended on that (install4j stuff). Or maybe we can think of/setup some other building process? Sometimes patches are very quick, sometimes we would want to beta test, but we have to wait for months for someone to build it. As i understand that’s why 2.6.0 release of Spark is holding.

  2. Igniterealtime.org website and forums. It lacks maintenance. Forums are not moderated. Or maybe they are? Because there is not much spam seen. But there is still some issues like wrong documents instead of discussions, there should be some Announcements about the important things (like Openfire 3.6.0a upgrade nag), some parts of the site are very outdated (screenshots, etc.). Maybe there is a point to give some of the contributors the rights (maybe not full) to maintain this site.

I’m waiting for your ideas on these 3 questions. Or maybe there are more?

2

  1. One can get SVN accesssigning the contributor agreement. Maybe Igniterealtime should modify it as they are no longer interested in a commercial build of Openfire.

  2. We need someone at Jive to push releases. But we do not need one to build a an EXE installer manually - do we? The files which do change are usually the libs/*.jar files so one could also offer a patch or “zip” version without installer. So one could download the 3.6.0 installer and a 3.6.1 patch. That makes it a little bit less comfortable for some users, but should be a possible way.

Another option would be to automate the “build EXE installer” task so it can run nightly. Similar to the nightly builds.

  1. Do you mean the http://www.igniterealtime.org/images/ignite_home-circlegraph.gif “Commercial Extensions” image?

There are indeed some things which should be updated, just setting up a web page and hopping that everything turns out good did not work 10 years ago so one may wonder why it should work in our days. As far as I can tell there are only a few things which should be polished so I think that Igniterealtime can take the time to do this. Probably using a forum like this one were users can post simple “clean-up” tasks.

  1. Add a “donate” button. Even if the yearly donation is only $3,55 one could share it between the more or less active developers and forum users.

  2. Maintain the reached quality when releasing a new version. Francisco did create some QA documents, one may want to publish them here.

LG

3

Hey wroot,

Thanks for posting this. Hopefully we can avoid a forking, but things need to move along. Openfire is rapidly loosing mind share and this security issue is a huge problem.

Getting SVN access is not enough, the community needs control of the release process. If some nameless person at Jive is going to force broken releases out the door (which is exactly what happened with OF 3.6.0), then what is the point.

It also frustrates me to no end to see Jira basically unused. What is the point if Jive employees don’t read emails generated from Jira. Half of the stuff we discussed today was properly triaged, assigned, and some had patches attached. Then we get to hear the “patches welcome”, well whatever.

daryl

4

As I said yesterday in the chat, forking would be a bad idea.

I think testing submitted patches is the main problem. We need to find a way so this can be done by the community.

Also we need a better coordination. In the last two days I spend approx. 8 hours on a patch for the bug in AuthCheckFilter, half of the time together with Guus. After I posted the patch in JIRA, it come out that Matt Tucker was also working on that…(however, his solution is still not secure…)

P.S. a “donate” button is a good idea…problem is who get’s the money?

Message was edited by: Coolcat

5

Ok. I’m trying to gather all the ideas and thoughts.

LG’s proposition about zip patches sounds interesting. This could be a quick way for the community to make and share patches. I see this like some special DOC with the list of patches, instructions, changelogs and attached packages. Only a few members could have access to that DOC. Those patches could also be cumulative. But. Most of the community is not reading the forums, they just go to the download page and check for a new version. So maybe there could be a link to a doc with patches on the download page. But that starts to sound too awkward. Though, still such an idea of having quick hotfixes is interesting. And those patches later could be incorporated into a normal releases.

LG, can you comment more on “Another option would be to automate the “build EXE installer” task so it can run nightly. Similar to the nightly builds.”? Are you speaking about Jive building it with install4j nightly or we will have to use some other system?

As about polishing and maintaining the site. Gato said that they have a man who is maintaining all their sites. I think he didnt understand the whole question. He was speaking about their web admin probably. Web admin cant update the outdated content or polish the site… This part lacks understanding from Jive i think. I dont mind it to be done by Jive.

Both Daryl and LG mentioned QA. So maybe we should form a QA team and Jive should wait for this team approval before releasing something? I wonder will it help much? I’m sure they have their own QA and as they say “doing many tests on more than one server”. Personally i havent had any significant upgrade problems for a long time. On the other hand others do have problems. So we can still miss something and the release will be delayed longer. Hard to decide. Sure, we need some QA instructions to do that, cause now i can only check if it launches after the upgrade and can i send the messages. Probably i can volunteer for some QA (windows exe and linux tar.gz), but i need to know what should i be doing.

Testing of the patches by community. This can be some sort of QA. Contributor releases patches. Our QA team tests it and then approves that everything is working correctly. Then Jive incorporates these patches. Gato was speaking about some “crucible” addition to a svn/fisheye which will let to review patches after the submittion, if i understand right. If this really can help, we should “push” Jive to implement this in their system.

And the last and very important thing. The lack of response. I bet noone from Jive is reading this Maybe their are not watching Jira closely either. As well as the forums. I can understand that this is a large amount of information to monitor/test/answer etc. This version of Clearspace lets us to create social groups. What about creating some small closed contributors group. Also someone from Jive should be a member of that group, and not just formally. He will have to check that group’s discussion and submission on a regular basis. Maybe we should have a separate chat session for that group. Then such a group will gather all the most important reports, patches and relay it to a Jive guy. The traffic should be smaller, more concentrated and detailed. This is just an idea. This won’t work without Jive bigger involvement than now. We need a strong link with them (preferable Gato or Matt).

I think donations should go to LG, as he is so actively pushing this idea Personally i dont see how this can help. People will donate to Jive i think, but they will be willing to get some feedback in quick releases and bug fixes. I dont think this will motivate Jive a lot. And i dont think people will be willing to donate on an account of some unknown to them community contributors…

6

Hi Oleg,

with patch I mean an additional zip file which contains all modified files since the last “installer” release. So it shouldn’t be too hard to extract it over the existing installation. That’s the way how the linux tar.gz installations are updated.

Another option would be to automate the “build EXE installer” task so it can run nightly.

I think (maybe I’m wrong) that Igniterealtime builds these manually so it requires a lot of Daniels time and manual interaction and he always makes an error as he does not create installers often. So the nighly build script should create the installers and publish them on http://www.igniterealtime.org/downloads/nightly_openfire.jsp if this is possible. So using branch/ instead of trunk/ as the build source would be very easy.

So maybe we should form a QA team and Jive should wait for this team approval before releasing something? -Yes.

Testing of the patches by community. - I prefer a JUnit test to reproduce this problem. After writing the test case one should write and commit the patch and verify that the JUnit test passes then.

The lack of response. I bet noone from Jive is reading this. - They read it, at least my post. I think … hopefully.

*Donations *… a lot of admins may be happy to find such a nice chat server and some of them have money to spend. And Igniterealtime must take care about image cultivation. Handling security reports in a bad was likely stops any money flow.

LG

7

That “contributors group” idea sounds good, also an extra chat date for them. Once a week they talk about what bugs are urgent to fix, discuss implementation details and so on.

For QA, what about an Pre-Release? Just after a few quick tests, we bring it out, explicitly marked as test release for experienced users, or for users that are directly affected by an bug. Then, a few days later, if no errors where reported, it’s simply renamed as release.

8

Hi coolcat,

I have reservations about a contributers group. I wouldn’t want to participate unless the discussions were held in the open. I would think some users would feel left out, since they can’t be a part of the cabal. Maybe there could be a minimum CS point total for entry

For QA, I make attempts to follow and test things as they show up in trunk. The problem is that the release schedule is not known and with 3.6.0 a lot of code showed up literally hours before it was released, without a beta, and I don’t recall ever seeing intention of a release. There was no chance…

daryl

9

I have reservations about a contributers group.
I agree that this should be public normally. However, there are things that should be not public, e.g. details to an vulnerability. These details can be made public after there was a patch released.

10

LG, FYI, Daniel is no longer working for Jive. And he has probably abandoned IM Gateway, at least for a while

About QA. I see that i won’t be able to complete all the stuff. And i see a problem. Because i have never succeded to install/remove plugins on my Windows box without a problems. Compaining about that on the forums for ages… But i can do some part of it.

JUnit is ok, if you say so. Though this could be to high for me. This is more for the developers/coders probably. Hey, but real life testing is still worth something

11

Coolcat wrote:

For QA, what about an Pre-Release? Just after a few quick tests, we bring it out, explicitly marked as test release for experienced users, or for users that are directly affected by an bug. Then, a few days later, if no errors where reported, it’s simply renamed as release.

Pre-Release sounds like Beta. And there is already a place for betas at Ignite. It’s just these betas will come up more frequently. Maybe this page can be renamed to Beta/Pre releases. And then we can name pre-release like openfire-3.6.1pre1.exe/zip and place it on that page.

12

As i understand those social groups doesnt have to be closed. I can navigate to some of them and read the discussions and documents. Of course, most of the users are not aware of them. Maybe we could announce about such group existance in the forums, so more people would know about that. I just want to concentrate the info traffic on more imporant and detailed stuff, i dont want such group to became the ordinary forum flooded with not detailed reports and so on. We already have public forums for that. Well, we can create a sub forum for that purpose.

13

hey wroot,

To play devil’s advocate, why can’t Jira handle this ‘higher’ level

communication?

daryl

14

@Daryl:

Good argument…biggest benefit: No stupid clearspace RTE…

I think JIRA does also allow to create non-public issues (for the vulnerability details…)

15

wroot wrote:

LG, FYI, Daniel is no longer working for Jive. And he has probably abandoned IM Gateway, at least for a while

Actually, I have not exactly abandoned it. I will simply say that I am doing something “a little different” with it at the moment and I’ll post about it when it’s worth posting about. hehe (right now it’s an early work in progress and I don’t want anyone dancing over to it until it’s ready to be danced to)

Anyway, cool discussion here guys. Hope something comes of it!

16

Hi, Daniel. Sorry for my presumptions. We just didnt have much information from you. Glad you are still with us

17

If you think that Jira would be enough, then i’m ok. I was speaking more about communication between such contributors. Jira issues has comments, but a discussion have to start somewhere. Probably like it is now, someone reports something on the forums, then a contributor tests it, confirms and creates the Jira ticket. But how would be all other “team” members notifyed? Probably one will need to monitor all new Jira issues, if that’s possible.

18

For real discussions we could use the Openfire Dev forum, I think that was the idea behind that forum

19

JM-1489 was closed even though muesli posted the exploit for Matt’s patch. Also there was an much cleaner patch available. In my opinion this is an absolute no go…

http://www.igniterealtime.org/issues/browse/JM-1489

20

Hi All,

Interesting discussion. Here’s a couple of my thoughts:

I agree with the concerns some people have expressed about a contributors group. One of the complaints about the way the community is currently run is that there isn’t enough transparency about who is working on what and where things are headed. I think it would be best to keep discussions, even if they are security related, completely open.

As for the donate button idea, I think that leads to a whole new set of problems which the community might not want to be distracted by right now. Questions such as who is control of the donated funds and who decides how the funds are distributed would have to be answered. Also, from a legal standpoint it maybe necessary to establish a non-profit corporation which would require the filing of paperwork, appointing members, etc. Given that Jive and Contegix provide the community software and hosting free of charge the need for funding isn’t needed at this point and it might be best to not get bogged down in financial issues.

Cheers,

Ryan