Re: [dev] GSoC 2010

I think this is a good project idea, and it would prove more than useful
also im looking forward to the simple port scanner, these project ideas
have caugth my attention.

On Wed, Mar 03, 2010 at 03:41:12PM +0100, Nicolai Waniek wrote:
> On 03/03/2010 02:46 PM, Peter John Hartman wrote:
> > I agree about the issue trackers + the mail integration. A small
> > suggestion: none of the issue/bug tracking systems do collaboration very
> > well either. What I mean by "collaboration" is the capacity to pass a
> > single document back and forth with several "notes" appended to it. a
> > giant
>
> You might think on a distributed bug-tracking system similar to a list of
> bug-reports inside a git system with the possibility to create new bugreports
> "on the fly" when the mail-server receives a specific mail (you somehow have to
> define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on).
> There should be a 'central' (though not required) bug-tracking server for all
> those coming with bugs on you project-website. there, the current bug list and
> state is a available and an interface to add new bugs. then you could place
> some sort of hooks into your bugtracker (bt) configuration:
> bt/.config/new -> send mail to mail-adress with new bug
> then you can manage bug-notification via mailing lists. For users that don't
> want to use the website, you could listen on mails in a specific form/with a
> specific header to pass it directly to bt parsing it. if the parsing fails,
> automagically send a mail back to the composer with annotation where it failed,
> if successfull, send back a success-mail.
>
> usage could be like (in a distributed way):
> $ cd bugs/projectname
> bugs/projectname $ bt pull # pulls all new bugreports from server
> 7 new bugreports
> bugs/projectname $
> 51 unresolved bugs
> 123 pending bugs
>
> where 'pending' means that their state is in "needs check if the bugfix works
> or not, waiting for approval" or something like that.
>
> If you want to make comments to a file, make them and afterwards a
> bugs/projectname $ bt commit -m "some annotation"
> bugs/projectname $ bt send # send new file to whole mailinglist
> bugs/projectname $ bt send some.user_AT_host.tld # send your changeset just to a
> specific user
>
> would do the rest.
>
> something like that. Didn't think too carefully on it.
>
Received on Wed Mar 03 2010 - 21:25:38 UTC