FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Trac practices

 
Post new topic   Reply to topic     Forum Index -> DDL - D Dynamic Libraries
View previous topic :: View next topic  
Author Message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Fri Jan 13, 2006 7:40 am    Post subject: Trac practices Reply with quote

As the project progress, we'll hopefully get a lot of users, which in turn most likely will lead to lots of bug reports on a highly technical and very low level. I think we should prepare Smile

* The first point is getting good bug reports. I am thinking that maybe we should put some boiler plate text into some DDL exception classes, something like (if it's an ELF exception):

"You have run into a condition not handled, or possibly incorrectly handled, by DDL. $Insert some text provided by the code throwing the exception$ Please create a ticket (or look for similar ones) at http://trac.dsource.org/projects/ddl/newticket, explain the circumstances and paste this message into it. Also, if possible, please attach a minimal, reproducible testcase.

If you were trying to load an ELF object file, please also provide the object file and/or the output of 'readelf elfobject.o'"

Some refinements, and we would have a real headstart on those bugs.

* The second point would be to use Trac for all it's worth. For example, Brad can install a simple script which will hook into svn commit messages, parse them and do some Trac magic if the correct command is present. For example would the command

<code>svn commit somefile.d -m 'Added function this and that, closes #13 and refs #18' </code>

automatically close ticket number 13, and create a comment in ticket 18, both with a link to the changeset. And thus we as developers are fairly certain that if a ticket is closed, there is referencable code in the repository that justifies that the ticket is closed. This might lead to more, but smaller commits, btw.

When we get further along, I also think that svn features like branches should be used more. If you look at the edgewall trac (the one for Trac itself), you see that in their roadmap, they link to different branches that are to be merged at different stages. In this way they are also able to get the commits for that branch only, giving them exact change logs for each branch, accessible through a relatively easy link, especially useful for stable branches with bugfixes only (and if the commit messages then has a link to the ticket it closes, you got the whole process documented).

Well, at least a few ideas here, some thoughts? Do anyone bother to keep up with such a regime? Wink
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Fri Jan 13, 2006 7:58 am    Post subject: Re: Trac practices Reply with quote

Awesome input Lars, and right on all points. I say we do just this. Smile

larsivi wrote:
* The second point would be to use Trac for all it's worth. For example, Brad can install a simple script which will hook into svn commit messages, parse them and do some Trac magic if the correct command is present. For example would the command

<code>svn commit somefile.d -m 'Added function this and that, closes #13 and refs #18' </code>

automatically close ticket number 13, and create a comment in ticket 18, both with a link to the changeset. And thus we as developers are fairly certain that if a ticket is closed, there is referencable code in the repository that justifies that the ticket is closed. This might lead to more, but smaller commits, btw.


That could certainly help - it all comes down to how you want to work. Personally, I tend to groom the tickets from time to time and close this, comment here, open that... depending on what's going on. Correlating a ticket with a commit can help though, and I will try to get into the habit of putting the changeset number in my tickets from here on (and vice versa).

Quote:

When we get further along, I also think that svn features like branches should be used more. If you look at the edgewall trac (the one for Trac itself), you see that in their roadmap, they link to different branches that are to be merged at different stages. In this way they are also able to get the commits for that branch only, giving them exact change logs for each branch, accessible through a relatively easy link, especially useful for stable branches with bugfixes only (and if the commit messages then has a link to the ticket it closes, you got the whole process documented).


I'm kicking myself for not doing it earlier, but I was about 8 changesets along after 1.0b before I realized that I should have placed a branch out there. On the upside, the library is in beta, so support of intermediate renditions would probably have just slowed things down. Since the next milestone is going to be *very* usable, I don't see why we can't get this into practice now.

So in review:

- (coding) add *verbose* exception messages to code, encouraging users to report bugs via Trac.
- Annotate changesets with relevant ticket numbers
- Branch the codebase at each milestone


I'd also like to advocate some things I've already been doing, since they've been pretty helpful with keeping things organized.

- Add a ticket for each research task and link to the relevant forum if possible.
- Add a ticket for each bug and avoid wholesale bug reports if possible
- Inform people when their tickets are closed (pm, email, whatever)
- If a ticket is being worked collaboratively in the forum, link to the forum in the ticket.

FYI, When I get a more complete framework up for the documentation, we can discuss how to best use the wiki too.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Fri Jan 13, 2006 8:11 am    Post subject: Re: Trac practices Reply with quote

pragma wrote:

- Inform people when their tickets are closed (pm, email, whatever)


Note that there is a CC field in the tickets, works just like you want for emails Smile Maybe PM's can be added when Brad's Trac forum takes shape. I'll create a ticket at the dsource project.

I'll also notify Brad about adding the commit-hook-script.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DDL - D Dynamic Libraries All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group