PDA

View Full Version : U+1 Bug Management Thread - Draft sticky.



philinux
November 28th, 2011, 06:40 PM
Thanks to Effenberg for this. Please review and comment on this what would be the first post in the proposed sticky. And Cariboo did a great edit and sorted the BB codes and format out.


INTRODUCTION

This sticky thread was created and is maintained by the group of testers of the Ubuntu Development Version area (Ubuntu+1) of this forum.

Our goal is to find, study, report and keep track of bugs that affect the current development version of Ubuntu and it's flavors (such as Lubuntu).

TARGETS

The target-audiences for this content are:


Developers: Will hopefully find usable and summarized info here to ease and speed up their work.
Bug Triagers: Can use this content to help in triaging / validating / merging open Launchpad bugs.
Helpers: Will learn of current bugs and workarounds, thus being to provide better help for users in other forum sections.


BUG REPORTS

The following fields of information will be used. A bug reporter can choose to not fill all fields, according to bug characteristics, his own perception, limitations on current information.


Bug Short Description:
How to Reproduce the bug:
Current behavior:
Attachments: (image, code, files that can contribute to understanding the bug, if any);
Platform tested: (Ubuntu flavor, related software / package versions, hardware involved, if relevant);
Workaround: (only if known by the poster. Full workaround in CODE (for code) or QUOTE (for other procedures) tags. Not a long tutorial targeted at users. A working/usable fix. No external link to workarounds unless really needed (download of package, etc), so one can rapidly learn how to solve the problem when reading this sticky;
Link to Discussion Thread: (if it exists. Full U+1 link, so we can easily click it to open);
Link to Bug Report: (full launchpad link, so we can easily click to open it);
Bug Report Status: (will fix, will not fix, if the status is known and there is a Launchpad report);
Bug status: (Fixed, Not Fixed, if the status is known and there is a Launchpad report).

Attention Bug Reporter: Not all fields are required! Do the best you can. We as a group will try to work on each report to make it as precise as possible.

RULES


Only one bug should be report per post.
Even if kept blank, all fields must be respected and kept in order. Just cut & paste the above model when reporting;
Partial, confusing reports, will be checked by us, and re-reported in proper way if valid;
Descriptions must be as succinct, technical and direct as possible. Remember we are trying to make life easier for developers, triagers, etc;
No unrelated post of any kind. One can start a normal thread in this forum section to discuss other issues or comment on the reported bugs. Help us keep this thread as clean as possible;
If a bug report is posted by someone (tester or not) and no one can reproduce the bug (e.g. the report is wrong) the bug report will be deleted;
Use common-sense.


If you are not sure about how to use this thread and need more information in order to post a bug, please start a normal thread here with a descriptive title, such as [BUG] Testing needed.

ventrical
November 28th, 2011, 07:02 PM
It is pretty well self explanatory, concise and to the point.

Nice work all.

MG&TL
November 28th, 2011, 07:07 PM
Is the thread now here, then, or is this the draft

philinux
November 28th, 2011, 07:09 PM
Is the thread now here, then, or is this the draft

Draft as in the title. :P Please comment.

effenberg0x0
November 28th, 2011, 07:13 PM
Thanks Phil and Cariboo for your support on this. The formatting is a lot cleaner.

I'd like to stress that this is not "my idea", "my thread", etc. It is supposed to be a group effort. I feel like there are many official groups in the forum, in the community and we, as testers, are also a group, even if there's no such badge below our handles saying that.

We can add purpose for the knowledge and experiences we gather here, sharing them with people that can use it to improve Ubuntu. Working together, this can hopefully become something truly beneficial for Ubuntu and the community, as a whole. Ideally, it may bring other serious testers for this rather small area of the forum.

We don't have to face it as a boring job with mandatory fields. Everyone is free to contribute or not, in the best way possible.

Now I'll shut up as I want to hear your opinions :)

Thanks,
Effenberg

castrojo
November 28th, 2011, 07:48 PM
Hi!

This all looks good, but I have some questions about scope. When you say bugs in "ubuntu +1" do you mean bugs that affect running it day to day or all bugs?

I ask this because if it's just bugs with +1 then wouldn't that list get pretty huge right away? Is there some scope you want to define?

MG&TL
November 28th, 2011, 07:49 PM
Eearly on, you need to address some sort of cataloguing for the thread as it will inevitably become large.

Amjjawad & his One Stop Thread had a sort of log at the beginning of the thread whereby subjects were linked to at the start of the thread, enabling easy access.

Link's in my signature if you want to see.

effenberg0x0
November 28th, 2011, 08:22 PM
Hi!

This all looks good, but I have some questions about scope. When you say bugs in "ubuntu +1" do you mean bugs that affect running it day to day or all bugs?

I ask this because if it's just bugs with +1 then wouldn't that list get pretty huge right away? Is there some scope you want to define?

Hi Jorge, thanks for taking the time to participate in the discussion.

I don't have the ambition to catalog all existing bugs in here, but the most common, important, bugs we are seeing recently, that we see users complaining more or that may create more noise when PP is released. Yet, I do believe it may become a quite large list.

But I don't see anything bad in it:

- I think it would be easier for the target-audience to read a 5-line summary/technical bug description than to browse many pages long Launchpad reports, with all kind of information in it (relevant, not relevant, personal rants, etc). The link for the Launchpad report will most likely be present in each report here, and developers might choose to use it or not, to gather more relevant info.


- We, as testers, are the ones that are supposed to make things easier for developers, not the other way around. Otherwise, I can't understand why we would be here everyday testing.

- In terms of resources, I *think* Ubuntu would be OK with a large thread, after all, we have resources used freely at the Cafe, game-threads, etc. But you are the best to tell me about this aspect :)

Being 100% honest: I don't think we will succeed in having the best tool ever until PP. It's a long term initiative. An attempt. Hopefully it will promote the enrollment of other people, bring concision to our group of testers and, if I'm right, attract more good testers to this small area of the community. It's more about working together, creating some as a group, engaging and committing to improve Ubuntu, than anything else.

Well, call me an idealist :)

Regards,
Effenberg

effenberg0x0
November 28th, 2011, 08:24 PM
Eearly on, you need to address some sort of cataloguing for the thread as it will inevitably become large.

Amjjawad & his One Stop Thread had a sort of log at the beginning of the thread whereby subjects were linked to at the start of the thread, enabling easy access.

Link's in my signature if you want to see.

I agree. I think that, as we start to develop it, new ideas to improve it will arise and we will use them. It's far from being something static. It will only work and be useful if it is owned and managed by each one of us.

ranch hand
November 28th, 2011, 10:30 PM
This is a great idea and the draft version looks like a very good place to start.

I would get it up and running as soon as possible.

The only way to know what is really needed to make this work is to launch it and find out.

Hopefully this will become a standard sticky for future testing forums. It will improve with time.

If it gets too big it could be edited before the forum closes to remove bugs that are moot at that point. A little consultation would make this fairly easy. Certainly easier than having them still there when searching for an answer when the mayhem hits the general forums after release.

This could be an extremely handy tool at that time for all concerned.

philinux
November 28th, 2011, 10:36 PM
My intention was to leave it for 24 hours minimum for the timezone effect.

effenberg0x0
November 28th, 2011, 10:47 PM
HI Ranch Hand,


This is a great idea and the draft version looks like a very good place to start.

I would get it up and running as soon as possible.

The only way to know what is really needed to make this work is to launch it and find out.

That is exactly my opinion. I think it has potential, ok, but I can't be 100% sure or promise anything. At the very least, we will be working together, keeping up with each other developments and testing, and this can't be bad.



This could be an extremely handy tool at that time for all concerned.

This idea, as well as the one Ventrical is pursuing (of creating a shell-rescue-snippets thread) are all targeted one way or another at April 26th. We have 5 months until then, more or less 150 days. If we manage to have reported and developed workarounds for 50 bugs in this first cycle/attempt, I'll consider myself satisfied. Our team is small, everybody has jobs and etc.

Thanks for your feedback :)

ventrical
November 29th, 2011, 12:43 AM
I think it is just common sense to have our ducks in a row to some degree prior to the Alpha releases. Testing Oneiric was lots of fun and who wants to take that away from us eh :) But if the forum hives everything pertinent to this topic in real time then there will be a well of reference come release day and perhaps the transition then will not be so abrupt as it was with Oneiric. But yes, 150 days .. and that can only be done one day at a time. Slow builds are more durable, last longer than fast builds :)

my 2 cents worth.

philinux
November 29th, 2011, 02:43 PM
Sticky stuck. This one now closed.