| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Jonathan Smith wrote: |
| 5 |
|
| 6 |
> Scott Shawcroft wrote: |
| 7 |
> |
| 8 |
>> The bugday database would hold additional bug information. Not |
| 9 |
>> the data found in bugzilla. We get the available info from the |
| 10 |
>> bugzilla DB. The bugday DB is a supplement. |
| 11 |
> |
| 12 |
> |
| 13 |
> your origional email said "User logins using usernames and |
| 14 |
> passwords from bugzilla." this implies that you would be porting |
| 15 |
> the login db from bugzy to b-day. perhaps i misread that, but if |
| 16 |
> you use the same db for logins, how will you keep the two synced? |
| 17 |
> if i change my password on bugzy, would it be changed on bday too? |
| 18 |
|
| 19 |
We were thinking we'd verify passwords etc against the bugzilla DB. |
| 20 |
No separate info, just supplemental info in the bugday DB. |
| 21 |
|
| 22 |
> |
| 23 |
>> They would 'vote' via either adding a bug id or adding a vote to |
| 24 |
>> an existing bugday bug via a link.* |
| 25 |
> |
| 26 |
> |
| 27 |
> this again implies that you would need the bugzilla database. how |
| 28 |
> else would you keep track of which bug is which? iirc, jforman said |
| 29 |
> it was about 1.7gb... thats alot to manage in *two* places. this is |
| 30 |
> more of a technical issue than a problem with your plan, but i'm |
| 31 |
> just wondering how you plan to do this. |
| 32 |
|
| 33 |
When we add a bug to bugday it just tracks the ID. The other info |
| 34 |
like status etc. is taken from the bugzilla database. If it helps, we |
| 35 |
can and will be performing read only functions on the bugzilla database. |
| 36 |
|
| 37 |
> |
| 38 |
>>>> the problem i see is that easy bugs will simply be fixed by |
| 39 |
>>>> developers. the more difficult bugs will be either swept |
| 40 |
>>>> under the carpet or passed to maintainer-needed or bday. |
| 41 |
> |
| 42 |
> |
| 43 |
>> Could you explain this more? What developers actively work on |
| 44 |
>> has no direct link to bugdays. First and foremost bugdays are to |
| 45 |
>> give direction to users. However, since users cannot commit |
| 46 |
>> changes, the developers are involved. |
| 47 |
> |
| 48 |
> |
| 49 |
> you said that bugs would be ranked by difficulty and users with |
| 50 |
> experience "x" could work on bugs of the same experience level. |
| 51 |
> say, for instance, a user is very new to gentoo, or at least to |
| 52 |
> portage. if a dev gets a bug saying "package x does not install doc |
| 53 |
> y", the dev knows that all (s)he has to do is add y to dodoc. |
| 54 |
> consequently, the dev does it in a matter of seconds and the bug is |
| 55 |
> gone. |
| 56 |
> |
| 57 |
> if i understand correctly, developers add their own bugs to the |
| 58 |
> bugday list. since simple bugs like the above take just about as |
| 59 |
> much time to solve as to add to an arbitrary list, i don't see any |
| 60 |
> easy bugs being added to bday for newbie users to solve. |
| 61 |
> |
| 62 |
> maybe i'm wrong, but thats how i would generally do things. |
| 63 |
> |
| 64 |
The bugs will be added by the users. Even now they are added by |
| 65 |
people not associated with the bug, ie kloeri, GurliGebis, me and |
| 66 |
others. One of the lower levels of bughunting would be ebuild writing. |
| 67 |
|
| 68 |
>> To see how well it works is yet to be seen. However, it would be |
| 69 |
>> nice to extend the community into actual meetings. I believe |
| 70 |
>> (disclaimer) that learning techniques for bughunting and the like |
| 71 |
>> could be better learned in person. Having multiple people in one |
| 72 |
>> location is more effective and prevents bughunting from being too |
| 73 |
>> individual of an experience when its really focused on community. |
| 74 |
>> |
| 75 |
> |
| 76 |
> |
| 77 |
> this is true. if you can manage to arrange it, and its not too far |
| 78 |
> away (i'm pretty poor :-), i'd love to come. |
| 79 |
> |
| 80 |
> the sense of community would also be strengthened a good deal. i |
| 81 |
> read an article about obsd's hackathon, and it seems as if they are |
| 82 |
> all one big group of friends. maybe a stronger sense of community |
| 83 |
> would cut down on some of the silly arguments too... |
| 84 |
|
| 85 |
Exactly. Just don't consider the bugday real life events like |
| 86 |
conferences. More like your standard LUG. |
| 87 |
|
| 88 |
> |
| 89 |
>>>> occasionally user input. ex: if i can't reproduce and a user |
| 90 |
>>>> takes a month to do something that should have taken a few |
| 91 |
>>>> seconds, it is hard to progress quickly on the bug |
| 92 |
> |
| 93 |
> |
| 94 |
>> Right and bugdays could prevent these instances from being over a |
| 95 |
>> month long. It may also a way to bring more attention and |
| 96 |
>> knowledge about bugzilla. |
| 97 |
> |
| 98 |
> |
| 99 |
> well... if a user files a bug and the next bugday isn't for 3 |
| 100 |
> weeks, that doesn't seem to help much, unless i am misunderstanding |
| 101 |
> you. |
| 102 |
|
| 103 |
I realised that argument, "prevent these instances from being over a |
| 104 |
month long". With that said, I believe there are a lot of bugs just |
| 105 |
sitting for over a month. Hopefully bugdays would catch those. Also, |
| 106 |
the new bugday website will not be in operation just for bugdays. It |
| 107 |
will always be up and changing. |
| 108 |
|
| 109 |
~Scott |
| 110 |
|
| 111 |
> |
| 112 |
> -- |
| 113 |
> |
| 114 |
> smithj |
| 115 |
> |
| 116 |
> Gentoo Developer [ desktop stuff && network monitoring && |
| 117 |
> documentation ] |
| 118 |
> |
| 119 |
> |
| 120 |
-----BEGIN PGP SIGNATURE----- |
| 121 |
Version: GnuPG v1.4.1 (GNU/Linux) |
| 122 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 123 |
|
| 124 |
iD8DBQFC3R4n10ekhar8gdURAtQkAKCYeeWykP0JhG50rC4oW2dnYDf//ACeNeZ2 |
| 125 |
KQnxHWt1DMfpR435RLAj9cg= |
| 126 |
=DH7Y |
| 127 |
-----END PGP SIGNATURE----- |
| 128 |
|
| 129 |
-- |
| 130 |
gentoo-dev@g.o mailing list |
Archives