On Monday 06 November 2006 08:46, Maciej Sieczka wrote:
Hamish wrote:
> Maciej Sieczka wrote:
>>> PS: If I understand well -- patches should be submitted to Gforge in
>>> the future and not sent as the attachment to the grass-dev list,
>>> right?
>>
>> That's how I imagine this. Is that OK for devs?
>
> probaby depends on the size of the patch. For a few lines it's probably
> not worth the trouble of using the patch tracker. For larger patches and
> module submission it is more appropriate than sending 50kb emails to the
> entire list.
IMO, the main reason to use the tracker instead of sumbitting patches
just to the dev list is to keep the track of them :). So that we can
easilly access the patches that have been sent half a year ago, and
were ignored then, but now they could be usefull. For this, I believe,
any patch should be submitted by the user to the tracker, instead of
the list directly (the message will be forwarded to the list from the
tracker anyway). Once it is apllied (or used as a protype for another
patch), it's ticket should be closed.
I think it is good to track patches, even small ones.
Still there are situations where I would want to mail a patch to the list.
Especially when I am in a process of changing or discussing a change
or I know I will commit this tomorrow anyway.
Otherwise, at the end of a working session, it is good to publish something
and a tracker can help a lot to create a mini-discussion place
for a specific change.
> Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry
> that old scripts will be lost when people switch ISPs, jobs, graduate,
> etc.
We could have a separate tracker for this, or use the the GForge ftp
space (there is such thing).
Bernhard,
What is file size limit and the overall quota, in the tracker and the
ftp space? Better ideas?
There is no specific quota (yet) as disc space is reasonable cheap (though
backspace is not). We might introduce a quota in the future.
I am not quite sure that I know what "Wiki Add-ons scripts & modules"
precisly are, but if this is useful for GRASS to track and reaonably
seperate from other things. By all means: Track it.
You can use the documentation space or another svn module if
a tracker is not appropriate, so there are enough possibility to model
a solution.
Bernhard
--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)