Hi, because new ebuilds now will get the status RESOLVED LATER, I think it would be a good idea to include such bugs in the default query of bugzilla. Otherwise already submitted ebuilds won't be found with the default search. Just my 2 cents ;) Regards, Alexander
after the code freeze i was going to go back and re-open them a few of those ebuilds were mine so i plan on making sure they get seen ;)
Hmm, why you have changed this bug to resolved later?
because imho the default query should only show bugs that are open
Hmm, then the status resolved later for new but queued ebuilds is choosen bad. Anywhere I think already submitted ebuilds should be seen (by the default query or e.g. with "My bugs") until there are really resolved.
the chosen status is most appropriate considering the system that is being used a new system is being designed to handle the submission of new ebuilds, but until that system is complete, gentoo has bugzilla. the reason for the 'RESOLVED LATER' status is so that developers who are trying to minimize the # of open bugs for the upcoming release dont have to see these enhancements. so, your default query would still show them completely negating the intended affect. the idea of a 'resolution' do it 'LATER' is exactly that. there are no plans to punt these new ebuilds, but rather, after the 1.4 release, they will all be looked at by the appropriate developer and then have their 'resolution' changed to either 'FIXED' (added to portage) or 'WONT FIX' (ebuild is deemed not worthy to be added to portage) does this clear up the situation for you ?
The situation is clear. I just wanted to prevent that more than one ebuild for a prg is submitted. E.g. if I need some soft for which I didn't found an ebuild in the portage I do a (default) search, before I start writing the ebuild (I don't like writing ebuilds ;)). Ok, now _I_ know I have to include resolved bugs into the search. Maybe an announcement about the freeze with an explaining about the status "resolved later" would be good.
Since there is no more freeze, and the RESOLVE:LATER resolution is implemented, I am going to close this. Maybe there should be something in the policy about submitting ebuilds and making their default stats RESOLVED:LATER? //ZhEN
