Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Issue tracking...
Re: Issue tracking... [message #30756 is a reply to message #30742] Thu, 20 January 2011 16:10 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
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 Smile IMO fossil should exist only in museum. Smile

Andrei


Then all databases are bad? Shocked
Re: Issue tracking... [message #30757 is a reply to message #30756] Thu, 20 January 2011 16:23 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile 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 Go to previous messageGo to next message
unknown user
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 Smile IMO fossil should exist only in museum. Smile

Andrei


Then all databases are bad? Shocked


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 Smile maybe it's just me.

Andrei
Re: Issue tracking... [message #30928 is a reply to message #30619] Fri, 28 January 2011 14:28 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Back to the topic of issue tracking Smile

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 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
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 #30953 is a reply to message #30928] Sat, 29 January 2011 20:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Fri, 28 January 2011 08:28

Back to the topic of issue tracking Smile

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
Re: Issue tracking... [message #30970 is a reply to message #30953] Sun, 30 January 2011 18:20 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Smile

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 Smile

Honza
Re: Issue tracking... [message #31000 is a reply to message #30619] Mon, 31 January 2011 16:25 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

One more question Smile

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 #31005 is a reply to message #31000] Mon, 31 January 2011 18:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
dolik.rce wrote on Mon, 31 January 2011 10:25

One more question Smile

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
Re: Issue tracking... [message #31007 is a reply to message #31005] Mon, 31 January 2011 19:46 Go to previous message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

mirek wrote on Mon, 31 January 2011 18:52

dolik.rce wrote on Mon, 31 January 2011 10:25

One more question Smile

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 Wink

Honza
Previous Topic: SSE2(/AVX) and alignment issues
Next Topic: Q: howto incorporate a native console window in GUI
Goto Forum:
  


Current Time: Fri Mar 29 11:38:24 CET 2024

Total time taken to generate the page: 0.01181 seconds