Sounds good to me. It might be worth waiting to see what kind of bugs
we get first.
On Jun 18, 2007, at 1:52 PM, Mimi Yin wrote:
FWIW, uploading your repo ain't fun ;o) And reading the step-by-
step instructions is probably not going to a common scenario?
I'm wondering if we're jumping the gun worrying about an
unmanageable influx of repos? The directions are pretty clear that
repo-submit is a 'Don't call me, I'll call you' kind of thing, as
in developers may ask you to upload your repo.
Would it be too risky to see what happens?
Mimi
On Jun 15, 2007, at 9:14 AM, Mike Taylor wrote:
I just wanted to make a note and remind everyone that currently
the repo-submit tool is located on what is technically an internal
dev resource. If the instructions for dogfooders is going to go
public then I suspect the repo-submit tool will either a) run out
of drive space or b) crash due to load.
What kind of user count are you expecting? If it's more than 5-10
items a day then we will need to find a new home for repo-submit.
Note: the 5-10 number is purely a SWAG I pulled out of the air - I
have no idea how many connections-per-second the repo-submit
service can handle but I do know that drive space is going to be a
concern.
On Jun 15, 2007, at 12:14 AM, Aparna Kadakia wrote:
We also have the instructions for dogfooders page which instructs
users on how to report problems, log files, repositories etc.
There is also overlap between this page and the ReportABug page.
http://chandlerproject.org/Projects/InstructionsForDogfooders
Aparna
On Jun 14, 2007, at 6:19 PM, Mimi Yin wrote:
How about this?
http://chandlerproject.org/Journal/ReportABug
At the top, I added a short definition of what a bug is and a
pointer to the Chandler Users list for people who don't feel
like their issue is concrete enough for a bug report.
Right below that are 2 columns, 1 for the Desktop and the other
for Chandler Hub/Server.
The instructions are very brief. Mostly telling you to check to
see if your problem has been logged and a note about what extra
info to include.
I've consolidated the overlapping material at the bottom. It's
mostly process stuff about how to log a good bug report and how
bugs are process.
Anything else we want to add? Do I have the right prioritization
in terms of what info should be above the fold / below the fold?
Mimi
On Jun 14, 2007, at 5:49 PM, Ted Leung wrote:
IOn Jun 14, 2007, at 4:55 PM, Mimi Yin wrote:
http://chandlerproject.org/Projects/ReportingBugs
http://chandlerproject.org/bin/view/Projects/ReportingBugsCosmo
Who is the target audience for Reporting bugs?
Do we expect end-users to report bugs?
I definitely expect end users to report bugs.
Should we unify these pages? There's a lot of overlap and it
seems like for end-users, we mostly want to pinpoint where
they experienced their problem and send them on their way
accordingly...
+ Chandler Desktop
+ Chandler Hub / Chandler Server
There's a bunch of common stuff about how/when to file a bug,
and it seems like a waste to duplicate that. But I also agree
that we want it to be clear and easy to report problems on the
correct product.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
---
Bear
Build and Release Engineer
Open Source Applications Foundation (OSAF)
[EMAIL PROTECTED]
http://www.osafoundation.org
[EMAIL PROTECTED]
http://code-bear.com
PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
