... or find a similar appropriate solution. This is a spin off from "Bug 60766 - BUGZILLA: Remove Android Impress Remote Versions". We should discuss here what exactly we want to do, and if it's a new Product (may be additionally new OS?) we can shift it to Tollef and ask him to proceed. Currently I am a little doubtful that an own Component is really necessary and appropriate: a) do we have enough Bugs? I don't think that we need something like that if we do not get at least 60 Bugs /year (1/week) Currently we've got 9 reported between 2012-12-14 ... 2013-02-27 a1) An how (if) will be divide that into Sub components? b) do we need something so specific? What's with an iPhone / blackberry remote? May be we will get other LibO-Related, but not LibO tools (Like Florians GUI installer ...). A solution would look like Component: LibO-Tools Sub Compo: ImpressRemoteControl (We would ask for 2 new OS) Sub Compo: Deployment Tools Sub Compo: ?1 Sub Compo: ?2 If B we would get back the version problem we currently have with Product LibO c) May be we worry other users with a separate product. Is it LibO or is it not? And BSA might become more complicated d) My suggestion: d1) We leave the current LibO Component (or may be only Impress Remote Control, see below?) d3) We think about Sub components (may be Android, iPhone, ...) d4) In Bugzilla Component text and BSA we ask reporter to add his Version so that a bug looks like Product: LibO Component: Impress Remote Control Sub.Comp: Android -> Summary: "Android V1.0.2: Automatic silent profile smartphone to " start a slideshow d5) Existing bugs will be amended, Versions deleted, and BSA would work without bigger work
I'll think on this, I also think it's unnecessary and add more work to those of us maintaining FDO & BSA for no real payoff...
(In reply to comment #0) > > Currently I am a little doubtful that an own Component is really necessary > and appropriate: A fair question > a) do we have enough Bugs? I don't think that we need something like that > if we do not get at least 60 Bugs /year (1/week) > Currently we've got 9 reported between 2012-12-14 ... 2013-02-27 I'm not sure that the total # of reported bugs should be our deciding metric. In my mind, the primary consideration is: How easy is it for users to interact with our infrastructure? That of course includes: Ordinary Users, Devs, QA, etc... > b) do we need something so specific? What's with an iPhone / blackberry > remote? > May be we will get other LibO-Related, but not LibO tools (Like Florians > GUI installer ...). A solution would look like > Component: LibO-Tools > Sub Compo: ImpressRemoteControl (We would ask for 2 new OS) > Sub Compo: Deployment Tools > Sub Compo: ?1 > Sub Compo: ?2 This sounds like we're trying to shoehorn multiple different projects into a single Bugzilla project, and it sounds very confusing to me. I'm not sure that such a setup is going to be easier for an Ordinary User or for us. > c) May be we worry other users with a separate product. Is it LibO or is it > not? Technically speaking, the AIR is not LibreOffice. We might keep it in the tree with other LibreOffice code, but it's a separate application that doesn't provide any of the functionality of LO. > And BSA might become more complicated I think that the BSA is going to get more complicated either way: We're creating more functionality on more platforms, which means that we have more moving parts to take care of. ---- My suggestion: Make a new project called "LibreOffice - Impress Remote". For now, it'll just have a single OS (Android). If/when we get a port of this code running on iOS, BlackBerryOS (?), or other platforms, we add new OSes to the Platform drop-down list.
(In reply to comment #1) > I'll think on this, I also think it's unnecessary and add more work to those > of us maintaining FDO & BSA for no real payoff... How much additional work would it be to maintain a separate project in Bugzilla? For the BSA, I figured that we would just have a page on which we list an icon for each of our projects, so (for now) two big icons -- click on the Android tablet/phone icon on the left for AIR, and click on the computer on the right for the LibreOffice suite.
wouldn't be easier to create an AIR meta-bug inside LibO bugtracker?
(In reply to comment #4) > wouldn't be easier to create an AIR meta-bug inside LibO bugtracker? I think of a meta-bug as a bug to track a set of bugs or to group together a bunch of related bugs like MABs. In this case, the AIR bugs would apply to a single piece of software, but it's a separate piece of software from LibreOffice. I'm not too familiar with the Android and iOS remote, but I assume that with some minor abstraction the same software could be used to connect to AOO or other presentation programs.
I see that "Android Impress Remote" is indicated in the component menu. It looks me a good solution to filter "AIR" bugs from other LibO bugs. My 2 cents are that actually there's no need to create a separate Bugzilla project for AIR as requested by Reiner. setting status to NEW anyway.
Task for me to complete after we migrate Bugzilla
(In reply to Robinson Tryon (qubit) from comment #7) > Task for me to complete after we migrate Bugzilla DONE -- see https://bugs.documentfoundation.org/describecomponents.cgi?product=Impress%20Remote