| View previous topic :: View next topic |
| Author |
Message |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
 Posted: Sun Jun 08, 2014 11:16 am Post subject: Bugzilla is a mess |
 |
|
If you assign a bug in bugzilla to the proper group/person, you get no result ; you're bug will not even be confirm.
Result is that if you want any success with your bug in bugzilla, you better not assign it to who it should in order to get it assign to bug-wranglers.
That's pretty stupid, as bug-wranglers will manage your bug and assign it finally to where it should ; so it higher human needs.
All my bugs that were assign to bug-wranglers find their path to a resolution (yeah close/won't fix... is a resolution), while i have two open bugs that were directly assign to the proper group that are just dead ; and one i'm watching that face the same fade.
Everyone would answer : understaff, but assign a bug to bug-wranglers is eating more staff power. It seems the result is just better and your understaff team this time, handle it.
Difficulty of the bug : one of the bug is a file change to revert to its previous state (that's so easy anyone can do it). Another one can be confirm by any users using openrc that might this time need some code (but a few) to fix it, but to test it you just need openrc.
For me it looks more like some poor thinking of our devs (an indirect result of understaff): if user assign bug to me, i don't care user sucks, if i get assign by bug-wranglers, i should have a look at it as it's serious.
Anyone sharing that feeling? |
|
| Back to top |
|
 |
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 08, 2014 1:27 pm Post subject: |
|
|
| Which bugs is this about? As a developer I feel that there is not much difference between resolving bugs assigned by users and those assigned by bug wranglers; the only difference to me, is that directly filed bugs sometimes provide less information. Bugs that go through bug wranglers get checked for build.log, config.log, `emerge --info`, properly attached attachments, useful summary (for listing and searching), backtraces, dmesg output, .config file and things like that. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Jun 08, 2014 2:14 pm Post subject: |
|
|
https://bugs.gentoo.org/show_bug.cgi?id=508238
openttd 1.4 and 1.4.1 ebuild works well just reusing previous ebuild, user didn't post the ebuild, but i'm not sure it really lack infos.
Not even confirm, well it's easy to see anyone asking bump generally ask a bump on something that exist, and it's easy to check if that version exist or not.
Link to it, https://bugs.gentoo.org/show_bug.cgi?id=492876 that is CVE for old version is not close yet (even safe version was stabilize)
https://bugs.gentoo.org/show_bug.cgi?id=510036
This is the so easy one, revert a file back to its previous state, this is awesome because if dev doesn't agree, it will be mark won'tfix and if he agree, the file is just revert to previous state. So it can be resolve in what 1s as wontfix or 3s with file revert.
That's a real easy one and still see date.
https://bugs.gentoo.org/show_bug.cgi?id=510636
Less easier as it need code to fix, but seriously anyone can easy "CONFIRM" it as you can reproduce it so fast & easy.
But those are samples, plenty others exists, it's just ones i'm watching.
So, something is wrong at handling bugzilla. The user/group are autoassign by bugzilla when you properly fill the bug, while using a generic "i dont know what this bug is and where and who should look at it" result in better result than trying to make the bug route to who it should. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Jun 10, 2014 5:24 am Post subject: |
|
|
| krinn wrote: | https://bugs.gentoo.org/show_bug.cgi?id=510636
Less easier as it need code to fix, but seriously anyone can easy "CONFIRM" it as you can reproduce it so fast & easy. |
Patched (trivial).
| Quote: | But those are samples, plenty others exists, it's just ones i'm watching.
So, something is wrong at handling bugzilla. The user/group are autoassign by bugzilla when you properly fill the bug, while using a generic "i dont know what this bug is and where and who should look at it" result in better result than trying to make the bug route to who it should. |
That's not right, then, as users doing the work should get equally good results, if not better, or they'll stop doing the work. Perhaps there needs to be a big fat reminder about the list TomWij outlined when you assign a bug yourself. |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Tue Jun 10, 2014 10:55 pm Post subject: |
|
|
yes, bugzilla sucks
We need a proper review platform which is fun to use. This is the difference between "oh cool, might just give this a quick review" and "oh noes, have to open the file (sometimes tared, compressed or just both), reference lines manually and make a list what is wrong with it". Then there is no automatic repoman check etc. All steps I have to do. Even if the ebuild supposedly just needs a rename, I calculate ~30min for a simple bump.
* rename the ebuild
* fetch sources
* run repoman
* try to build with gcc
* try to build with clang
* try to build with gold linker
* check if QA is still in place (CC, CFLAGS, LDFLAGS etc respected?)... as in: read the build log (yes, I do)
* for games I also have to check whether the games variables are respected... that only works if I actually change them (/usr/share/games is sometimes even hardcoded, so it looks like it works, when it does not in fact)
* when there are reverse deps... give them a quick rebuild
* build with some random use flag permutations
* EDIT: almost forgot... check if the user is actually correct about "only needs a rename"  ...most of the time, it's just not true (new dependencies and whatnot)
and... you will still miss something (maybe it got relicensed?)
Also mind that there are max ~3 people actively working on games ebuilds. I stopped blaming people for not becoming gentoo devs... but yeah. You'll have to lower your expectations. That is the sad truth. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Jun 11, 2014 5:26 am Post subject: |
|
|
Thanks for the example hasufell, like i said, instead of looking at what users have done ; you just ignore it... 1.4.2 will be out before the 1.4 ebuild even hit ~ for sure.
I didn't stopped blaming dev that cry for staff and ignore any help gave to them... I don't think i need to lower my expectations, they are low already. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Wed Jun 11, 2014 10:59 am Post subject: |
|
|
| hasufell wrote: | | yes, bugzilla sucks |
It is rather good at what its purpose is, reporting and tracking bugs; all the rest of what you expect it to do, is out of its scope and can often be solved in other ways.
| hasufell wrote: | | We need a proper review platform which is fun to use. This is the difference between "oh cool, might just give this a quick review" and "oh noes, have to open the file (sometimes tared, compressed or just both), reference lines manually and make a list what is wrong with it". Then there is no automatic repoman check etc. All steps I have to do. Even if the ebuild supposedly just needs a rename, I calculate ~30min for a simple bump. |
Consider to automate and parallelize your workflow, instead of doing each step manually; you can cut off quite some time by doing so, for the simple bump below I calculate ~10 to ~15 mins.
| hasufell wrote: | * rename the ebuild
* fetch sources
* run repoman
* try to build with gcc
* try to build with clang
* try to build with gold linker |
This can all happen with a single command, the builds can run in parallel.
| hasufell wrote: | | * check if QA is still in place (CC, CFLAGS, LDFLAGS etc respected?)... as in: read the build log (yes, I do) |
We have QA notices for that, manually reading the build logs is therefore not necessarily; solely the summary output.
| hasufell wrote: | | * for games I also have to check whether the games variables are respected... that only works if I actually change them (/usr/share/games is sometimes even hardcoded, so it looks like it works, when it does not in fact) |
Changing that and checking the installed files can be automated.
| hasufell wrote: | | * when there are reverse deps... give them a quick rebuild |
This can also be automated; this is mostly needed for libraries, which makes this a less generic need.
| hasufell wrote: | | * build with some random use flag permutations |
We have app-portage/tatt for that.
| hasufell wrote: | | * EDIT: almost forgot... check if the user is actually correct about "only needs a rename" ...most of the time, it's just not true (new dependencies and whatnot) |
Running a diff over the important files between two versions semi-automatically cover this as well; other than that, QA scripts like depcheck can cover this automatically as well.
| hasufell wrote: | | and... you will still miss something (maybe it got relicensed?) |
Can also be semi-automatically done; though a bit harder, given the amount of licenses (covering the popular ones spares out time).
| hasufell wrote: | | Also mind that there are max ~3 people actively working on games ebuilds. I stopped blaming people for not becoming gentoo devs... but yeah. You'll have to lower your expectations. That is the sad truth. |
Also mind that there are min ~3 people actively interested in working on games ebuilds (eg. gamerlay, but also on b.g.o as Krinn demonstrates). I started making people interested in becoming gentoo devs... but yeah. You'll have to higher your expectations. That is the happy truth. |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Wed Jun 11, 2014 4:42 pm Post subject: |
|
|
| TomWij wrote: | | hasufell wrote: | | yes, bugzilla sucks |
It is rather good at what its purpose is, reporting and tracking bugs; all the rest of what you expect it to do, is out of its scope and can often be solved in other ways.
|
No, it even sucks at reporting bugs. It's an ancient tool that isn't able to even map the simplest workflows without overcomplicating everything.
| TomWij wrote: | | hasufell wrote: | | We need a proper review platform which is fun to use. This is the difference between "oh cool, might just give this a quick review" and "oh noes, have to open the file (sometimes tared, compressed or just both), reference lines manually and make a list what is wrong with it". Then there is no automatic repoman check etc. All steps I have to do. Even if the ebuild supposedly just needs a rename, I calculate ~30min for a simple bump. |
Consider to automate and parallelize your workflow, instead of doing each step manually; you can cut off quite some time by doing so, for the simple bump below I calculate ~10 to ~15 mins.
| hasufell wrote: | * rename the ebuild
* fetch sources
* run repoman
* try to build with gcc
* try to build with clang
* try to build with gold linker |
This can all happen with a single command, the builds can run in parallel. |
I run -j8, so it is already parallelized. Writing a script for it saves 3 seconds work and is pointless.
| TomWij wrote: | | hasufell wrote: | | * check if QA is still in place (CC, CFLAGS, LDFLAGS etc respected?)... as in: read the build log (yes, I do) |
We have QA notices for that, manually reading the build logs is therefore not necessarily; solely the summary output. |
That's just not true. Portage can not reliably detect most of the QA issues, including CC ignored, CFLAGS ignored and even LDFLAGS ignored (unless you use hash-style=gnu). And these are only the trivial things. How about overwritten CFLAGS or LDFLAGS not before libraries etc, that even confuses the hash-style=gnu check.
So no, that doesn't work like you think.
| TomWij wrote: | | hasufell wrote: | | * for games I also have to check whether the games variables are respected... that only works if I actually change them (/usr/share/games is sometimes even hardcoded, so it looks like it works, when it does not in fact) |
Changing that and checking the installed files can be automated. |
Then write up a script that's able to get all the exceptional cases. And there are a lot within games ebuilds. Also mind that not all files are supposed to go into games related directories... and this varies.
| TomWij wrote: | | hasufell wrote: | | * when there are reverse deps... give them a quick rebuild |
This can also be automated; this is mostly needed for libraries, which makes this a less generic need. |
It's a single bash line that takes me 10 seconds to write up. So it doesn't help.
| TomWij wrote: | | hasufell wrote: | | * build with some random use flag permutations |
We have app-portage/tatt for that. |
Also not the issue here.
| TomWij wrote: | | hasufell wrote: | | * EDIT: almost forgot... check if the user is actually correct about "only needs a rename" ...most of the time, it's just not true (new dependencies and whatnot) |
Running a diff over the important files between two versions semi-automatically cover this as well; other than that, QA scripts like depcheck can cover this automatically as well. |
I don't know what "depcheck" is. You are pobably referring to the DT_NEEDED entries. This is highly unreliable and not in the slightest a complete investigation.
The rest (like reading the diff of the build system) cannot be automated.
| TomWij wrote: | | hasufell wrote: | | and... you will still miss something (maybe it got relicensed?) |
Can also be semi-automatically done; though a bit harder, given the amount of licenses (covering the popular ones spares out time). |
You missed the point. Licenses was just an example.
| TomWij wrote: | | hasufell wrote: | | Also mind that there are max ~3 people actively working on games ebuilds. I stopped blaming people for not becoming gentoo devs... but yeah. You'll have to lower your expectations. That is the sad truth. |
Also mind that there are min ~3 people actively interested in working on games ebuilds (eg. gamerlay, but also on b.g.o as Krinn demonstrates). I started making people interested in becoming gentoo devs... but yeah. |
Gamerlay contributors have shown that they are not interested in reviews. I'm not interested in working with people who are not willing to cooperate more closely and spend some additional time. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Wed Jun 11, 2014 6:45 pm Post subject: |
|
|
| hasufell wrote: | | No, it even sucks at reporting bugs. It's an ancient tool that isn't able to even map the simplest workflows without overcomplicating everything. |
It does map them easily for me, despite there being ways to file them faster (pybugz, browser extensions, ...); bugs don't take long to file, I have never walked from filing a bug report thinking "this took ages", "this could be faster", "this was hard" or some other similar regression...
| hasufell wrote: | | I run -j8, so it is already parallelized. Writing a script for it saves 3 seconds work and is pointless. |
Which means that those three builds are parallel, therefore these step are fast and consume a minimal time; other than that, 3 seconds are 3 seconds and that can be quite useful to cut when you need to do these 3 seconds over and over again (as you get the ebuild to work).
| hasufell wrote: | That's just not true. Portage can not reliably detect most of the QA issues, including CC ignored, CFLAGS ignored and even LDFLAGS ignored (unless you use hash-style=gnu). And these are only the trivial things. How about overwritten CFLAGS or LDFLAGS not before libraries etc, that even confuses the hash-style=gnu check.
So no, that doesn't work like you think. |
Everything you've mentioned just works fine for me.
| hasufell wrote: | | Then write up a script that's able to get all the exceptional cases. And there are a lot within games ebuilds. Also mind that not all files are supposed to go into games related directories... and this varies. |
Yes, that's what you can do; it spares out a lot of time, as well as makes reviewing a lot easier.
| hasufell wrote: | | It's a single bash line that takes me 10 seconds to write up. So it doesn't help. |
If you're not willing to optimize the way you work; then as a result, you'll slow down your work a lot. 1 second is ten times as fast compared to 10 seconds...
| hasufell wrote: | | I don't know what "depcheck" is. You are pobably referring to the DT_NEEDED entries. This is highly unreliable and not in the slightest a complete investigation. |
There are various of those; DT_NEEDED in one way, the other way is to detect which files on the system were accessed, yet another one could be to deduce this automatically from configure.ac, etc...
| hasufell wrote: | | The rest (like reading the diff of the build system) cannot be automated. |
The format of the diff as well as the format of for example configure.ac (but also imports in languages) is known; as a result, it can be automated.
| hasufell wrote: | | You missed the point. Licenses was just an example. |
That's the point; it is one example that can be automated, among many others.
| hasufell wrote: | | Gamerlay contributors have shown that they are not interested in reviews. I'm not interested in working with people who are not willing to cooperate more closely and spend some additional time. |
The reviews can be made a lot easier and complete, which makes it more interesting for people to use them; some of this reviewing can even be made more implicit and available, by for example adding it to Portage, Repoman, Gentoolkit, Portage Utils, ...
As a side note it is worth knowing that such things as respecting *FLAGS are nice to have QA improvements; it however doesn't keep packages from being added to the Portage tree, neither does it keep these packages from stabilizing as we've seen earlier this week. In other words, it doesn't fit as one of the reasons for rejecting their contributions; as came up in the recruitment quizzes, we can handle their contributions constructively... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jun 11, 2014 7:14 pm Post subject: |
|
|
Lots of things "can" happen. And it's easy to discuss lots of ways things "can" be made better, as if that's all that needs to happen.
However, it's not. An awful lot more needs to happen, than someone state that "things can be better" as if that would make them so.
But not respecting *FLAGS is ok too.. welcome to lala land. |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Wed Jun 11, 2014 9:16 pm Post subject: |
|
|
| TomWij wrote: | | Which means that those three builds are parallel, therefore these step are fast and consume a minimal time; other than that, 3 seconds are 3 seconds and that can be quite useful to cut when you need to do these 3 seconds over and over again (as you get the ebuild to work). |
I have no idea what you are talking about.
| TomWij wrote: | | hasufell wrote: | That's just not true. Portage can not reliably detect most of the QA issues, including CC ignored, CFLAGS ignored and even LDFLAGS ignored (unless you use hash-style=gnu). And these are only the trivial things. How about overwritten CFLAGS or LDFLAGS not before libraries etc, that even confuses the hash-style=gnu check.
So no, that doesn't work like you think. |
Everything you've mentioned just works fine for me. |
I don't know what that means. Portage does NOT have the functionality you claim. It's just wrong.
| TomWij wrote: | | hasufell wrote: | | Then write up a script that's able to get all the exceptional cases. And there are a lot within games ebuilds. Also mind that not all files are supposed to go into games related directories... and this varies. |
Yes, that's what you can do; it spares out a lot of time, as well as makes reviewing a lot easier. |
I was asking you. I am not interested since I doubt it will save me any time.
| TomWij wrote: | | hasufell wrote: | | It's a single bash line that takes me 10 seconds to write up. So it doesn't help. |
If you're not willing to optimize the way you work; then as a result, you'll slow down your work a lot. 1 second is ten times as fast compared to 10 seconds... |
Sure, if I do this more than once a day, I might notice the slowdown. But this is so trivial I don't even know why we are talking about this.
| TomWij wrote: | | hasufell wrote: | | I don't know what "depcheck" is. You are pobably referring to the DT_NEEDED entries. This is highly unreliable and not in the slightest a complete investigation. |
There are various of those; DT_NEEDED in one way, the other way is to detect which files on the system were accessed, yet another one could be to deduce this automatically from configure.ac, etc... |
And none are reliable. So they are just indicators. I try to do my work properly, so I don't solely rely on any such tools.
You probably don't know... the former QA lead did run a tinderbox and had to file all bugs manually, because there was no easy way to automate this without causing a LOT of wrongly submitted bugs.
| TomWij wrote: | | hasufell wrote: | | The rest (like reading the diff of the build system) cannot be automated. |
The format of the diff as well as the format of for example configure.ac (but also imports in languages) is known; as a result, it can be automated. |
I have no idea what you are talking about. I still need to read the diff myself.
| TomWij wrote: | | hasufell wrote: | | You missed the point. Licenses was just an example. |
That's the point; it is one example that can be automated, among many others. |
No, it cannot easily be automated. Again... the same applies as with dependencies... it's not reliable and can only be an INDICATOR. Ulm will cut my head off if I run such tools without actually looking at any license file.
You oversimplify things... a lot.
| TomWij wrote: | | hasufell wrote: | | Gamerlay contributors have shown that they are not interested in reviews. I'm not interested in working with people who are not willing to cooperate more closely and spend some additional time. |
The reviews can be made a lot easier and complete, which makes it more interesting for people to use them; some of this reviewing can even be made more implicit and available, by for example adding it to Portage, Repoman, Gentoolkit, Portage Utils, ...
As a side note it is worth knowing that such things as respecting *FLAGS are nice to have QA improvements; it however doesn't keep packages from being added to the Portage tree, neither does it keep these packages from stabilizing as we've seen earlier this week. In other words, it doesn't fit as one of the reasons for rejecting their contributions; as came up in the recruitment quizzes, we can handle their contributions constructively... |
I don't know what this has to do with my quote. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Thu Jun 12, 2014 6:58 am Post subject: |
|
|
| steveL wrote: | | Lots of things "can" happen. And it's easy to discuss lots of ways things "can" be made better, as if that's all that needs to happen. |
+1
And
+1 again.
That is the worst annoyance I would complain about.
Everything, a simple version bump, a trivial patch needs to be justified, argued, questioned, then re-justified, re-questioned... nearly : ad-libitum.
I won't take the bugs I am implied in as examples, because I acknowledge that it could well be... my own fault.
But isnt' this one the extreme example of the problem?
I did not face the very problem krinn initialy reports and this simply because I had explicitly been told *not* to assign / CC bugs myself and let the bug-wranglers do their work.
I had found this st...range since, like krinn, I was expecting that this would save manpower and time.
The annoyance I then experimented is that, since my bugs are serviced by the bug-wranglers, they often change the summary, prefering spaces to colons, parentheses to brackets... and some times... the other way round...
The annoyance IS real since... this just breaks my mail-client filters.
Anyway... Never mind and fair enough... I comply.
I comply and my only reason for complying is that the very first thing I want is : My bug to be addressed as soon as possible.
And then, whatever the annoyances I can experiment, whatever my own and necessarily biased judgement on the process...
IF those actually in charge of handling the bugs, if the gentoo devs consider that they are happy with that process and that the fact that common users scrupulously follow that procedure makes so they can deliver more efficiently,
THEN, I am happy and WILCO! And WILCO happily!
err... reading hasufell... hmm... I suddenly feel my happiness... highly... questionable.
EDIT : I hate generalizing and always need grounds for questioning my happiness. So, among the 76 bugs I submitted, I must acknowledge that 52 went their way happily.
So... OK! I am 68.5% happy ! Cool!
EDIT-2 : OK... for the sake of honesty, I must also acknowledge that, in some (exceptional) occasions, that process delivers incredibly well.
So... with fun and trolling...
| hasufell wrote: | | I calculate ~30min for a simple bump. |
beaten! and
_________________
|
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Thu Jun 12, 2014 11:29 am Post subject: |
|
|
| hasufell wrote: | | I have no idea what you are talking about. |
Asking questions about it can help.
| hasufell wrote: | | TomWij wrote: | | hasufell wrote: | That's just not true. Portage can not reliably detect most of the QA issues, including CC ignored, CFLAGS ignored and even LDFLAGS ignored (unless you use hash-style=gnu). And these are only the trivial things. How about overwritten CFLAGS or LDFLAGS not before libraries etc, that even confuses the hash-style=gnu check.
So no, that doesn't work like you think. |
Everything you've mentioned just works fine for me. |
I don't know what that means. Portage does NOT have the functionality you claim. It's just wrong. |
How do you think the Tinderbox bugs for most of these were detected? Hint.
Out of all of them CC is perhaps less reliable, as that one relies on setting up wrappers, outside Portage; but ignored *FLAGS can be covered (record switches and set hash-style), as well as overwritten *FLAGS (use an as-needed GCC spec) as documented in the QA documentation.
| hasufell wrote: | | TomWij wrote: | | There are various of those; DT_NEEDED in one way, the other way is to detect which files on the system were accessed, yet another one could be to deduce this automatically from configure.ac, etc... |
And none are reliable. So they are just indicators. I try to do my work properly, so I don't solely rely on any such tools. |
True, but the point here is that they shave off a lot of time you would otherwise spend figuring out manually.
| hasufell wrote: | | You probably don't know... the former QA lead did run a tinderbox and had to file all bugs manually, because there was no easy way to automate this without causing a LOT of wrongly submitted bugs. |
That is a contradiction. Tinderbox does this automation; it is merely the bug reporting part of that that went manually to avoid unnecessary duplicates and matters like that, which is just a matter of more properly automating that as much as possible (as Patrick has been doing to a large extent). But that bug reporting part is irrelevant to this discussion; it is the detection that is automated, sparing out a lot of time.
| hasufell wrote: | | I have no idea what you are talking about. I still need to read the diff myself. |
Despite still needing to read it, it can be automated as the syntax and semantics are known.
| hasufell wrote: | | Ulm will cut my head off if I run such tools without actually looking at any license file. |
The heads of those whom run tools are still in place.
| hasufell wrote: | | You oversimplify things... a lot. |
Simplification is preferable compared to too complex things; as can be seen in the industry, it can lead to a superior value creation. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Thu Jun 12, 2014 11:48 am Post subject: |
|
|
| aCOSwt wrote: | | Everything, a simple version bump, a trivial patch needs to be justified, argued, questioned, then re-justified, re-questioned... nearly : ad-libitum. |
This is an exaggeration; I assume that this is an exception to it, or not?
| aCOSwt wrote: | | I won't take the bugs I am implied in as examples, because I acknowledge that it could well be... my own fault. |
Oh, so it can't be an exception; you've got me there!
| aCOSwt wrote: | | But isnt' this one the extreme example of the problem? |
That is one of the well known limitations of what can be supported without losing support.
| aCOSwt wrote: | I did not face the very problem krinn initialy reports and this simply because I had explicitly been told *not* to assign / CC bugs myself and let the bug-wranglers do their work.
I had found this st...range since, like krinn, I was expecting that this would save manpower and time. |
This is because often committers from the ChangeLog are put in the Assigned To field, as well the herds are left out, or one maintainer is Assigned To and the others ignored; similar to the list of information given above, a lot can go wrong here if the Assignment / CC expectations that have build up over the years aren't followed by users that are unaware of these expectations. Who wants to read through these expectations anyway if all what all they in first instance care about is to have the bug filed.
These expectations are listed here: https://wiki.gentoo.org/wiki/Project:Bug-wranglers#Assigning_Bug_Reports
| aCOSwt wrote: | The annoyance I then experimented is that, since my bugs are serviced by the bug-wranglers, they often change the summary, prefering spaces to colons, parentheses to brackets... and some times... the other way round...
The annoyance IS real since... this just breaks my mail-client filters. |
Along adding more information to the summary and making it more concise; the summary is corrected according to perceived standards which sometimes change when people start and/or stop with bug wrangling, they should undergo a knowledge codification one or another day but overall it doesn't form a large problem. You however seem to claim that they break mail-client filters, I do not see how they do that or experience this myself; can you give an example?
| aCOSwt wrote: | EDIT : I hate generalizing and always need grounds for questioning my happiness. So, among the 76 bugs I submitted, I must acknowledge that 52 went their way happily.
So... OK! I am 68.5% happy ! Cool! |
Oh, that should at least be 70%! Trying to quickly change this value, I found there were no version bump bugs for ck-sources open; so, to make you more happy we need you to file such new version bump bug reports...  |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Thu Jun 12, 2014 2:20 pm Post subject: |
|
|
| TomWij wrote: | | How do you think the Tinderbox bugs for most of these were detected? Hint. |
Yes, as I said... this is not part of portage. And it is unreliable. And I know that Diego didn't solely rely on any of these.
I have scripts in my .vimrc that do this, on top of my own build log syntax highlighting. So I open the build log, call some greps, check some parts with my own eyes that such scripts would never catch and be done.
| TomWij wrote: | | True, but the point here is that they shave off a lot of time you would otherwise spend figuring out manually. |
I already use them, so I don't see your point.
| TomWij wrote: | | That is a contradiction. Tinderbox does this automation; it is merely the bug reporting part of that that went manually to avoid unnecessary duplicates and matters like that |
???
I was talking exactly about the bug reporting part.
| TomWij wrote: | | Despite still needing to read it, it can be automated as the syntax and semantics are known. |
That sounds like you can automate programming. Err, no. You seem to have no idea what you are talking about here. This isn't trivial pattern detection.
| TomWij wrote: | | hasufell wrote: | | Ulm will cut my head off if I run such tools without actually looking at any license file. |
The heads of those whom run tools are still in place. |
You ignored the actual meaning of the statement: "without actually looking at any license file".
| TomWij wrote: | | Simplification is preferable compared to too complex things; as can be seen in the industry, it can lead to a superior value creation. |
This is totally unrelated to what I was talking about. I don't need a lecture on the KISS principle.
But you are simplifying things in a manner that makes them wrong. That can be as dangerous as the opposite. |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Thu Jun 12, 2014 2:23 pm Post subject: |
|
|
| aCOSwt wrote: | | hasufell wrote: | | I calculate ~30min for a simple bump. |
beaten! and |
I prefer proper work over quick work. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Thu Jun 12, 2014 3:25 pm Post subject: |
|
|
| hasufell wrote: | | aCOSwt wrote: | | hasufell wrote: | | I calculate ~30min for a simple bump. |
beaten! and |
I prefer proper work over quick work. |
There's a limit to anything... even to quality.
You know openttd release always 2 RC versions before a stable one? Considering openttd in tree is at version 1.3.3 still, as of today, openttd is bellow 1.4RC1 1.4RC2 1.4 1.4.1RC1 1.4.1RC2 1.4.1, let's be nice, don't count RC release, still 1.4 and 1.4.1...
I don't know what version you are working on, but in the meanwhile, no multiplayer because servers using latest version reject users with a version older.
It takes so much time to stabilize or even just enter the ~ tree that except if you work on 1.4.1 you will just gave users a useless old version again.
I will ask thread lock as i don't like how it goes now, i was expecting answers to my feelings devs on bugzilla have bad habit to ignore bugs when bug-wrangler didn't assign them to (lol something users are doing by just properly feel bugzilla query!).
So i expect more users of bugzilla answers than devs answers ; i don't wish put blame on that dev or that dev.
Thanks for the patch steveL (i'm afraid openrc will remain as-is even with your patch). |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Jun 12, 2014 5:36 pm Post subject: |
|
|
| krinn wrote: | i was expecting answers to my feelings devs on bugzilla have bad habit to ignore bugs when bug-wrangler didn't assign them to (lol something users are doing by just properly feel bugzilla query!).
So i expect more users of bugzilla answers than devs answers ; i don't wish put blame on that dev or that dev. |
Going back to what the topic was:
| krinn wrote: | | something is wrong at handling bugzilla. The user/group are autoassign by bugzilla when you properly fill the bug, while using a generic "i dont know what this bug is and where and who should look at it" result in better result than trying to make the bug route to who it should. |
It seems like bug-wranglers are useful ;) Again, I think having a fat reminder of the checklist would be useful, if a user is filling in the assignment (and it's not to bug-wranglers.)
That's assuming it's not already done, and if so, why are we getting this problem from our educated userbase? If we're going to add automation, I'd rather automate getting users to do the right thing, eg having a script that picks up on the same problem recurring over and over with the same user and emails them a link to a doc about it, with a reply-to: gentoo-user@
Devs can sort out their own scripts, afaic. It's not like they can't ask for help getting them done: that's what the forums are for (as well as IRC or mailing-lists, ofc.)
| Quote: | | Thanks for the patch steveL (i'm afraid openrc will remain as-is even with your patch). |
Well that brings up another aspect: sometimes the maintainer is away.
In this specific case though, qnikst is a developer since last year, so he can commit; as can any dev, for minor obviously-correct patches.
It's to be expected when you're devaway, that others may well have patched some of your ebuilds or packages, in response to bugs. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Thu Jun 12, 2014 7:25 pm Post subject: |
|
|
| hasufell wrote: | | Yes, as I said... this is not part of portage. And it is unreliable. |
Tinderbox uses Portage to leverage this, as the file hints; so, it is part of Portage. How is that unreliable if all these bugs come from the automatic detection of Tinderbox?
| hasufell wrote: | | That sounds like you can automate programming. |
Exactly, a large part of it can be automated; there is a limit to it, but we are far away from that limit.
| hasufell wrote: | | But you are simplifying things in a manner that makes them wrong. That can be as dangerous as the opposite. |
They appear to work right, no heads were cut off; so, what is the danger?
| krinn wrote: | | So i expect more users of bugzilla answers than devs answers ; i don't wish put blame on that dev or that dev. |
These answers are an unintended consequence; developers are concerned when their work (bug wrangling, games, ...) or when as a result matters related to that (QA workflow, ...) are mentioned, which involves them directly. Consider here that both proper bug wrangling as well as a proper QA workflow spare out time; it grants other developers more time to do more stuff, which is intended to get more bugs resolved. The bug wranglers have been analysed in the past in The Rise and Fall of a Central Contributor: Dynamics of Social Organization and Performance in the Gentoo Community and to a lesser extent in The Role of Emotions in Contributors Activity: A Case Study on the GENTOO Community.
But that doesn't withhold that there are more bugs filed than there are people to resolve them right now; so, there will as a result be a certain percent of bugs that remain open. The Bug Cleaners project was started to further address this; however, without more manpower even that project won't have success. Even when I check my own reported bug count I see several tenths of bugs that remain unresolved, which means that I can definitely share your feeling; Gentoo isn't a popular distribution, but rather a distribution with a specific need. Along with that comes that there will often be limited manpower; especially when its user / contributor base grows faster than its developer / infra base, which limits how fast these users and contributors can be satisfied.
That's why we're Gentoo penguins: No need to hurry, or otherwise we'll fall; no need to be too slow, or otherwise we'll miss out on the rest.
| steveL wrote: | | Again, I think having a fat reminder of the checklist would be useful, if a user is filling in the assignment (and it's not to bug-wranglers.) |
http://a3li.li/2013/11/improving-the-bugzilla-product-selection/
There is work going on to integrate a part of that, in the link above; beyond that, some parts of such checklist are specific to certain situations (eg. Xorg.0.log) so I assume such checklist to become long to cover most cases. The question is somewhat where to draw the limit; the above link is a good start to that, further categorization can become somewhat more tricky. And mentioning too much for a certain category tends to have users read over the extraneous information; or at least, that's what UX guidelines usually suggest.
| steveL wrote: | | That's assuming it's not already done, and if so, why are we getting this problem from our educated userbase? If we're going to add automation, I'd rather automate getting users to do the right thing, eg having a script that picks up on the same problem recurring over and over with the same user and emails them a link to a doc about it, with a reply-to: gentoo-user@ |
In terms of Bugzilla, one idea has been to support packages more directly; allowing the Bugzilla system to assign based on the package mentioned, instead of users or developers having to do this manually. Maybe this is something that we could get to see in the new Bugzilla. In terms of support on the forum and elsewhere; I think we could improve Portage's output in these cases, but if not a more knowledge base type of documentation can definitely help. Linking to documentation isn't always a silver bullet though; it can help cover a lot of cases, but there are exceptions. (When you get more than two packages to block each other, nasty dependencies in the reverse dependencies, a specific need, ...; specific things like that) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Jun 12, 2014 9:59 pm Post subject: |
|
|
@TomWij I'm not getting into it with you, as I've told you before. Suffice to say, this is an example of why:
| TomWij wrote: | | hasufell wrote: | | That sounds like you can automate programming. |
Exactly, a large part of it can be automated; there is a limit to it, but we are far away from that limit.
| hasufell wrote: | | But you are simplifying things in a manner that makes them wrong. That can be as dangerous as the opposite. |
They appear to work right, no heads were cut off; so, what is the danger?
|
Good luck. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Fri Jun 13, 2014 11:09 am Post subject: |
|
|
This addresses the general interest, people are welcome to get into that but it is not a requirement to do so; facts, references and examples are provided where they are due. In the example that is quoted the intended sound of programming automation is reaffirmed and the limits thereof, further questioning the actual existence of danger in the simplification; they both bring good luck, as feedback reveals the automation to cut time without danger.
They are important considerations to addressing the shared feeling; which everyone can reconsider, a shared collective can make a shared movement. Besides resolution of bugs and version bumps; this feeling can also be seen with stabilization as has been resounding on the mailing lists, where further automation and simplification considerations matter within their respective limits. Some considerations were made; with app-portage/tatt and other stabilization tools increasing the coverage, as well as speeding up the process and progress.
(This concerns me as a member of the QA Team, Bug Wranglers and Bug Cleaners; to address this feeling, I am looking for the best interests from users and developers regarding those considerations within the limits of available manpower.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Jun 13, 2014 3:04 pm Post subject: |
|
|
Does anyone besides TomWij know WTF that meant? I'm quoting it as he has a habit of going back and editing the posts that cause the most puzzlement, weeks later so that suddenly they're incisive two-liners that magically foresee all that is to come..:
| TomWij wrote: | This addresses the general interest, people are welcome to get into that but it is not a requirement to do so; facts, references and examples are provided where they are due. In the example that is quoted the intended sound of programming automation is reaffirmed and the limits thereof, further questioning the actual existence of danger in the simplification; they both bring good luck, as feedback reveals the automation to cut time without danger.
They are important considerations to addressing the shared feeling; which everyone can reconsider, a shared collective can make a shared movement. Besides resolution of bugs and version bumps; this feeling can also be seen with stabilization as has been resounding on the mailing lists, where further automation and simplification considerations matter within their respective limits. Some considerations were made; with app-portage/tatt and other stabilization tools increasing the coverage, as well as speeding up the process and progress.
(This concerns me as a member of the QA Team, Bug Wranglers and Bug Cleaners; to address this feeling, I am looking for the best interests from users and developers regarding those considerations within the limits of available manpower.) |
<parody>
'Now we have an example of early 21st century bulshytt[1]. Note the way the Markov chain generator strings together apparently intelligible phrases made from stock words; however the "important considerations" alluded to at the top of the second paragraph, are patently not manifest in the first, despite being referred back to. On top of these are more considerations that have seemingly unending scope and ofc no specification beyond an adjective, as well as some further, unspecified considerations.
Yet the reader is exhorted, in the manner of classical propaganda, to dig deep and contribute to an abstract, and unspecified idea of potentially unbounded scope, along with an appeal to authority based on position, not on content. This was coined a "bushism" in contemporary parlance, after the "War on Terror" which is about as useful as a concept as a War on Clouds, although of course much more appealing to the fear-soaked brains of our ancestors.'
</parody>
[1] Bulshytt: A technical term denoting speech (typically but not necessarily commercial or political) that employs euphemism, convenient vagueness, numbing repetition, and other such rhetorical subterfuges to create the impression that something has been said.
Neal Stephenson, "Anathem" |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Fri Jun 13, 2014 3:45 pm Post subject: |
|
|
Could I respectfully ask for some time to appropriately ? honnestly? correctly? approximatly? conveniently? gracefully? seriously? abruptly? arbitrarily? xwzt-ly? handle krinn's request ?
Please!
_________________
|
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Fri Jun 13, 2014 4:02 pm Post subject: |
|
|
| aCOSwt wrote: | Could I respectfully ask for some time to appropriately ? honnestly? correctly? approximatly? conveniently? gracefully? seriously? abruptly? arbitrarily? xwzt-ly? handle krinn's request ?
Please! |
The request is being worked on by the Gentoo community, by both contributors and developers; but, receiving parodies in mail is not bound to speed it up, it causes the contrary. Especially since that habit has no meaning with regards to the topic... |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Fri Jun 13, 2014 4:29 pm Post subject: |
|
|
| TomWij wrote: | | aCOSwt wrote: | Could I respectfully ask for some time to appropriately ? honnestly? correctly? approximatly? conveniently? gracefully? seriously? abruptly? arbitrarily? xwzt-ly? handle krinn's request ?
Please! |
The request is being worked on by the Gentoo community, by both contributors and developers; |
-- No! That request is being worked on by the Gentoo-Linux-Forum-Project! --
EDIT : And this one as well.
_________________
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
