Home » Developing U++ » U++ Developers corner » Issue tracking...
|
|
| Re: Issue tracking... [message #30620 is a reply to message #30619] |
Wed, 12 January 2011 21:14   |
|
|
It would clean up the forum a bit... Why not the tracker that already exists on sf.net? Only reason I can see is that it is not on ultimatepp.org (maybe that might be fixed with a little work).
Honza
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Issue tracking... [message #30645 is a reply to message #30638] |
Thu, 13 January 2011 11:57 |
|
|
Issue tracking is generally a good idea. But I don't need it too much now so if that would speed up developing rainbow project it can be written in upp for me 
|
|
|
|
| Re: Issue tracking... [message #30650 is a reply to message #30624] |
Thu, 13 January 2011 15:31 |
|
|
| mirek wrote on Wed, 12 January 2011 22:35 |
And to sum it up, I was also considering issue tracking as nice case-study for U++ based web development:)
|
I agree with you to make U++ based web development.
I planning to create an issue tracking, integrated with GIT repository (or SVN). Based on web and windows forms.
Web forms i planning to add with v8cgi.
Finally, I can contribute in this project!
|
|
|
|
|
|
| Re: Issue tracking... [message #30661 is a reply to message #30653] |
Fri, 14 January 2011 17:06 |
|
|
| mirek wrote on Thu, 13 January 2011 20:17 |
| unodgs wrote on Thu, 13 January 2011 05:57 |
Issue tracking is generally a good idea. But I don't need it too much now so if that would speed up developing rainbow project it can be written in upp for me
|
Well, that 'rainbow' thing is primarily intended to speed up MacOSX/Android/framebuffer ports. Using it for TS-like server was just additional idea; I am afraid that in the end we should support 'proper' web development as well...
|
I do not know details 'rainbow'.
Will be exists possibility to:
1. change source code runtime (like in PHP or v8cgi)
This rainbow will not overload the system for more quantity of users?
|
|
|
|
| Re: Issue tracking... [message #30662 is a reply to message #30619] |
Fri, 14 January 2011 20:08 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
PHP can't change code dynamically.
Well, it can by calling "eval()", but that's not used.
(anyway, self modifying code was common practice back in past, and it died for quite a valid reasons  )
What you probably have on mind is simple deployment of new changes, but that's just implementation detail and can be solved up to some degree even with C++, and also for larger projects this is absolutely non issue, because you definitely don't want your project to just change suddenly, that requires much more planning and strategy with large projects to keep the app running without inconsistencies and noticeable downtime.
If you want just to do some small page and experiment a lot, PHP is excellent choice and I don't see a reason to compete with it in such case.
Rainbow project is anyway almost completely unrelated to web development, except the ability to run more of U++ core in server environment without GUI and with smaller platform dependency, so porting and maintaining will be simpler.
[Updated on: Fri, 14 January 2011 20:08] Report message to a moderator |
|
|
|
|
|
| Re: Issue tracking... [message #30741 is a reply to message #30619] |
Wed, 19 January 2011 22:49 |
harmac
Messages: 16
Registered: January 2011
|
Promising Member |
|
|
When thinking about improvements for development, it might also be a good idea to consider changing to a distributed version control system. There has already been some discussion about that in the coffee corner. I think, I should go there later and also add something to the discussion, as I've recently read about a couple of systems around of which Bazaar and Fossil looked the most promising to me.
Speaking of the latter, it has some unique features and its being BSD licensed might also be worth taking a look on it, as you mentioned having considered issue tracking as a case study for U++ web development (what exactly does that mean, did you think of writing an issue tracker?). In particular, it is self-contained and integrates bug tracking and a wiki for documentation with its version control that allows for distributed working. So, if I've read that correctly, you can for example write offline in the wiki and commit changes locally and push them later to a central repository the same way as you'd do it with code when using the system with autosync off. While a GUI is missing, which I consider a weakness, the author argues that it is not necessary, because there's a web interface.
Otherwise, I'd suggest not to use sourceforge, because I have the impression that the site loads annoyingly slowly when compared to googlecode, which might be the best choice among third party web hosted trackers.
Are there any specific requirements for functionality that shouldn't be missing?
|
|
|
|
| Re: Issue tracking... [message #30742 is a reply to message #30741] |
Thu, 20 January 2011 00:59 |
|
|
| harmac wrote on Wed, 19 January 2011 22:49 |
When thinking about improvements for development, it might also be a good idea to consider changing to a distributed version control system. There has already been some discussion about that in the coffee corner. I think, I should go there later and also add something to the discussion, as I've recently read about a couple of systems around of which Bazaar and Fossil looked the most promising to me.
|
Off-topic:
IMO git fit better with U++ design. One can checkout a branch (change from one branch to other) in same directory so there is no need to add new assembly to TheIde, only reload the files (which TheIde already do) - one reason why i use git with U++.
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. 
Bazaar is ok (a bit slow), but it can't have branches to share same directory (AFAIK), and switch from one to another.
Andrei
|
|
|
|
| Re: Issue tracking... [message #30744 is a reply to message #30742] |
Thu, 20 January 2011 09:34 |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
glad to see things going this direction..
| Quote: |
When thinking about improvements for development, it might also be a good idea to consider changing to a distributed version control system.
|
totally agree with it. this makes developping things really smooth. and cleans up the forum. otoh, having code examples and 'geek upp terminology' (things beginners wouldnt first search for in upp/and help forum) really helps the learning process.. so totally dismiss them (issue threads) there would probably make learning for the 'others' (non-developers) more difficult.
in terms of bug tracking: i'd suggest to use a BT that can be integrated with the version control of choice (see coffe corner: GIT). so i'd suggest 'mantis' which might not seem too fancy but is just the right choice for most things, and has GIT integration plugins.
but some research revealed: Redmine is just as potent for integrating GIT. and it looks better
so, for mireks sake, i'd suggest to switch over to Redmine/GIT.
(for git, all version history from svn can be imported, i'm having running a git mirror from upp locally, and someone is running a public one as well, Mindtraveller, right?). this would speed up migrating (just pass over a rar file).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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: 1431
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: Tue Apr 28 07:09:38 GMT+2 2026
Total time taken to generate the page: 0.01111 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
)
