Some comments on Dennis' remarks.

Giel van Schijndel schreef:
> Dennis Schridde schreef:
>> Am Mittwoch, 9. Januar 2008 18:15:31 schrieb Per Inge Mathisen:
>>> On Jan 9, 2008 5:45 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
>>>>  * Change the bugtraq:* properties on the entire trunk directory tree to
>>>> use http://trac.wz2100.net as its bugtracker
>>> Please don't do stuff like this without discussing it here first.
>> Agreed.
>>
>> In case we want to keep this, the minimum requirement would be that all Gna 
>> bugs are copied to that Trac, so we don't loose anything.
>>
>> If we do that, the only thing left on Gna would be a SVN server (where the 
>> public one is usualy out of order) and a HTTP fileserver. (Where the SVN 
>> server is also already cloned on Mortis.) Well, and this ML, but that is 
>> probably minor.
>> I doubt that Mortis can handle the load of a full fileserver, though. No 
>> idea 
>> what would happen if everyone started using its SVN server...

Well connection wise (bandwidth and datalimit) I don't think there would
be much problems. Though I think we could better limit ourselves
(definitly at this moment) to providing a Trac project environment on
the dds.mortis.eu server (the server where trac.wz2100.net is hosted).


>> I think that spreading all that over dozens of places is not a really good 
>> idea, so we should decide what to do next.

If and when Kamaze decides that Trac hosting can take place on the
wz2100.net machine I will be happy to assist him in migrating/moving the
project environment to that server. Although I don't think Germany is
the best country lately to be hosting open source projects in. (Some
anti-cryptography laws seem to have been passed there if I've followed
the news correctly. And GPG signing is essentially cryptography, not to
mention SSL and SSH connection encryption...).

>> Personaly I like using a project-hoster, since they can always watch over it 
>> and should have the expertise to maintain it properly and without issues. 
>> (I.e. we have to maintain less.)
>> On the other hand Gna's public SVN is often down, Trac is nice, Gna's 
>> tracker 
>> has some limitations, and we could host additional services, like Git.
>>
>> Thus I did not decide finally what my opinion is, yet. It is a bit tricky.
> 
> Okay, I have indeed done this (i.e. telling GUI SVN clients to use
> trac.wz2100.net as its issue tracker) in the wrong order. So I'll try to
> continue doing it the "right" way.
> 
> Now:
> My proposal is setting up a Trac [1] project environment to use for
> tracking Warzone-related bugs/issues/defects, patches, tasks and feature
> requests. (The environment itself is set up already, see [2]) Some of
> the most important options/features this would offer us are, IMHO,
> automatic linking (i.e. through URLs) to revisions, tickets (Trac's name
> for a tracker item), wikipages, etc.
> 
> Trac allows wikiformatting almost everywhere (commit messages as well),
> which I personally think is much more convenient than Gna!'s custom
> markup-syntax. Additionally it is possible to actually preview things
> before posting them.
> 
> Tracking of individual tickets can be done quite effectively as it is
> possible to add custom queries to find, group and sort them. These lists
> can effectively be embedded in wikipages or defined as custom reports.
> Examples of the automatic ticket tracking for individual components can
> be found quite easily on TracHacks [3]. See for example the bottom of
> the DoxygenPlugin page [4]. I've done something similar for EditWorld on
> the Trac environment I've set up [5].
> 
> Then there is the ability to manage tickets through commit messages.
> This allows one to make Trac automatically add the commit message as a
> comment to the mentioned ticket, it optionally allows to close the
> tickets with the commit message. This way a tracked bug and its fixing
> (or addressing) revisions will automatically be linked together (in both
> directions, ticket <--> revision) which allows for easier searching of
> them. See [6] for the required formatting in a commit message (can
> easily be expanded if necessary).
> 
> Then lastly there's the option to make an IRC bot spam messages in
> #warzone on ticket creation (and optionally ticket updates) much like
> CIA does for commit messages right now. For this I use the IRC Announcer
> Plugin [7] for supybot. I've currently set up my bot to be more passive
> though. I.e. it allows querying of the Trac environment, just use "list
> trac" or "list tracbot" to see the commands it has available. For a more
> active example (of a "spamming" bot) see evil_twin in [EMAIL PROTECTED]
> 
> So please give notice of your opinion, ask any questions, etc. That is
> to say, I'd like to hear people's thoughts on this.
> 
> [1] http://trac.edgewall.org/
> [2] https://trac.wz2100.net/
> [3] http://trac-hacks.org/
> [4] http://trac-hacks.org/wiki/DoxygenPlugin#Defects
> [5] https://trac.wz2100.net/wiki/EditWorld#Defects
> [6]
> http://trac.edgewall.org/browser/tags/trac-0.10.3/contrib/trac-post-commit-hook#L47
> [7] http://trac-hacks.org/wiki/IrcAnnouncerPlugin
> [8] http://supybot.com/

-- 
Giel


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev

Reply via email to