> I'm not sure it's a wise thing; the coupling between
> Tycho and Platform is huge
Then this is a problem independent of the used tracker/git host!
It's not a problem, it's how things are architectured. It's desired that way.
> That's nothing semantic, all textual conventions, it's really weak!
there are pros-and-cons for sure but one can also argue that most
developers today are more familiar with slim, agile and flexible
workflows than with traditional heavyweight central managed ones.
How are the workflows in GitHub slimmer or more agile? If I want to define a relation between issue, I have to edit add/edit a comment in one ticket of one project with a reference to the bug in another project. Editing a comment doesn't send a notification by the way; then I need to go on the other side of the issue and also add the textual _expression_ of this semantic relationship to the other issue as well; again probably without notifications if I edit things.
Then if one issue is closed, people watching the other ones are not notified so they don't know they can now fix their issue.
So overall, what you call slim actually require much more step, what you call agile is actually reducing the feedback loop by not sending notifications and is very error-prone, and what you call flexible is yet to be defined after years of using GitHub no project does it properly.
I'm aware of some teams that do mirror their public GitHub issues to Jira to enable some more serious project management, including relationship definition. The fact that people have a separate tool from the pubic tracker to actually organize their work tells a lot about how bad the tracker is.
I don't say its not worth or useful, but if we want to get faster and
more open I think a more relaxed development process could help to
attract new committers. Even though I'm using eclipse-bugzilla for years
now I'm not always sure what al those fields and options are meant for
and my impression is they lie often dormant.
Sure, people who don't know how to use those fields or don't want to use them can simply not use them; but still they are necessary for many people nd complex tasks IMO.
You will be able to look at them in GitHub/lab also
By scrolling down a few dozen of comments and re-reading multiple messages to find out the ones that are blockers, the ones that are dependents, the ones that are just mentioned more or less erroneously... That would basically replace a 30 seconds task (looking at related bugs that are already defined) by a 5 minutes task (re-reading everything). I do see only a loss here.
its just that you
won't need to manage them explicitly!
I do want to manage them explicitly. Everything else is just going to slow me down in my work.
Also referencing issues in commits
and get them linked to the issue automatically can be really nice.
Linked but without direction. That's too weak for complex task management.
IMO, GitHub tracker is not viable until it has a clear way of linking to blocks and dependents, with symetric updates and notifications.
