Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] Move to Github / Bugzilla, MediaWiki and Git/Gerrit deprecated in early 2021 
Github is more focused on fixing issues rather than managing them ;-)
And I think there is no choice to go wit Atlassian tool suite anyways so I think its a bit out of scope. Anyways github has recently added support for project management also, so things are changing every day...
May projects on https://github.com/eclipse use github also for issues so maybe its more valuable to ask some of them how they managed it to work.
All I wanted was to suggest we better now think about alternatives and how to proceed before it cannot be postponed anymore... 


Am 18.12.20 um 09:57 schrieb Mickael Istria:
On Fri, Dec 18, 2020 at 9:31 AM Christoph Läubrich <laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote: 

      > 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. 



_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-dev

Back to the top