=== daker_ is now known as daker [07:50] hi guys. finally getting round to looking at the cleansweep stuff. I made a list of package names that ubuntu-reviewers is subscribed too and how many patches exist for that project. http://pastebin.ubuntu.com/491431/ - this seem right? the next idea is to try work out where to apply the patches to the bzr branch. [09:38] stefanlsd, Which are you trying to accomplish? Most of what we do involves coordination with upstream, rather than direct application. [11:00] persia: ok, would be useful to clarify exactly if this could help. So my orig thinking was to take all the bugs with patches, determine from the patch where it applies (files / dates), and apply it. If it applies cleanly, that can be added to the bug that it does (later step might be to build), if it fails to apply, mark it as such... at least we can focus our efforts on patches that apply [11:01] Actually, that might help. The current guideline is for folks to try doing so first, and then try against wherever it's being sent upstream. [11:02] We could probably automate the first step, although I'm unsure if that raises the barrier for the second step. [11:07] persia: second step being forwarding upstream? [11:08] Possibly including minor patch mangling. [11:08] persia: my understanding is the patches we are getting / fixing will apply to ubuntu firstly, with potential that the patch does apply upstream [11:08] Ideally patches ought be minimally tested against upstream, but I don't know if everyone is doing that. [11:08] Depends on the patch. [11:09] So, in an ideal world, there would be an infinite number of infinitely qualified Ubuntu Developers with infinite time. [11:09] In such a world, every user-supplied patch can be effectively evaluated, discussed, applied to Ubuntu, and sent upstream via any number of channels. [11:10] Unfortunately, the number of patches added to LP exceeds the bandwidth of the developers to review/process them. [11:10] yeah, agreed. I dont think we have the resources for such [11:10] so my idea was to automate what we can, so that the time we do have we can at least focus on things that we know apply, know build, and perhaps 3rd step would be to generate a merge proposal [11:10] So this team attempts to help by grabbing the patches that haven't gotten attention from Ubuntu Developers, and getting them to the original authors, or failing that, Debian Developers to review/consider. [11:11] What you're describing could be useful for either team: making reviewing stuff easier for application to Ubuntu, or helping identify stuff that is better candidates for submission upstream. [11:12] But I think that if you develop it, you'll want to target one or the other workflow, as they diverge sharply once one gets past patch application. [11:12] If nothing else, this team doesn't care that much if the patch happens to be compatible with the other patches applied by Debian and Ubuntu: focusing mostly on the upstream code. [11:13] Does this team want to do the forward, or ask the submitter to please forward upstream? [11:14] for packages with vcs upstream info, we could potentially do this, but im not sure if there is a universal way to find and communicate with upstream [11:16] thats a bit ahead though, as a first step, i would like to patch against ubuntu bzr branch and see if it applies. tag it as such, or if it doesnt apply, let them know, ask them to recreate the patch if its still a problem, mark our ubuntu bug invalid [11:18] Generally the team forwards directly. [11:18] The assumption is that if the submitter has been ignored for a while, and was capable of taking action, they would have sent it somewhere else, or grabbed a dev or something. [11:26] ok. thanks. i think i should prob write a wiki page with the ideas and get some input [12:05] stefanlsd: Awesome idea :) === yofel_ is now known as yofel === daker_ is now known as daker