=== j1mc is now known as _j1mc === _j1mc is now known as j1mc [20:13] mdke: I wrote to the lp team about managing bugs twice, see https://answers.launchpad.net/launchpad/+question/60937 [20:13] mdke: please amend/clarify as neccessary :) [22:16] dsas_, i think bugs need to be filed against both [22:16] ubuntu-docs is for the system documentation which is also available at help.ubuntu.com [22:17] ubuntu-doc team covers more, like the community docs [22:18] the ubuntu-doc team is the parent of the committers as well [22:18] it is confusing though :) [22:19] Rocket2DMn: Yes. there's 3 things there. [22:19] the ubuntu-docs ubuntu package, the ubuntu-doc team and the ubuntu-doc project [22:20] Rocket2DMn: The wiki bugs should probably be filed against a different/sub project that the ubuntu-doc team also looks after. or something. [22:21] Also there are various bugs the ubuntu-docs team should just be subscribed to... [22:22] well if the ubuntu-docs should be subscribed, then the bug should be filed under it [22:22] since it is a package which is installed on every ubuntu system [22:23] Rocket2DMn: Not neccessarily, [22:23] do you have an example? [22:23] if there's a bug we've introduced into the gnome2-user-guide for example. ubuntu-docs should probably be subscribed to it, but the bug belongs with the gnome-user-guide not with the ubuntu-docs project [22:24] Rocket2DMn: Though it doesn't currently work that way I think. [22:24] The bug gets filed against gnome2-user-guide and eventually one of may notice it. [22:24] do you have a link for such a bug? [22:24] no, it's hypothetical. [22:25] i dont really see how it affects anybody subscribed to ubuntu-docs if its not in the ubuntu-docs package [22:25] Rocket2DMn: because we make changes to that package too. [22:25] if a change is made elsewhere, like during packaging, then it is a problem with our implementation of that package [22:25] (like if we edit a man page) [22:26] that's literally a bug against the package, though its not one that travels upstream [22:26] Rocket2DMn: Yes. perhaps the ubuntu-doc team ought to be subscribed to such bugs in the gnome-user-guide package which the ubuntu-doc team do modify from time to time [22:28] from time to time huh? I think in that case they should be manually added to the subscriber list [22:28] Rocket2DMn: perhaps bug 201131 is an example of what I mean. [22:28] Launchpad bug 201131 in gnome-user-docs "Documentation for gnome-control-center does not mention PolicyKit" [Medium,Confirmed] https://launchpad.net/bugs/201131 [22:29] Rocket2DMn: that is the current workflow. individual members subscribe to those bugs (they usually get wrongly reported against ubuntu-docs in the first place!) [22:31] so the task is opened against Ubuntu Documentation [22:31] that seems correct to me [22:31] Rocket2DMn: it shouldn't be. It's not a bug in ubuntu documentation. it's a bug in the ubuntu package of gnome-user-docs that is handled by the doc team [22:34] "The Ubuntu Documentation Project (UDP) is a community-driven project that develops and maintains Ubuntu-specific documentation." [22:34] ah i see [22:36] i think its still appropriate [22:37] heh, ok. I guess we'll just have to agree to differ on that. [22:37] hehe, i think its easiest if you kinda ignore the ubuntu-doc team [22:37] that is to say, the project... [22:37] oh man [22:37] It still leaves the question that we have to manage the status of some bugs twice, or check in some locations twice. [22:38] ignore this - https://launchpad.net/~ubuntu-doc [22:38] Rocket2DMn: Perhaps. That still leaves the issue above though! [22:39] that should be "check two locations" not "check in some locations twice". [22:39] https://launchpad.net/ubuntu-doc is like an upstream for https://launchpad.net/ubuntu/+source/ubuntu-docs [22:39] so yes, you do have to check in 2 places :( [22:40] Rocket2DMn: Yep, that's the main thing I don't want to have to do. [22:40] heh, im not really sure there is any way around it. the latter is the actual ubuntu package that users would file bugs to, say, if they use apport [22:41] whereas the former is where code is maintained [22:41] Rocket2DMn: I couldn't think of anything either, that's why I asked the LP guys. [22:41] probably a bit of a long-shot :) [22:41] we're a bit of an edge case I imagine. [22:41] yeah, thanks for taking interest though [22:42] it's just that there isn't another upstream location, ubuntu-docs package upstream IS on launchpad as well [22:43] Yes, and the package is maintained by us. and our "Fix released" is when a new package gets released etc. [22:43] it's an artificial distinction that doesn't really help us. [22:44] Though I suppose there is an argument that the case of someone deriving from ubuntu is currently catered for. [22:44] not that I ever knew of a deriviative caring about the system docs [22:45] we can still use fix committed and fix released [22:45] if fixed code is in a bzr branch, then it's committed, if it's pushed to the package and placed in a repository, then its released [22:46] it is pretty trivial though [22:46] Rocket2DMn: yes. that's the same for the ubuntu package and the "upstream" development. [22:46] they both happen at the same time. [22:46] yeah, though there is some delay [22:47] we count fix committed for the upstream project and the source as when a fix is checked into bzr (this is similar to how the ubuntu-gnome desktop team work) [22:48] we count fix released for the upstream project when a new package is in the ubuntu repos, we count fix released for the packages when a new package is in the repos [22:48] yeah, i tend to think of Fix Comitted as Work is Complete and available for download somewhere [22:49] Fix Released means its in the ubuntu repos (for ubuntu-docs) or is merged with the main branch of the upstream code [22:49] Rocket2DMn: That's not how we manage that currently in our projet. [22:50] oh wait sorry I misread. Yes it is. the or bit is for normal programs [22:50] yeah i dont think i explained that very well [22:50] you get the idea though [22:51] yeah. it's probably because I'm having two conversations at once [22:51] thats ok im about to bump you down to one convo b/c im going afk [22:51] we'll see if matthew has anything to add, otherwise cheers :) [22:51] heh yeah, thanks for the discussion. [22:52] I'm going to get off soon myself