Comments on: Github issues for issues, not bug reports
Curecode stores R3 bug reports and enhancement requests.
Github issues area stores problems with builds, pulls, merges, branches, etc.
In other words we're not using Github issues for bug reports, only for repository/branch problems.
Only copy an item from Curecode to Github if:
- you fixed it and need to discuss it
- the matter needs urgent attention
Thanks.
9 Comments Comments:
Brian Hawley
14-Dec-2012 20:10:14 |
I'll copy the issue-request I posted already over to CureCode. All of Meijeru's issues were copies from CureCode, so they don't need to be copied back, though I'll transfer any useful comments to their relevant CC tickets.
I'll miss the Rebol highlighting. Somewhat ironically, Github supports Rebol highlighting better in bug reports than CureCode does. Room for improvement, I guess. Still, in the issue system I missed the ability for admins to clean up the language of a submission so that it could be of more value to the developers assigned to implement the fixes. CC may be better for us in the long run.
We should work on the CureCode/Github integration. Both have APIs, so we should be able to write a little glue. It can even be submitted as an official Github project plugin, for other projects that want to use CC as well.
One serious concern we have run into in the last couple days is a bit of a mismatch between the development model that CC is set for, and the development model of open-source R3. CC doesn't yet have a ticket state for the case of a fix waiting to be pulled into your repo, or a state for the fix having been accepted into your repo, but not yet incorporated into an official build. We need to make some tweaks to resolve this process mismatch.
For that matter, we could use official builds. Make a branch for each official version, so that someone can switch to that branch if they need to be compatible with a specific set of functionality. Make prebuilt binaries available for download based on each official version. That way user scripts don't have to keep up with a moving target.
We've been doing pretty well so far, hitting the ground running. Things are looking up! | Andreas
15-Dec-2012 17:14:45 |
I think it's better to disable the Github issues again, for now. Otherwise, this will distract us many times.
For discussing a fix, this can still be done within the pull request on Github.
Note that I can still see us fully switching over to Github issues eventually. But we're certainly not there, yet, and for now it's rather annoying to have two separate issue trackers. | AdrianS
16-Dec-2012 0:36:17 |
There should be a link to CureCode on the main GitHub project page, no? | MaxV
18-Dec-2012 4:16:05 |
I copied Carl post to Github wiki, but I'm afraid to divide resource.
My humble opinion is to use only Github. If you are invaded of emails, you can disable them from project settings just for R3. Github gives possibility to tag as (right menu):
- bug
- duplicate
- enhancement
- invalid
- question
- wontfix
You can assign issues to someone to resolve. I think that it's better to mantain all on one single site as much as possible.
Carl himself could just read issues connecting to github site when he has time to do, without receiving tons of requests. | Brian Hawley
18-Dec-2012 12:40:35 |
Max, that would sound like a good idea going forward, but the problem is that we have already used CureCode for years and there's a lot of project history in there already. Switching to Github for everything means having our existing processes basically stop working. There's even a lot of useful information in CC tickets and comments, some of which was written by people without Github accounts yet. The info in CC is not "old" information from the "old" project, it's current information about the current project.
If we were to switch to Github for everything and not lose all of our context, it would be a bit of a task. We would have to import 1875 tickets and countless thousands of comments under the names of the Github accounts corresponding to the CC users (you can import stuff on behalf of other people, without clearing every post with the other people, such that it looks like the other people posted it themselves, right?), backdated to the original ticket/comment dates (you can post issues from before Github existed, right?). And that is just that would be required to catch us up with the status quo.
As it is, not everyone in the community wants to have Github accounts - some have objected to this explicitly. Some recent blogs have suggested workarounds for that.
In the long run better Github integration would probably be a good thing. In the short run let's not throw away our existing processes, especially while they're actively being used. | MaxV
19-Dec-2012 1:40 |
I'm not a GitHub fan, but source code is on GitHub and common people automatically will use GitHub. I copied this post on GitHub wiki, but I don't think people will read it.
Moreover even CureCode requires to register and log in, so where is the difference?
I think that everything will automatically move to GiTHub, so be prepared. | MaxV
19-Dec-2012 2:15:20 |
Don't do the same errors of Rebol 2, where there was a wall between people and reboltech. | shadwolf
27-Dec-2012 7:02:26 |
ticket triming dedicated forum is created.
Preferably french debats will be attended there but not exclusively.
Our way to work is
1) set up a proper SDK you can use and set up (with a documentation adapted to r3) on any main OS
2) identify tickets that we can treat
3) start finding solution for those bug through open talks.
4) propose to curecode the code that solve it... I don t want to make a github branch in order to retro feeback and share the changes ... all discussions will be done throught the forum. Conclusion will be given to CureCode.org for each ticket.
This let the people in charge of the integration of bug fix if they don sleep tightly the luxury to see the proposal invent eventually a derivated fix that will be more convenient based on the fix proposed by us.
| pep
11-Jan-2013 1:44:58 |
maybe it's just too late for this comment but a good lightweight and tiny alternative for git is fossil and also you have an alternative to hithub such as http://chiselapp.com/ or http://fossilrepos.sourceforge.net/ |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
