On 05/29/11 10:36, Enrico Tröger wrote:

On Sun, 29 May 2011 15:25:12 +0200, Frank wrote:

...

On Fri, 27 May 2011 14:31:29 -0700 Matthew Brushmbrush@codebrainz.ca wrote:

...

Hi,

Would it be useful for someone with admin rights on SourceForge.net to create a "Patch Tracker"? I've seen some projects with this[1].

[1] https://sourceforge.net/tracker/?group_id=6556&atid=306556

I thought collecting them inside wiki as most seems to push them via git etc.

I don't mind much. Whatever you think is most useful.

It's not super useful like using a better development site would be, but it's better than nothing if that's never going to happen.

I just thought the wiki idea was weird, for example, what do you put there? Do you put a paste of the whole patch? Upload the patch file? Put a link to the Git repository where the changes are?

One thing that might be good on the wiki is to have a page that lists all the places where Geany development is happening, since only a handful of developers are doing it on the SF site.

Cheers, Matthew Brush

On Fri, 3 Jun 2011 19:49:33 +0300, Dimitar wrote:

On Fri, 27 May 2011 14:31:29 -0700 Matthew Brush mbrush@codebrainz.ca wrote:

...

Would it be useful for someone with admin rights on SourceForge.net to create a "Patch Tracker"?

A patch tracker would be nice to have IMHO.

...

I've seen some projects with this[1].

Any new project created on sourceforge automatically receives a one.

On Sun, 29 May 2011 15:25:12 +0200 Frank Lanitz frank@frank.uvena.de wrote:

...

I thought collecting them inside wiki as most seems to push them via git etc.

Bugs and feature requests in SF trackers, but patches in a wiki? Hmm.

Good point. Created one[1]:

https://sourceforge.net/tracker/?group_id=153444&atid=787793

[1] actually it existed all the time but was hidden

Regards, Enrico

On 06/09/11 10:40, Thomas Martitz wrote:

Am 27.05.2011 23:31, schrieb Matthew Brush:

...

Hi,

Would it be useful for someone with admin rights on SourceForge.net to create a "Patch Tracker"? I've seen some projects with this[1].

We, at Rockbox, are in the process of abandoning our patch tracker. Because it has grown to host over 400 patches, nice ones as well as bad ones, which nobody looks at.

We made the following observation after years with a patch tracker. If core developers are rare or lack time or can't otherwise regularly look at the patches (which is the case for Geany too), it will become a place to let patches rot. The problem is that a patch tracker creates the idea that once a patch is uploaded the project is responsible for them and not the contributor. This means the contributor is less motivated to work on the patch to make it committable or to pester developers.

The way I see it is that a patch tracker will not work for Geany.

So it's better to let them rot in the (non-searchable) archives of a mailing list? It's at least a bit better than the current situation, since it's easier for a core developer to see a list of outstanding patches in one page, and people down the road can see the patches and update them to work with newer versions later if they get forgotten.

Of course, like you said, if nobody looks at it ever, it's still pretty useless.

Cheers, Matthew Brush

Unless the patch tracker lives long enough to grow to a couple (say 50) patches in which case patches not clearly represented anymore and it's de-motivating to even look at the patch tracker, let alone individual patches.

In a voluntary project no-one is *required* to do anything with patches (or anything else for that matter) so, as Thomas says just putting them in a tracker isn't going to have them addressed, but, as Matthew argues at least developers know where to look for them.

The developers are interested in adding things they want or see are needed, and occasionally have a fit of conscience and try to apply some patches. Frankly feeling guilty or harrassed is a bad way of keeping developers motivated.

If the project is going to say patches welcome (tm) then there should be enough developers who agree to assess and apply patches (more than one to allow for breaks, by choice or forced). That needs people who have time and enough knowledge of Geany's code to put their hands up to Enrico and ask for the ability to do this, for example people who have submitted enough patches and demonstrated enough responsibility for the community to have confidence in them.

...

Of course, like you said, if nobody looks at it ever, it's still pretty useless.

Additionally, if the contributor is not motivated enough to bring up patches again and again then neither the maling list or patch tracker help. In this case it's simply the contributors fault.

Harsh and not terribly welcoming and motivating either, remember that people submitting patches are the projects best source of possible future developers to help spread the workload and thus improve the situation.

I'm sure that the current situation isn't deliberate on the part of the developers, just circumstances, Nick is MIA, Enrico has very little time, I have very little time etc. So again what it needs is for more people to volunteer who have shown that they have the experience and responsibility. The more people who each do a little bit the easier it is for all.

Cheers Lex

On Thu, 09 Jun 2011 19:40:26 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:

We made the following observation after years with a patch tracker. If core developers are rare or lack time or can't otherwise regularly look at the patches (which is the case for Geany too), [...]

Nothing will work in this case.

The problem is that a patch tracker creates the idea that once a patch is uploaded the project is responsible for them and not the contributor.

I wonder how. A serious patch is likely to break on ~100 svn revisions, and you must update it, to be able to use it yourself.

The way I see it is that a patch tracker will not work for Geany.

+1. But it's still better than the mailing list.