you are probably right and that is the way it is intended to work and that should scale well for "big packages", e.g. Libre Office, ...
On the other hand, there are over 300 open bugs against either Simple Scan itself or the Simple Scan Ubuntu package right now, and that is after I merged lots and lots of duplicates. There is currently one developer (Robert Ancell) and he has moved on to other priorities recently. So there is no chance these bugs are all properly cared for, even less so in a timely manner.
Having issues like this pop up twice is in my opinion bad, because it produces overhead in two ways:
- direct overhead: to fix it "upstream" first *and then additionally track the progress of the fix from upstream into the package* -- given the current situation, we should try to get some bugs fixed at all and not waste energy on something (in my opinion comparatively less important) like tracking way of the fix back into the package
- indirect overhead: having more and more issues show up in all list makes working with these lists slower, as these issues distract and/or make it harder to find the relevant issue
So I think technically you are right, but sticking to the letter of the law is in my opinion counterproductive in this case. However, this is not the place to discuss this. Let bug #896729 (just created before submitting this comment) be the place to discuss this further and lets work on that problem with the metadata here...
Hi Marcel,
you are probably right and that is the way it is intended to work and that should scale well for "big packages", e.g. Libre Office, ...
On the other hand, there are over 300 open bugs against either Simple Scan itself or the Simple Scan Ubuntu package right now, and that is after I merged lots and lots of duplicates. There is currently one developer (Robert Ancell) and he has moved on to other priorities recently. So there is no chance these bugs are all properly cared for, even less so in a timely manner.
Having issues like this pop up twice is in my opinion bad, because it produces overhead in two ways:
- direct overhead: to fix it "upstream" first *and then additionally track the progress of the fix from upstream into the package* -- given the current situation, we should try to get some bugs fixed at all and not waste energy on something (in my opinion comparatively less important) like tracking way of the fix back into the package
- indirect overhead: having more and more issues show up in all list makes working with these lists slower, as these issues distract and/or make it harder to find the relevant issue
So I think technically you are right, but sticking to the letter of the law is in my opinion counterproductive in this case. However, this is not the place to discuss this. Let bug #896729 (just created before submitting this comment) be the place to discuss this further and lets work on that problem with the metadata here...
Best Regards
Michael