Polls

Default Game Speed

Log in to vote!

Currently Online

Latest Posts

Topic: Move Widelands to GitHub

hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 953
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-12-06, 16:40

Ok I'll make the references. How do we propose them for closing, review the proposal and close?


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 293
Ranking
Tribe Member
Location: Earth
Posted at: 2019-12-06, 16:50

hessenfarmer wrote:

Ok I'll make the references. How do we propose them for closing, review the proposal and close?

Maybe add them to the issue triage project if they aren't already.


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 953
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-12-06, 16:52

What about opening a seperate issue to hunt these issues down in the discussion we could add the number of the issue to be closed together with a mention to the preferred second reviewer which should lead to a mail to the person.


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 293
Ranking
Tribe Member
Location: Earth
Posted at: 2019-12-06, 16:57

Sounds good. Open a separate Issue and list them like this:

[] #1234
[] #1235

They will then appear in a checklist. Ans we can add a heck to issues already closed.


Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 953
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2019-12-07, 14:59

Ok I started the "collect" issue yesterday. However while scrolling through the issues I discovered a big difference to what we had on launchpad, which makes bugtracking different. and we should discuss how to handle this in github.
in Launchpad we had different stai for issues from new over triaged to in progress, fix comitted and closed.
on Git we have only open and closed
so we can't apply our old strategy to set fix commited if fixed in trunk and fix released when a new release has been pushed out
Furthermore I discovered that somebody had used the "good first issue" tag on some old issues which have already been fixed partly or even in total and we kept the bug open for some reason (f.e. the fix was not satisfying in every aspect)
According to the tooltips this tag is meant different on github. It means this issue isn't complicated to solve a beginner could start with this, so our tagging is confusing.
So we need a consistent bug management strategy how to tag and how and when to close issues.
we have to take into account githubs principles in this area for this.


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3073
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2020-01-03, 14:24

I assigned "Good First Issue" to bugs that had "lowhangingfruit" on Launchpad, but I didn't review their contents.

For issues that get closed without changing anything, we can assign the "wontfix" label.

I think for new issues, we should stick them into the "Issue Triage" project https://github.com/widelands/widelands/projects/2 - I already used that one heavily during the issue migration.

For reviewing older issues that can be closed, let's use "Hunting down old issues" https://github.com/widelands/widelands/issues/3607

Also, when merging a pull request, we need to make sure that we assign the current milestone.

When trying to find the commit that fixed something, I find git log > log.txt helpful, which then gives me a searchable text tile.


Busy indexing nil values

Top Quote