Having personnally gone through some forking process, I think we should consider things calmly. Give them some time to react, maybe they're really overworked and don't have time to process this. Give them a date at which the fork will happen and keep an open mind: give them an honorable way to avoid the fork.
Also, the fork should support distributed versionning, otherwise the same issues could happen. Dspam is strongly source-oriented (e.g. it is recommended to compile your own rather than use binaries) so I would see fairly well having my own branch for my deployment, for example. Git, mercurial and SVK comes to mind. If hosted on Sourceforge, the only possibility is SVK because it plugs into Subversion, which sourceforge supports. Finally, some thoughts should be given on release engineering: how often to release? Who coordinates? Do we have milestones or just release when we feel like it / when all the bugs are closed? Etc... Having a wiki for this kind of crap helps a lot, and sourceforge now supports that too (was about time...). A.
signature.asc
Description: Digital signature
