Excerpts from Dagobert Michelsen's message of Fri Feb 24 08:52:59 -0500 2012:
Hi Dago, > > When packages are stubbed out, the bugs are supposed to be moved > > to one of the other projects that obsoletes them. Is this not > > what's happening or am I misunderstanding the problem you've > > noticed? > > Correct, this is not happening. Please browse on the bugtracker > directly to samba by visiting https://www.opencsw.org/mantis/ and > then use the popup to select "samba_common". Then open the search > filter and set "Hide Status" to "none", then lots of bugs appear > which I closed yesterday. From your description I would have > expected that they would have been moved to "samba", as samba_common > was obsoleted by this one. Ok, I'm looking into this now. There are some heuristics applied here to determine where the bugs are moved. I do take into account the fact that once stub can pull in multiple other new packages. I don't actually see samba_common* in the catalog currently. Might it have been removed instead of stubbed out? That would line up with what I see in the db. > However, please note that a package may be obsoleted by more than > one package, so it may be best to just leave the bugs and > re-register the _stub packages. I tend to leave artifacts in the > view so they are clearly visible instead of applying different > levels of magic. The idea behind the current function is that dropped packages are hidden from view, leaving the bugs as is. It's a very simple change if people would like the removal of a package from the catalog to result in a no-op as far as mantis is concerned though. If we want to keep stubs in the db instead of moving the bugs to the new packages, that's a larger change. I don't mind doing this if it's the preferred behaviour though. In the case of stub handling, I attempt to move bugs to one of the packages in the dependency list of the stub using the following mechanism: 1. Remove CSWcommon from the list. 2. Reverse the dependency list to hopefully skim out automatically added things (CSWcas-*, etc). Some of these auto things could be moved to step 1. 3. Pick the first package. I see that there is some potential for more corner case bugs in this area though, so I'm looking at how to improve it... If we want to drop some of the rename detection for stub handling, many things can become simpler. In hindsight, this might be a better option for the web db...We could note the catalog name change in the database and preserve the dependencies. The _stub packages could then be filtered from the 'whole list' view but made available when clicking through from an individual package. If that sounds ok, I'll make the required changes. I think it might also be a good exercise to empty all of the package tables (in my test db) and start from a clean slate as if the original catalog was empty. The tables could then be imported to the webdb on www.opencsw.org. If anyone is putting real effort into making a nice package browser based on the buildfarm db though, let me know as I'd rather spend effort on that than polishing this turd if it's going to be replaced. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
