[ejabberd] process-one?

Wed Aug 1 17:06:58 MSD 2007

Hello Badlop,

Le 31 juil. 07 à 16:55, Badlop a écrit :

> 2007/7/31, Evgeniy Khramtsov <xramtsov at 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.

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.

> 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

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.

> 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.

> 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 :)

> 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.

> 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 agree. Contributions does not necessarily means patch 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.

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.

> 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.

> 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&sel 
> ectedProjectId=10011&reportKey=com.atlassian.jira.ext.charting% 
> 3Aresolutiontime-report&Siguiente=Siguiente

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jabber.ru/pipermail/ejabberd/attachments/20070801/b7a2b5ec/attachment.htm 