Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build/maintner: new empty milestones are not detected #25744

Open
FiloSottile opened this issue Jun 6, 2018 · 3 comments
Open

x/build/maintner: new empty milestones are not detected #25744

FiloSottile opened this issue Jun 6, 2018 · 3 comments

Comments

@FiloSottile
Copy link
Member

@FiloSottile FiloSottile commented Jun 6, 2018

A new milestone with no issues does not show up in the corpus.

(Also, don't mind me while I use this issue to prime the corpus.)

@gopherbot gopherbot added this to the Unreleased milestone Jun 6, 2018
@gopherbot gopherbot added the Builders label Jun 6, 2018
@FiloSottile FiloSottile modified the milestones: Unreleased, Go1.10.4, Go1.9.8 Jun 6, 2018
@dmitshur
Copy link
Member

@dmitshur dmitshur commented Sep 7, 2018

I ran into what I suspect to be a related issue while doing #26949.

A newly added GitHub repository with zero issues does not show up in the corpus. As soon as I created the first Pull Request (which counts as an issue), the repository showed up:

1. added "dl" to whitelist (CL x) and redeployed maintnerd
2. corpus.GitHub().Repo("golang", "dl") // nil
3. created first issue/PR in the repo https://github.com/golang/dl/pull/1
4. corpus.GitHub().Repo("golang", "dl") // non-nil

(Thanks @FiloSottile for reporting this issue; if I hadn't seen it, it would've been harder for me to debug what went wrong.)


To test this, I used maintserve. I also ran the following snippet:

package main

import (
	"context"
	"fmt"
	"log"

	"golang.org/x/build/maintner"
	"golang.org/x/build/maintner/godata"
)

func main() {
	corpus, err := godata.Get(context.Background())
	if err != nil {
		log.Fatalln(err)
	}
	num := make(map[string]int)
	for _, name := range []string{"example", "dl"} {
		repo := corpus.GitHub().Repo("golang", name)
		if repo == nil {
			continue
		}
		err = repo.ForeachIssue(func(gi *maintner.GitHubIssue) error {
			num[name]++
			return nil
		})
		if err != nil {
			log.Println(err)
		}
	}
	fmt.Println(num)
}

Before first PR:

map[example:11]

After first PR:

map[example:11 dl:1]

Edit: That said, I don't think this is necessarily a bad behavior that must be changed. Perhaps the right fix is documentation. I'd need to think through the trade-offs before making a decision.

@katiehockman katiehockman modified the milestones: Unreleased, Go1.11.2 Oct 1, 2018
@katiehockman
Copy link
Member

@katiehockman katiehockman commented Oct 2, 2018

After going through the latest Go release, I think this is indeed a bug. If a new, empty milestone is not picked up by the corpus, then the new milestone for the next release will be ignored. The current code will then require that some random issue is added to this future milestone in order to be picked up and allow the release to proceed. I also used this issue to prime the corpus as @FiloSottile did, but that feels like a bit of a hack.

@FiloSottile FiloSottile modified the milestones: Go1.10.8, Go1.11.5, Unreleased Dec 14, 2018
@julieqiu julieqiu modified the milestones: Unreleased, Go1.11.6, Go1.10.9 Jan 23, 2019
@dmitshur dmitshur modified the milestones: Unreleased, Go1.12.7, Go1.11.12 Jun 7, 2019
@dmitshur dmitshur removed this from the Go1.11.12 milestone Jun 7, 2019
@dmitshur dmitshur added this to the Unplanned milestone Sep 1, 2020
@dmitshur
Copy link
Member

@dmitshur dmitshur commented Sep 1, 2020

This issue is is needs decision state. By now, I think the decision is we should fix this issue if we find a safe way to incorporate explicit milestone creation/deletion events into the maintner data model, have an efficient way of extracting these events from the GitHub API, and ensure it won't increase rate of data written significantly (it should not). This is likely blocked on a resolution to #37603, and ideally addressed while taking into account the many other maintner issues.

I'll move it to needs investigation, since a decision is no longer blocking progress here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.