Bugzilla – Full Text Bug Listing
| Summary: | Committers not moved to new parent | ||
|---|---|---|---|
| Product: | Community | Reporter: | Dani Megert <daniel_megert> |
| Component: | Project Management & Portal | Assignee: | Eclipse Management Organization <emo> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | markus.kell.r, tjwatson, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Dani Megert
(In reply to Dani Megert from comment #0) > The sub-project for Equinox got merged into Equinox via bug 488579, but the > merged committers do not appear under Equinox: > https://projects.eclipse.org/projects/rt/who (e.g. Markus Keller). I assume that you mean https://projects.eclipse.org/projects/rt.equinox/who There's a quirk in the way that information is propagated from the EF database to the PMI instances. The query looks for 'recent' changes (in the last month or so) based on changes in the active or inactive dates on the committer/project association table. Since these records were just moved, these dates weren't modified and the process didn't see them. Matt and I discussed maybe adding a 'last changed' timestamp column on the tables to make this more reliable. I've rerun the update script with the definition of 'recent' set to within 10,000 days; that should (and indeed did) get 'em. I think that it's fixed now. (In reply to Wayne Beaton from comment #1) > (In reply to Dani Megert from comment #0) > > The sub-project for Equinox got merged into Equinox via bug 488579, but the > > merged committers do not appear under Equinox: > > https://projects.eclipse.org/projects/rt/who (e.g. Markus Keller). > > I assume that you mean https://projects.eclipse.org/projects/rt.equinox/who Yep. > There's a quirk in the way that information is propagated from the EF > database to the PMI instances. The query looks for 'recent' changes (in the > last month or so) based on changes in the active or inactive dates on the > committer/project association table. Since these records were just moved, > these dates weren't modified and the process didn't see them. Matt and I > discussed maybe adding a 'last changed' timestamp column on the tables to > make this more reliable. Why not just kick it after a project structure change? > I think that it's fixed now. Yep. (In reply to Dani Megert from comment #2) > Why not just kick it after a project structure change? The challenge is that the database schema doesn't have a means of telling us what has changed outside of the active/inactive dates (which didn't actually change in this case). Without setting up additional infrastructure or adding further mechanical work to the webmaster process to handle these corner cases, the relatively expensive operation of just occasionally rebuilding all of the relationships is really the only way to catch them. Perhaps we should configure the cron to do a full rebuild periodically. (In reply to Wayne Beaton from comment #3) > the relatively expensive operation of just occasionally rebuilding > all of the relationships is really the only way to catch them. Right, so there is a way to do this. And given there aren't too many merges going on, why not just do that after the merge? (In reply to Dani Megert from comment #4) > (In reply to Wayne Beaton from comment #3) > > the relatively expensive operation of just occasionally rebuilding > > all of the relationships is really the only way to catch them. > > Right, so there is a way to do this. And given there aren't too many merges > going on, why not just do that after the merge? There are a few other corner cases that just rebuilding every once-in-a-while catches. But you're probably right. |