| Author |
Message |
|
| Guest |
 Posted: Mon Jul 30, 2007 8:37 pm |
 |
|
|
Guest
|
So, what's the deal with process-one? What do you get from paying them
vs. using the open source ejabberd? Are they offering support, do they
sell some proprietary add-ons, or do they withhold patches from
non-subscribers?
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 31, 2007 7:00 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 31, 2007 8:00 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 31, 2007 9:00 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 31, 2007 9:20 am |
|
|
|
Guest
|
Christophe Romain wrote:
>that's why ejabberd-modules exists
>http://ejabberd.jabber.ru/ejabberd-modules
>
>
I don't see the difference between these modules and contributions.
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 31, 2007 11:40 am |
|
|
|
Guest
|
2007/7/31, Evgeniy Khramtsov <xramtsov@gmail.com>:
> I don't see the difference between these modules and contributions.
I'll try to explain how I understand it.
The difference between
1. the list of source code contributions to ejabberd published in
http://ejabberd.jabber.ru/contributions
and hosted by jabber.ru's ejabberd Drupal page
and
2. the source code repository for contributions to ejabberd available
in ejabberd-modules SVN, and hosted by Process-one's SVN server
is this: the contrib page lists and announces contributions, while the
modules svn hosts source code. The contrib page is like freshmeat.net
for ejabberd modules and patches. The modules svn is a svn repository.
Both resources complement.
I consider that neither ejabberd-modules nor the contrib page list
source code that is awaiting to be commited to core ejabberd.
For example, I didn't write this module to be included in ejabberd:
http://ejabberd.jabber.ru/mod_chatcommands
I wrote it to provide a wacky and funny feature. I doubt any
responsable and respected administrator really needs such a feature 
If anybody needs, he can find it using Internet search engines.
Note that both the contrib page and the modules svn also include
projects that should be someday included in ejabberd, for example.
Summary: I consider the primary purpose of those resources is not to
list which patches are awaiting integration.
Then, where can we see what patches and modules are awaiting
integration in ejabberd core? I think the best place to look for this
is bug trackers. When I want my code to be submitted to SVN, I create
a bug and attach the patch; examples:
http://www.jabber.ru/bugzilla/show_bug.cgi?id=253
https://support.process-one.net/browse/EJAB-18
If you still don't see the difference between ejabberd-modules and the
contributions page, I'll put yet another example:
1. I want a certain feature, for example a small cron system to
schedule tasks inside ejabberd without needing unix's crontab.
2. So, I request an account in ejabberd-modules SVN, and start
implementing mod_cron. Debug, fix, test, experiment with the code,
etc.
3. Once I consider the code is usable by other people I request a page
in Contributions, which briefly summarizes what mod_cron is, where to
find the code, the author...
http://ejabberd.jabber.ru/mod_cron
4. If I someday consider that mod_cron is very interesting for most
ejabberd administrators, I will file a bug report in the bug tracker
proposing my module to be included in ejabberd core.
5. If my proposal gets accepted, the page is moved from Contributions
to Features. The source code may continue living in ejabberd-modules
SVN, or may be moved to ejabberd SVN.
6. If the proposal is rejected, mod_cron will continue living as it
is: code in ejabberd-modules, home page in Contributions.
---
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 31, 2007 2:55 pm |
|
|
|
Guest
|
2007/7/31, Evgeniy Khramtsov <xramtsov@gmail.com>:
> Christophe Romain wrote:
>
> > we do not withhold patches from non-subscribers.
>
> Of course. And http://ejabberd.jabber.ru/contributions approves this.
I completely agree with Evgeniy that the speed at which patches
submitted by independent developers are commited in ejabberd core is
really really slow.
To make this comparison, I consider the speed that was typical in
ejabberd in 2004 and 2005, and also the speed that has always been in
Tkabber (those are the only projects that I inspect regularly). I
consider 'fast': some days, or some weeks, but less than a full
working month.
For example: the Galician translation took 5 weeks to commit:
My request:
> Subject: ejabberd - new translation: galician
> Date: Sat, 23 Jun 2007 11:52:17 +0200
The final response:
> 846 by alexey 31 July 2007, 06:13:39 +0200
>* src/msgs/gl.msg: New galician translation (thanks to Carlos E. Lopez)
The patches that Aleksey submitted yesterday, also took around 5 weeks
to commit. I've gathered several possible reasons: required detailed
review due to sensitive location of changes; travels; forgotten; I
didn't test them in real world server; the format of spaces and tabs
was strange...
Since I spend some of my spare time writting such code, I find
irritating when for any reason the proposals don't get
accepted/rejected in a reasonable lapse of time. And this tends to
happen quite frequently nowadays in ejabberd, IMHO. This is a
text-book reason why people loose interest in open source.
Aleksey has tell me several ways to reduce the time he needs to review
patches. I'm investigating that topic, and if it really seems to help,
I'll write a document aimed at ejabberd contributors. Call me
optimistic
I agree with you that P1 commits patches from outside P1 very, very slowly.
But to reflect this conviction, it does not help to show
http://ejabberd.jabber.ru/contributions
because that page does not list patches awaiting integration.
I find more convincing to show the list of pending bugs for ejabberd
2.0.0 in JIRA:
https://support.process-one.net/browse/EJAB?report=com.atlassian.jira.plugin.system.project:roadmap-panel
I'm pretty sure that at least 10 of the 40 bugs that block the next
ejabberd release have a patch available that is awaiting
commit/reject/review for several weeks and even months.
This is visible too in Bugzilla: 30 bugs with patch available
http://www.jabber.ru/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=Importance&field0-0-0=attachments.ispatch&type0-0-0=greaterthan&value0-0-0=0
I also found this graph, but I still have no idea how to interpret it:
https://support.process-one.net/secure/ConfigureReport.jspa?projectOrFilterId=project-10011&periodName=weekly&daysprevious=365&selectedProjectId=10011&reportKey=com.atlassian.jira.ext.charting%3Aresolutiontime-report&Siguiente=Siguiente
2007/7/31, Evgeniy Khramtsov <xramtsov@gmail.com>:
> Christophe Romain wrote:
> > and we are committing our improvements directly into ejabberd trunk.
>
> Actually, there are only your improvements in ejabberd trunk for the
> last year or so.
https://forge.process-one.net/search/ejabberd/?comment=%28thanks+to&contents=&filename=&branch=&tag=&fromdate=2006-07-31T00%3A00%3A00&todate=&groupby=changeset&col=path&col=author&col=date&col=csid&col=linesAdded&col=linesRemoved&refresh=y
This page shows files that were changed in ejabberd SVN with a comment
that contains "(thanks to" since 365 days ago. This page shows the
improvements in ejabberd trunk for the last year. Remember that only
Aleksey and P1 have commit access to this SVN. All those revisions are
related to independent ejabberd developers: they are contributions
that are committed with a comment that gives thanks to the author.
If you have time, maybe you can convert that page into text, and draw
a graph that shows when are contributions added, and how many lines of
code, and how many commits in overall. And also to see if the trend is
decreasing, increasing, stable or unstable.
The next step you may want to do is to extract a similar list, but
only with code that comes completely from P1. And also draw a graph.
Finally, when you compare both graphs you will know with complete
certainty and tangible proofs that P1 does in fact commit a lot a lot
less code coming from outside themselves than inside themselves.
This material proof will help you to start a fork, and people will be
happy that you free them from oppressive private powers that want to
destroy ejabberd, or even worse, convert it to the dark side.
However, if I had only personal opinions and suspicions, but not
demonstrable facts, I would prefer to say
> Actually, *I think* there are only your improvements in ejabberd trunk
> for the last year or so.
This way, I transmit my opinions to others, but I cannot be accused of
calumnious, right? 
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 1:07 pm |
|
|
|
Guest
|
Hello Badlop,
Le 31 juil. 07 à 16:55, Badlop a écrit :
Quote: 2007/7/31, Evgeniy Khramtsov <xramtsov@gmail.com (xramtsov@gmail.com)>:
I completely agree with Evgeniy that the speed at which patches
submitted by independent developers are commited in ejabberd core is
really really slow.
This is not my view. The reference for patch is the bugtracker that the developer are using to organise ejabberd development:
http://support.process-one.net/
This bug tracker is open for registration (I have seen that sometime the process fail, due to a bug reported to Atlassian, drop me a mail saying you want an account if this happens to you).
If it does not show there, it means that we are not aware of the patch. If we are not aware of the patch, we cannot work on integrating it. We sometime monitor various contributions place on the web, but not on a regular basis.
Another obvious advatange in submitting your patch there is that:
- You get feedback on it,
- You know when it is scheduled for integration
- You know when it is worked on,
- You know when it reach SVN
For the examples that have been mentioned on fast integration versus slow integration this is the main difference.
Quote: To make this comparison, I consider the speed that was typical in
ejabberd in 2004 and 2005, and also the speed that has always been in
Tkabber (those are the only projects that I inspect regularly). I
consider 'fast': some days, or some weeks, but less than a full
working month.
For example: the Galician translation took 5 weeks to commit:
My request:
Quote: Subject: ejabberd - new translation: galician
Date: Sat, 23 Jun 2007 11:52:17 +0200
I have no idea how the patch you talk about have been submitted.
My guess is that it has been send privately to Alexey.
By doing so, you depend on the time, memory etc of a single developer, not a development process. By doing so you rely on a private exchange and you cannot consider it as an official submission. I for example never seen this patch.
Quote: The patches that Aleksey submitted yesterday, also took around 5 weeks
to commit. I've gathered several possible reasons: required detailed
review due to sensitive location of changes; travels; forgotten; I
didn't test them in real world server; the format of spaces and tabs
was strange...
I read it as ironical, but the reason is that we did not knew about this patch.
Quote: Since I spend some of my spare time writting such code, I find
irritating when for any reason the proposals don't get
accepted/rejected in a reasonable lapse of time. And this tends to
happen quite frequently nowadays in ejabberd, IMHO. This is a
text-book reason why people loose interest in open source.
Aleksey has tell me several ways to reduce the time he needs to review
patches. I'm investigating that topic, and if it really seems to help,
I'll write a document aimed at ejabberd contributors. Call me
optimistic
We have a process in place for that already. This is a project with multiple developer and cannot rely only on one developer.
The answer is here:
http://support.process-one.net/
Now, it just await contributions to be submitted
Quote: I agree with you that P1 commits patches from outside P1 very, very slowly.
I have replied to that. We can only work on integrating patch we know about. When we know about them, they are discussed, schedule, improved, etc.
I agree. Contributions does not necessarily means patch awaiting integration.
Why is it so ?
Because, we fix major problems before minor one. When the major one are fixed, the release will be close and integrating the small / minor changes will be pretty fast.
I am sorry, but I only go there from time to time and cannot monitor closely what is there.
Not sure you can interpret it, if people do not submit patch there and if we are not sure every ticket is close as soon as the patch is commited.
I hope this helps clarifying a bit the question of patch integration.
--
Mickaël Rémond
http://www.process-one.net/
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 1:19 pm |
|
|
|
Guest
|
Den Wednesday 01 August 2007 15.06.58 skrev Mickaël Rémond:
> > This is visible too in Bugzilla: 30 bugs with patch available
> > http://www.jabber.ru/bugzilla/buglist.cgi?
> > bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=R
> > EOPENED&order=Importance&field0-0-0=attachments.ispatch&type0-0-0=grea
> > terthan&value0-0-0=0
>
> I am sorry, but I only go there from time to time and cannot monitor
> closely what is there.
Isn't it better to have this bug tracker closed if it isn't used or preferred?
Google believes the main page for ejabberd is ejabberd.jabber.ru and currently
that doesn't seem to be true with no news AT ALL since 1.1.3 was released.
Get rid of it and move everything to process-one so information can be found
atleast. With duplicate information it is quite easy to forget to update at
once place, it is as bad as not having documentation at all.
/Albert
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 2:00 pm |
|
|
|
Guest
|
2007/8/1, Albert Holm <albert+ejabberd@cdr.se>:
> Isn't it better to have this bug tracker closed if it isn't used or preferred?
Both are used by general people, but ejabberd core developers use
mostly JIRA. Preferences may vary (I for examples prefer Free Software
instead of Proprietary), but if JIRA provides more features, and is
preferred by ejabberd core developers (including Aleksey), and anyway
is free of cost to P1... I'll use it without problem.
Instead of closing Bugzilla, I propose to inform that the ejabberd
core developers use the P1 bug tracker (JIRA). By inertia, new bugs
will be submitted to that bug tracker. The bugs in Bugzilla can be
referenced as new in JIRA, adding a link to the Bugzilla entry. After
some time, most bugs in Bugzilla will already fixed/rejected. Then
Bugzilla @ jabber.ru will remain only for archiving purposes.
> Google believes the main page for ejabberd is ejabberd.jabber.ru and currently
> that doesn't seem to be true with no news AT ALL since 1.1.3 was released.
I'm completely responsible for that. For several months (and years) I
considered that only very very important announcements and news should
appear in the front page.
I now think this is not a good idea, as you pointed. I plan to be less
restrictive about what is promoted to front page since september (or
whenever ejabberd 2.0.0 is close to release) . For example: new
tutorials, and new FAQ entries could be promoted.
> Get rid of it and move everything to process-one so information can be found
> atleast. With duplicate information it is quite easy to forget to update at
> once place, it is as bad as not having documentation at all.
If you look closely, ejabberd.jabber.ru hosts mostly
information/documentation relevant to ejabberd developers and admins
(except ejabberd guide.html and some technical pages).
ejabberd@process-one has mostly source code, packages, installers,
SVN, bug tracker and news.
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 3:47 pm |
|
|
|
Guest
|
Badlop <badlop@gmail.com> writes:
> Instead of closing Bugzilla, I propose to inform that the ejabberd
> core developers use the P1 bug tracker (JIRA). By inertia, new bugs
> will be submitted to that bug tracker.
I propose that submission of new bugs to Bugzilla be disabled, with a
pointer to JIRA.
> The bugs in Bugzilla can be referenced as new in JIRA, adding a link
> to the Bugzilla entry. After some time, most bugs in Bugzilla will
> already fixed/rejected. Then Bugzilla @ jabber.ru will remain only
> for archiving purposes.
I'll try to transfer the Bugzilla bugs I care about…
--
Magnus
JID: legoscia@jabber.cd.chalmers.se
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 3:54 pm |
|
|
|
Guest
|
On Wed, Aug 01, 2007 at 05:46:26PM +0200, Magnus Henoch wrote:
> Badlop <badlop@gmail.com> writes:
>
> > Instead of closing Bugzilla, I propose to inform that the ejabberd
> > core developers use the P1 bug tracker (JIRA). By inertia, new bugs
> > will be submitted to that bug tracker.
>
> I propose that submission of new bugs to Bugzilla be disabled, with a
> pointer to JIRA.
>
> > The bugs in Bugzilla can be referenced as new in JIRA, adding a link
> > to the Bugzilla entry. After some time, most bugs in Bugzilla will
> > already fixed/rejected. Then Bugzilla @ jabber.ru will remain only
> > for archiving purposes.
>
> I'll try to transfer the Bugzilla bugs I care about???
Let's disable bugzilla, website, maillist and conference on jabber.ru as
deprecated by p-1.
ermine
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 4:43 pm |
|
|
|
Guest
|
2007/8/1, Anastasia Gornostaeva <ermine@ermine.pp.ru>:
> On Wed, Aug 01, 2007 at 05:46:26PM +0200, Magnus Henoch wrote:
> > I propose that submission of new bugs to Bugzilla be disabled, with a
> > pointer to JIRA.
>
> Let's disable bugzilla, website, maillist and conference on jabber.ru as
> deprecated by p-1.
Instead of forcing the complete shutdown of Bugzilla, incinerating the
backups, and sending the remaining ashes to the outer space, I propose
to call it 'superseded'; and let it be as a fall-back bug tracker. So,
if Aleksey agrees, JIRA@P1 can be named official ejabberd bug tracker
from now until Aleksey considers, and be used as M Remond explained in
a previous email.
I don't agree in closing ejabberd.jabber.ru Drupal site because I
think it's the best publicly accessible resource for information
regarding ejabberd. I don't see absolutely any reason to move to a
Drupal/Plone/Wiki/whatever hosted in any other place. I consider
ejabberd.jabber.ru is very good as it is now. If it has any problem,
it can be reported in the forums, this mailing list or privately, and
fixed.
I don't agree in closing the ejabberd mailing list hosted by
jabber.ru. It is a long-lasting mailing list, it is the official
mailing list for announcements, discussions, technical questions, etc.
about ejabberd. It runs fast, no problems... no reason to close it.
I don't agree in closing ejabberd chatroom at conference.jabber.ru.
The reasons: the same that above
I think bug tracker & patch submission is closely related to svn
commit. So I think that it is reasonable that resources related to
*code* like SVN, downloads, JIRA and Fisheye, all of them may be
hosted and administered by P1.
For the same reason, I think that resources related to *information*
like mailing lists, forums, tutorials, discussions, proposed changes,
and in general anything that does not strictly require P1 involvement,
can be (and should be) hosted and administered by independent people,
like the current drupal page, forums, mailing list, chatroom and
whatever we later find useful.
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Aug 01, 2007 7:03 pm |
|
|
|
Guest
|
On Wed, Aug 01, 2007 at 06:43:10PM +0200, Badlop wrote:
> > Let's disable bugzilla, website, maillist and conference on jabber.ru as
> > deprecated by p-1.
>
> Instead of forcing the complete shutdown of Bugzilla, incinerating the
> backups, and sending the remaining ashes to the outer space, I propose
> to call it 'superseded'; and let it be as a fall-back bug tracker. So,
> if Aleksey agrees, JIRA@P1 can be named official ejabberd bug tracker
> from now until Aleksey considers, and be used as M Remond explained in
> a previous email.
>
I wonder why never before nobody asked to disable Bugzilla, only now?
Remember: it has been started before p1 appears on our horizont and
Remond knows about it's existence excelently, istn't?
So, why we should disable bugzilla bugzilla just now?
Let's leave it as is. Let's P1 to win in other ways.
ermine
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Aug 02, 2007 7:54 am |
|
|
|
Guest
|
On Aug 1, 2007, at 8:02 PM, Anastasia Gornostaeva wrote:
> Let's leave it as is. Let's P1 to win in other ways.
Disclaimer: I work for a P1 client.
I don't think this is about "let P1" win. It's not about win or loss,
unless you are referring to proprietary IM networks.
This is about what is the best and most productive way to help
ejabberd developers, right? To make sure patches don't get lost and
are timely included in the ejabberd core.
I think everybody would benefit from this.
And yes, personally I prefer bugzilla over JIRA, but I don't care,
because I don't have to use it everyday to track the development of
the beast.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
