|
|
Home » Developing U++ » U++ Developers corner » Issue tracking...
|
Re: Issue tracking... [message #30757 is a reply to message #30756] |
Thu, 20 January 2011 16:23 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
don't want to start a flamin discussion git vs. fossil. haven't tried the latter.
thanks for the comparison. though, not all points, that seem 'negative' or 'disadvantage' are really such.
GIT in no way is to complicated. the problem is, that we are subversion-braindamaged and need a paradigm shift but thats true for all distributed vcs. so it depends on perception.
licence: GPL, doesnt bother us, since we wont change or reuse the source code, but use the tool.
separate web tools: we keep the choice 'what else' besides dvcs best fits our needs, which forum, which blog, which bug tracker.
multiple files: is definitely better. shorter load times etc..less mem consumption during run.
etc..everything is relative (to the needs)
|
|
|
Re: Issue tracking... [message #30761 is a reply to message #30756] |
Thu, 20 January 2011 16:51 |
|
fudadmin wrote on Thu, 20 January 2011 16:10 |
andreincx wrote on Wed, 19 January 2011 23:59 |
If i understand correctly fossil repo is one single file? SQLite DB? You have to run "open" command to map the file to a directory and "close" when you done - that doesn't worth the effort IMO fossil should exist only in museum.
Andrei
|
Then all databases are bad?
|
Databases are not bad, but VCS based on databases are bad (if they don't hide that dependency), i personally dislike monotone and now fossile maybe it's just me.
Andrei
|
|
|
Re: Issue tracking... [message #30928 is a reply to message #30619] |
Fri, 28 January 2011 14:28 |
|
Back to the topic of issue tracking
I am quite new to this, so I would like to make sure I get some things right. So my idea about typical flow of things is this:
1) Report a bug/task/feature. It's state is "New".
2) Someone makes a decision if the issue is worthed the work/necessary/good idea and sets it to "Approved".
3) Someone assigns the issue to themselves and starts working on it. The state changes to "In Progress".
4) Assigned person (optionally?) reports progress.
5) When it is ready, the issue state is changed to "Ready for QA" and is reassigned to someone responsible who checks if it is OK.
6) Issue is either "Closed" and changes committed or it is assigned back to the person who worked on it, to continue at step 4) with state "In Progress".
Few consecutive steps can be possibly merged.
Is that correct? Few things are still unclear to me, though in most cases the "common sense solution" is probably correct. Like who can approve an issue (can I approve issue I reported?) or who to ask for QA (Mirek in case of new features, original creator of changed code in other cases?). Are there any other rules we should follow?
Honza
|
|
|
Re: Issue tracking... [message #30951 is a reply to message #30928] |
Sat, 29 January 2011 16:30 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
off-topic:
I'd like to suggest to use buildbot for automated building and testing. It is a distributed system. A master process can run on the same server as redmine and build slaves can be run somewhere else. For example, I do not have any BSD system installed in my household, but somebody else might have it.
This is a quite useful system and I use it a lot at work.
Regards,
Novo
|
|
|
|
Re: Issue tracking... [message #30970 is a reply to message #30953] |
Sun, 30 January 2011 18:20 |
|
mirek wrote on Sat, 29 January 2011 20:35 |
dolik.rce wrote on Fri, 28 January 2011 08:28 | Back to the topic of issue tracking
I am quite new to this, so I would like to make sure I get some things right. So my idea about typical flow of things is this:
|
New -> Rejected (closed)
-> In progress (or just can stay New)
-> Ready for QA
(usually switched to reporter)
then reporter either Approved (closed) or returns it to New or In progress.
Quote: |
Like who can approve an issue (can I approve issue I reported?) or who to ask for QA (Mirek in case of new features, original creator of changed code in other cases?).
|
IME it is best when one that reported the issue approves it. Of course, not always possible.
E.g. in #19, the task to do is me to check the code and apply it to uppsrc. When I am done, I will switch it back to you for final check and approve.
Mirek
|
Ok, that clears it up for me, thanks Mirek. I was mystified about the Approved state - it just didn't occur to me that it means "approve the solution" (not "approve the issue"). My English is getting worse and worse over the time
Honza
|
|
|
Re: Issue tracking... [message #31000 is a reply to message #30619] |
Mon, 31 January 2011 16:25 |
|
One more question
I accidentally double-posted (issues 24&25) and found out that there is probably no way to delete/close one of them. Actually not even mark them as duplicate. Shouldn't users with developer status have right to close issues? Or are they closed automatically on Approve? But that wouldn't make sense in this case, as the bug is not approved yet, I just want to "hide it" somehow to prevent the same thing to be discussed in two places.
Honza
[Updated on: Mon, 31 January 2011 16:26] Report message to a moderator
|
|
|
|
Re: Issue tracking... [message #31007 is a reply to message #31005] |
Mon, 31 January 2011 19:46 |
|
mirek wrote on Mon, 31 January 2011 18:52 |
dolik.rce wrote on Mon, 31 January 2011 10:25 | One more question
I accidentally double-posted (issues 24&25) and found out that there is probably no way to delete/close one of them. Actually not even mark them as duplicate. Shouldn't users with developer status have right to close issues? Or are they closed automatically on Approve? But that wouldn't make sense in this case, as the bug is not approved yet, I just want to "hide it" somehow to prevent the same thing to be discussed in two places.
Honza
|
In such cases, "Rejected" is the right option, with possibly mentioning in the text that it is a duplicate of another issue.
(Or you can even add 'related' issue).
Note that such Reject is also appropriate in situation where e.g. new bug report duplicates some older one.
Mirek
|
Oups, I overlooked rejected. Does that close the issue too? Also, I didn't see an option to add related or duplicate issue anywhere...
Anyway, thanks a lot for your patience
Honza
|
|
|
Goto Forum:
Current Time: Sat Sep 21 04:04:58 CEST 2024
Total time taken to generate the page: 0.05975 seconds
|
|
|