On Saturday 03 January 2009 04:14:08 am Carlos E. R. wrote:

On Saturday, 2009-01-03 at 10:44 +1000, Eric Springer wrote:

...

Nobody is saying that things need to be perfect, but what we are saying is to not waste our time with things already known. These packages should lie in some sort repository intended for developers of the package until you believe that it actually requires _testing_.

Absolutely.

At worst, "zypper dup" could install a log or notes saying "don't test this", "known issues", etc.

Carlos, See how long it takes to come from this: http://en.opensuse.org/Bugs to this http://en.opensuse.org/Bugs:Most_Annoying_Bugs ? Is it something illogical in idea to look on the wiki for announcements? Second place: https://bugzilla.novell.com/query.cgi type in component name and you will get all related bugs. Where else to publish information? Remember that we talk about test version and people that want to be testers, that must have above average to analyze situation and look for solution. If someone can't come on idea to check: - bugzilla - wiki - mail list archive - forums how probable is that he will open change log or release notes? While I agree that even Factory must have well known release day, as current way of changes that happen anytime leads nowhere, asking to announce problem in more places than it is already announced will not help. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Saturday 03 January 2009 07:23:51 am Carlos E. R. wrote:

On Saturday, 2009-01-03 at 05:38 -0600, Rajko M. wrote:

...

...

Absolutely.

At worst, "zypper dup" could install a log or notes saying "don't test this", "known issues", etc.

Carlos,

See how long it takes to come from this: http://en.opensuse.org/Bugs to this http://en.opensuse.org/Bugs:Most_Annoying_Bugs ?

No factory section.

It is a wiki. You see article about Smolt. I liked idea and put article. Someone else added current workaround. I formatted and shaped that. Now, I hope that other will pick up and add more content, and that will bring more people using it, adding features and squashing bugs. If you miss Factory in most annoying bugs, make entry on wiki, update it every week, or month, with bugs that you care about, and let others do the same for their itch.

...

Is it something illogical in idea to look on the wiki for announcements? Second place: https://bugzilla.novell.com/query.cgi type in component name and you will get all related bugs.

Frankly, if I'm going to test a package included in factory, I assume it is ready for testing. I assume that it is thought to work, and that the devs wan us to test it now.

You had problem with kernel, and you know that you can test only the part of the kernel that you have hardware for test, so don't blame developers for broken drivers. The most that they can do is to write readme, or use wiki and list bugs there.

Thus, if I install factory, and think "hey, today I'm going to see how OOo works" - I'm not going to go search Bugzilla for all known issues, that's too long. However, in this case, the devs knew that OOo was not ready for testing...

So where they should put OOo? The only solution is to ship the older one, but do they have one that works with current environment.

...

Where else to publish information? Remember that we talk about test version and people that want to be testers, that must have above average to analyze situation and look for solution.

Yes, but I do not want to waste my time either.

If testing is for you waste of time, then it is time to take a rest and let other folks do it. I feel tired and I'm didn't take that much time testing last round, and I don't feel guilty at all.

...

While I agree that even Factory must have well known release day, as current way of changes that happen anytime leads nowhere, asking to announce problem in more places than it is already announced will not help.

Maybe. The wiki is a place, but an email here or a log file in the distro is probably even easier than writing up in the wiki.

Carlos, there are few mail lists that give you reports on bugs and package changes: opensuse-bugs Broadcasts all changes that are being made to bugs opensuse-commit Check in commit logs for Factory opensuse-features Broadcasts all changes that are being made to features opensuse-security-announce Announcements concerning security There few more related to YaST and zypper. For instance check this: http://lists.opensuse.org/cgi-bin/search.cgi?query=OpenOffice it is case sensitive, and there is link to Advanced Search, where you can limit number of results, by specifying for instance what mail list, or data range is your interest. As I said if all that is already provided is not enough, what else to do. Write it on default wall paper? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tuesday 06 January 2009 06:47:21 am Rob OpenSuSE wrote:

2009/1/3 Rajko M. :

...

On Saturday 03 January 2009 07:23:51 am Carlos E. R. wrote:

...

On Saturday, 2009-01-03 at 05:38 -0600, Rajko M. wrote:

...

See how long it takes to come from this: http://en.opensuse.org/Bugs to this http://en.opensuse.org/Bugs:Most_Annoying_Bugs ?

No factory section.

It is a wiki. You see article about Smolt. I liked idea and put article. Someone else added current workaround. I formatted and shaped that. Now, I hope that other will pick up and add more content, and that will bring more people using it, adding features and squashing bugs.

If you miss Factory in most annoying bugs, make entry on wiki, update it every week, or month, with bugs that you care about, and let others do the same for their itch.

So if it's so simple, why don't those putting packages into Factory have to comment, in such a place?

Relying on community testers to poll and document bugs, on code which they are unfamiliar with is extremely ineffiecient. Furthermore they may spend significant time documenting a transient or hardware specific issue.

Also, positive communication and engagement with community testers ought to foster better relations, and grow the community.

Currently the "Most Annoying Bugs" type list is very incomplete. There's commonly occuring issues unreported there, which look far more serious; never mind the many hardware issues which may stymie a Live CD install and require experience to work round.

The "Most Annoying Bugs" is short reference maintained by developers and community testers, whoever can find time to put information on the wiki. It is short reference of often reported bugs in bugzilla.novell.com and main use is to help openSUSE users/testers not to report bugs that are already reported few times, but to join effort to resolve bug in one place. Therefore format: <bug number> <description> . Creating entry on the wiki is not a holly script, so anyone missing it can create wiki page, add reference it in the "Most Annoying Bugs". -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Le mercredi 07 janvier 2009, à 10:07 +0000, Rob OpenSuSE a écrit :

2009/1/7 Rajko M. :

...

Creating entry on the wiki is not a holly script, so anyone missing it can create wiki page, add reference it in the "Most Annoying Bugs".

How would I know it was a commonly reported bug, without being in the Bug Triage team?

Because you're experiencing the bug and saw there were many duplicates in bugzilla, for example.

Frankly, that "Most Annoying Bugs" page, has been far too incomplete and also looking over it, it is very much application oriented.

If the responsibility is on "Community Testers" to create Wiki pages, you are creating yet another hurdle to cross.

For the testing I've done, there's been quite enough time spent, installing, trouble shooting, checking reproducibility and trying to narrow down the bug, whilst checking Bugzilla, without starting to worry about writing Wiki pages.

So to be blunt, it is TOTALLY unrealistic to expect me to write both a bug report, and do Wiki page! I just won't get round to doing it.

So, hrm, are you saying that this should be done by Novell people only? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/1/7 Vincent Untz :

Le mercredi 07 janvier 2009, à 10:07 +0000, Rob OpenSuSE a écrit :

...

2009/1/7 Rajko M. :

...

Creating entry on the wiki is not a holly script, so anyone missing it can create wiki page, add reference it in the "Most Annoying Bugs".

How would I know it was a commonly reported bug, without being in the Bug Triage team?

Because you're experiencing the bug and saw there were many duplicates in bugzilla, for example.

Who's deciding they're duplicates? It's very often unclear, when you join a bug report, that it is actually the same bug. I've often for instance seen claims of "crashes", but unsupported by kernel dump or oops, when what I see is very poor performance and many errors written to log files.

...

So to be blunt, it is TOTALLY unrealistic to expect me to write both a bug report, and do Wiki page! I just won't get round to doing it.

So, hrm, are you saying that this should be done by Novell people only?

No I never said that. If openSUSE ppl are doing bug triage, and have communication with the developers of the package involved they're in an excellent position to make that decisions. I don't think the average bug reporter will make a good job of it. Most likely if it was done, frequently the reports would be unclear, and would get orphaned, just like so many bugzilla reports I've seen which get stuck for months (years?) on "NEEDINFO". -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/1/7 Vincent Untz :

Le mercredi 07 janvier 2009, à 16:50 +0000, Rob OpenSuSE a écrit :

...

2009/1/7 Vincent Untz :

...

Le mercredi 07 janvier 2009, à 10:07 +0000, Rob OpenSuSE a écrit :

...

2009/1/7 Rajko M. :

...

Creating entry on the wiki is not a holly script, so anyone missing it can create wiki page, add reference it in the "Most Annoying Bugs".

How would I know it was a commonly reported bug, without being in the Bug Triage team?

Because you're experiencing the bug and saw there were many duplicates in bugzilla, for example.

Who's deciding they're duplicates? It's very often unclear, when you join a bug report, that it is actually the same bug. I've often for instance seen claims of "crashes", but unsupported by kernel dump or oops, when what I see is very poor performance and many errors written to log files.

Let's take a concrete example:

a) you file a bug (bug A). b) someone (doesn't matter who) closes your bug as duplicate of another bug (bug B)

You then have two possibilities:

That's not what we're supposed to do. Filing the bug report involves searching for similar reports, hence my experience of "joining" other bug reports, if the problem looks similar. Often this involves providing information, for a bug report filed on a previous release, that has stalled. Where Novell bug reports have been marked as duplicates, it's often due to poor titling of the initial report, or a partial intersection with another report rather than a full duplication. So if you're a concientious bug reporter, you generally do not get into the situation you hypothetically put forward.

Now, the person who closed your bug as duplicate could have added the bug in the list of most annoying bugs, but maybe this person just forgot or was doing something else at the same time. So you can do it. Sure, you might be afraid to do it because you're not 100% sure it's right, but it's a wiki and the good thing is that someone disagreeing with you will be able to fix the stuff.

I'm sorry but when I've been testing stuff, frequently I have to be not only selective of the bugs I report, as there is no shortage of obvious flaws to find in a release like 11.1-rc1, but then there's often test reports to gather in a timely turn around. The reality is, messing around in the Wiki is yet another task, one that is public and that decision "most annoying bugs" is one that I'd not be well placed to make a considered judgement. The developer's marking bugs as duplicates, who do not want another 10 bug reports, are however perfectly placed. The value of "Most Annoying Bugs" has actually been close to 0 to me, I really don't see any value in a whole load of "hand waving" community testers, feeling obliged to maintain such a list. Just following the Factory Mail list seems far more effective way to get a better feel for the issues, and solutions. For example, where was "Intel Graphics" in the "Most Annoying Bugs"? OTOH there were suspicions that CPUFREQ, was locking AMD Cool N' Quiet CPUs to the slowest frequency, marked a priority 1 bug, was reported monthes before release, the reporter failed to provide feedback; there communication from the Bug Assignee appealing for test on that before release would have been useful.

I have the feeling that you think the barrier to contribute is high. It doesn't have to be. An average bug reporter can make a good job too for this. You just don't have to be afraid of making mistakes.

I am actually saying, that contributing by testing, filing bugs, and providing info on "known" problems is fairly time consuming as is, without adding extra expectations of also creating Wiki pages which can only be of a speculative nature. Those who believe in doing the Wiki can "simply" scan the publically available bug reports and probably do a better job than I would. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

2009/1/8 Vincent Untz :

Le jeudi 08 janvier 2009, à 11:12 +0000, Rob OpenSuSE a écrit :

...

2009/1/7 Vincent Untz :

...

I am actually saying, that contributing by testing, filing bugs, and providing info on "known" problems is fairly time consuming as is, without adding extra expectations of also creating Wiki pages which can only be of a speculative nature.

Nobody is expecting you to do it: "you can do it" doesn't mean "we expect you to do it".

The thing is: if it's broken, anybody can step up to start fixing it. You're saying "it's up to the developers/bug triage team", while I'm saying "it's up to all of us, and it's realistically more likely to be fixed by people who think the current list is not good enough".

So isn't that exactly as it stands? Someone wanted more useful information, somebody else suggested "Most Annoying Bugs" and Bugzilla searches as if it was a solved issue. Those actually seem to me, to have been less useful than Factory mail list, when looking at 11.1 beta & rc. If we're talking about a development release, then it's communication from packagers that's most likely to help testing community; trying to document issues with only 1 piece of the puzzle appears doomed to me. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org