A few comments:
1. I agree that it is useful to remove obsolete, uninformative comments in the appdb. (You have to be careful to leave the old informative ones, though; if somebody has a great workaround or bug that might still be useful, don't delete it.)
2. The wiki is not the place for appdb-like stuff; duplication of information silos is generally a bad idea. Yes, I created a few wiki pages for Adobe apps, but that was a temporary hack, and the appdb provides almost enough flexibility. (What's missing is the ability to add howto's and notes at the application level, i.e. one level higher than the version level where they all go right now, but that's not usually a dealbreaker.)
3. Eight days is way too quick to remove an inactive maintainer. Six months is more like it.
4. The Wine community has some abrasive characters in it. Periodically we have to ask some of them to chill out. Everyone who is very active should take care that they don't get too curt with other developers or with users. A basic level of courtesy shouldn't be too hard. Dogfights where two maintainers are asking to have each other thrown out are a good sign that both of said developers need to chill.
'Nuff said. - Dan
2009/6/27 Dan Kegel dank@kegel.com:
(What's missing is the ability to add howto's and notes at the application level, i.e. one level higher than the version level where they all go right now, but that's not usually a dealbreaker.)
I like the sound of this! What's the feasibility of letting supermaintainers create app-level HOWTOs and notes?
- The Wine community has some abrasive characters in it.
/me waves
On Sat, Jun 27, 2009 at 02:32, Dan Kegeldank@kegel.com wrote:
(What's missing is the ability to add howto's and notes at the application level, i.e. one level higher than the version level where they all go right now, but that's not usually a dealbreaker.)
The usefulness of app-level howo's depend a lot on the application.
It should work really good for things like games, while it would not work at all for things like Office.
As long as the version-level howto's are kept, application level howto's / notes might be useful, even if just for pointing out which version is prefered for Wine.
Gert
2009/6/27 Gert van den Berg wine-devel@mohag.net:
On Sat, Jun 27, 2009 at 02:32, Dan Kegeldank@kegel.com wrote:
(What's missing is the ability to add howto's and notes at the application level, i.e. one level higher than the version level where they all go right now, but that's not usually a dealbreaker.)
The usefulness of app-level howo's depend a lot on the application.
This is the point, that there are some applications where the install instructions are identical across versions.
It should work really good for things like games, while it would not work at all for things like Office.
As long as the version-level howto's are kept, application level howto's / notes might be useful, even if just for pointing out which version is prefered for Wine.
No one is suggesting removing version-level HOWTOs or notes and replacing them wholesale with app-level equivalents.
Dan Kegel wrote:
- Eight days is way too quick to remove an inactive maintainer. Six
months is more like it.
That is far too long. After two weeks there are 100 test results waiting in the queue. Six months wouldn't help the users out at all. Their test results would disappear into a black hole.
Ken Sharp wrote:
Dan Kegel wrote:
- Eight days is way too quick to remove an inactive maintainer. Six
months is more like it.
That is far too long. After two weeks there are 100 test results waiting in the queue. Six months wouldn't help the users out at all. Their test results would disappear into a black hole.
But he could be temporarily away. What about sending him a mail after 8 days, sending him an urgent mail after two/three weeks saying "please remove yourself if you know you're not going to handle these" and only remove him a few weeks later. Maintainers are volunteers, they can't be expected to spend *all* their time on appdb, they have time now and then; unless they are, for example, on a holiday.
Sjors
On Mon, 29 Jun 2009 13:19:18 +0200 Sjors Gielen mailinglist@dazjorz.com wrote:
Ken Sharp wrote:
Dan Kegel wrote:
- Eight days is way too quick to remove an inactive maintainer. Six
months is more like it.
That is far too long. After two weeks there are 100 test results waiting in the queue. Six months wouldn't help the users out at all. Their test results would disappear into a black hole.
But he could be temporarily away. What about sending him a mail after 8 days, sending him an urgent mail after two/three weeks saying "please remove yourself if you know you're not going to handle these" and only remove him a few weeks later. Maintainers are volunteers, they can't be expected to spend *all* their time on appdb, they have time now and then; unless they are, for example, on a holiday.
That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours.
But you are right about temporary absences. It would be useful if there were some sort of "out of the office" flag that maintainers could check to notify admins that they'll be gone for a time, and we should process the tests reports for their apps.
I also think booting the maintainer on a first offense is a bit extreme. I'd prefer a "three strikes and you're out" approach--the first two times admins have to process a maintainer's tests (after sitting there for a week) they get warnings; the third time, they're removed as maintainer, and not allowed back. But there would need to be an automatic mechanism to keep track of repeat offenders. I'm not sure how difficult that would be.
BTW, nowhere on the maintainer guidelines page does it say that maintainers have to process test reports within a certain amount of time. In fact, nowhere does it say anything about them having to process test reports at all, nor does it say anything about being removed as a maintainer if they fail to fulfill their duties (which are so vague as to be unenforceable anyway). This really needs to be rectified.
On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesiodimesio@earthlink.net wrote:
That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours.
How about mailing admins after 24 hours? Maintainers are useful to offload tasks of admins. If they are away for a while, admins just get the mail as if there were no maintainer. If you have to remove a maintainer every time he can't respond in 24 hours, you won't have many left after a while.
Remco
On Mon, 29 Jun 2009 14:56:23 +0200 Remco remco47@gmail.com wrote:
On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesiodimesio@earthlink.net wrote:
That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours.
How about mailing admins after 24 hours? Maintainers are useful to offload tasks of admins. If they are away for a while, admins just get the mail as if there were no maintainer. If you have to remove a maintainer every time he can't respond in 24 hours, you won't have many left after a while.
Remco
Nobody's suggesting a 24 hour time limit for maintainers.
As for emailing the admins, I know I turned off emails from the AppDB to avoid having my mailbox overwhelmed with hundreds of useless notices every day, and I doubt I'm the only one who did this. http://bugs.winehq.org/show_bug.cgi?id=14755 needs to be fixed first for any solution that involves emailing admins to be viable.
On Mon, Jun 29, 2009 at 5:56 AM, Remcoremco47@gmail.com wrote:
That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours.
How about mailing admins after 24 hours? Maintainers are useful to offload tasks of admins.
Appdb admins get an absolute flood of appdb email. My impression was that we got copies of everything that ever happens on the appdb. Is it really only email for unmaintained apps? - Dan
On Mon, Jun 29, 2009 at 10:03 AM, Dan Kegeldank@kegel.com wrote:
On Mon, Jun 29, 2009 at 5:56 AM, Remcoremco47@gmail.com wrote:
That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours.
How about mailing admins after 24 hours? Maintainers are useful to offload tasks of admins.
Appdb admins get an absolute flood of appdb email. My impression was that we got copies of everything that ever happens on the appdb. Is it really only email for unmaintained apps?
- Dan
No, it's for everything, though it can now be disabled.
On Mon, Jun 29, 2009 at 8:06 AM, Austin Englishaustinenglish@gmail.com wrote:
Appdb admins get an absolute flood of appdb email. My impression was that we got copies of everything that ever happens on the appdb. Is it really only email for unmaintained apps?
No, it's for everything, though it can now be disabled.
There's only one checkbox, does that disable all email? If so, maybe we need another checkbox that just disables unmaintained app email.
On Mon, 29 Jun 2009 08:11:20 -0700 Dan Kegel dank@kegel.com wrote:
On Mon, Jun 29, 2009 at 8:06 AM, Austin Englishaustinenglish@gmail.com wrote:
Appdb admins get an absolute flood of appdb email. My impression was that we got copies of everything that ever happens on the appdb. Is it really only email for unmaintained apps?
No, it's for everything, though it can now be disabled.
There's only one checkbox, does that disable all email?
It disables all automated notices. Private emails still go through.
If so, maybe we need another checkbox that just disables unmaintained app email.
At the very least. More checkboxes to further specify what we do/don't want to receive would be even better.
-
Austin English -
Ben Klein -
Dan Kegel -
Gert van den Berg -
Ken Sharp -
Remco -
Rosanne DiMesio -
Sjors Gielen