You do not need programming skills, just a fair amount of Drupal experience and some time. There are a large number of older bug reports marked CVS that have not been closed out over time ago and may no longer be relevant. Here are the steps:
- Download and install Drupal HEAD on a test site.
- Visit the pending bugs list and start with the oldest reports.
- If a bug is marked as 4.5 or cvs, check if it still applies to the current HEAD version you downloaded.
- if it still applies, then set the version to cvs (if there is more than one cvs in the version menu, pick the first)
- Click the follow up link and update the bug report with your findings so that work is not duplicated.
- if the bug can no longer be reproduced as it is fixed or just no longer applies (several screens are reworked in HEAD), just change the status to fixed and update the comments acordingly.
- If bug report version is marked as 4.6, then just follow up whether the bug still exists in HEAD and update accordingly with a comment "exists in current HEAD". If you feel like verifiying if the bug has been corrected in 4.6.2 then go ahead but the current focus is to clean up the oldest ones first.
When Drupal enters the feature freeze cycle, it'll be much, much easier to look at only the real bugs not at several hundreds of old bugs. This is an excellent way to get involved with QA testing and is something that really helps out.
NOTE: No, there is no date on a feature freeze, we'd just like to get the clean up done so we are ready when it's announced.
Update: 357 open bugs on July 27 07:12 GMT+1. I will update this post from time to time to indicate where we are.
Update: 284 open bugs on August 23 18:05 GMT+1. I guess the bug bingo moved people. It's improvement, no doubt, but still a lot.
Comments
bugs on the front page
you've got to keep pure development statements off the front page! a first time user considering just using drupal as their cms will not be impressed
you guys could use a main development page
This is not for developers
"You do not need programming skills"... I am asking for more hands.
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
We do.
This one. Drupal is very open. We try and keep a lot of the focus here. Mix developers and site admins and new users. Welcome to the product. This is on purpose. :)
If a first time user is not impressed, well, their loss for not bothering to actually evaluate the product.
As it is, if you have a moderate amount of experiance using Drupal, then this is your chance to hop in and help check out old reports. A lot of them are duplicates or no longer apply and the person who patched/fixed it forgot to go close out the report. That's all. Why would this be something to 'hide' on a development page?
-sp
---------
Test sites and good habits: Drupal Best Practices Guide.
Back Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
ok ... i'm not a programmer,
ok ... i'm not a programmer, but i'm a user and a tester ... not really getting anywhere on this one, though:
http://drupal.org/node/24030
if i'm not approaching bug reports/patch testing in the right way, it would be good to know ... it seems like i'm wasting my time trying to help out on this one.
http://www.machinehasnoagenda.com
word of advice, limit
word of advice, limit yourself to bug reports (only) that is open and you can handle. only those simple ones. there are still a lot of them. leave those hard ones (i.e. with patches) to programmers to verify.
:)
"If you build it, they will come." -- Field of Dreams
I see your point. Maybe
I see your point. Maybe there should be a front page with version, download, etc info and a completely seperate news page
Huw.org.uk
Please refrain from telling
Please refrain from telling us what to do or not to do. Thank you.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
very sorry...
i guess my wording could have been better. sorry about that.
Someone woke up on the wrong
Someone woke up on the wrong side of the bed? I think he was merely providing a suggestion on what he thinks benefits drupal.org and the drupal community.
no
killes is know for his userfriendlyness :-) oddly enough, both parties are right.
As a community we ought to close old bug reports together, it's the task of all of us at drupal.org.
As a website (drupal.org) promoting drupal, we should not scare potential users with (closing) bugs.
I think the current posting is good for the community and not too bad for potential users, So all in all, promoting this posting was a Good Thing.
Now lets get back to closing this topic and some bugs...
no offense killes :-)
--
groets
bertb
--
groets
bert boerland
now...
Oh no, a software with bugs! Oh horror, hide your children and run for your life!
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
quote
i think when you would have quoted the complete sentence (As a website (drupal.org) promoting drupal, we should not scare potential users with (closing) bugs.), it would not have been out of context.
and yes, mother take your children to a safe place, drupal has bugs! :
--
groets
bertb
--
groets
bert boerland
devel site
I agree that we need a separate development site. Let drupal.org be the fancy showcase page with a development block on it.
This would mean that as a developer I would not have to share space on the page for advertising Drupal -- the whole page could be development-related.
I'm sure this is under consideration with the move to the new infrastructure.
nope
You'd be wrong.
Why do we need a seperate site? And don't give me the showcase argument, I don't buy it. Right now, you hit drupal.org, you get what you see. Besides, no one really wants to adminster yet another site with already limited reliable resources. Right now there is no seperation of end users, site admins and developers.
We have people that transition between roles and don't even realize it currently. This is the point of a community site. Drupal.org is not only the software, it is the community. We would lose far more than we would gain.
-sp
---------
Test sites and good habits: Drupal Best Practices Guide.
Back Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
people who are scared away by "help us" may move on!
Please: this is OSS. If you are a person that only demands, wants or "would like"s to, lpease move on. This is OSS, meaning that we (yes! that includes you, yes, you too. No, don't look away, I am talking to you too) build this together.
If you do not like this, then please buy a CMS, where you can demand support, where you can sue the developers if they broke your project-planning. Then pay for features and buy security. We cannot offer that. We are a community (yes, that includes you) that build a CMS. And "building" can be anything. Also closing bug reports and issues!
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
to reword...
sorry... it looks like the way i presented my thoughts has got things off on a wrong track.
firstly, i posted that comment because i truely love drupal and the oss community it is building and want to see it do as best it can, and was therefore motivated to share what i thought was a problem.
i wasn't really try to demand anything for my sake, and completely understand what you're saying about drupal as an oss project.
i also really love how open the whole site is, how much participation druapl supports, and its amazing to see the number of modules there. (although i'm not sure if publishing so much detail of the server backend is such a good idea for security). persoanlly, i can't wait to jump in once my php skills are up to it.
anyway, what i was trying to say is that many people who come to the drupal front page wont be interested in developing straight away, and in fact might be turned away from drupal if they see that on their first visit they're being asked to pass off bugs.
i thought it would've been good to have the front page promoting drupal and the entire community, and then another development front page that could serve as a focus for people interested in development.
.. but, then again, it is great how you really feel part of the community as soon as you arrive at druapl.
hope that clears things up a bit.
heh
It's not a problem.
http://en.wikipedia.org/wiki/Security_through_obscurity
It's a fairly standard time proven design. Many other large projects survive just fine releasing this infomration. :)
Welcome to the community, your start is just fine. Others have gotten off to similier and no worse for wear.
As to multiple sites, etc... we run into resource contstraints. There are only so many people that actively participate and for some of them, do we want them to develop or administer? :) Also, if everyone has to look at the same stuff, sometimes someone is motivated to fix it.
Let's get some bug reports closed.
-sp
---------
Test sites and good habits: Drupal Best Practices Guide.
Back Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I like the openess
I personally like the openess that there are bugs. I think it is in the interest of a beginner to know there are bugs and that they are handled by all. I would be against publicity talk that hides problem areas. It seems more honest and helps to truly evaluate Drupal.
The statement that all can help to debug shows that all are heard here, that all have a part to play. It is shows that Drupal is more then just some software; there is a community around it.
It would be bad publicity when nobody decided to help out and the long list of open (outdated) bugs would just remain. It would show there is no real community.
cjm, not personal!
cjm. that was not meant as an attack to your comment. But to all the people who in general think and state that bugs/development is for developers. I wanted to make the point that we ALL are developers in an OSS project.
Those who do not like that idea, simply do not belong in a developer community, but should move along to services like bryght, or other consultants. places where they add value by paying or fundring development.
Sorry to sound rude. but simple users, people who only use an OSS suit are no good to the community. They use our time and infrastructure while giving nothing back. That is fine, if it remains below a certain percentage, Then the average value of the community goes up, when there are more users. but really, I am not looking for people who only download drupal, ask support, and then leave forever. they simply don't add value, only slow down drupal.ogr for you. people who take the time to comment and add value!
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
dont do it
Do not do it, its only a waste of time. Most drupal developers and projects do not care for bug-reports. Even patches are not considered most of the time eventhough they are nicely programmed ...
Contrib?
I assume you're talking about contributed modules... because core's patches and bugs are followed up closely. As far as contributed modules go, they are up to the maintainer of the project. If you see a project that is no longer maintained, you are free to take it over.
--
If you have a problem, please search before posting a question.
less then helpful
chx is a core code contributor. He is asking for the communities help on core code. Your comments are less then useful or helpful. Patch acceptance here is done over time and through discussion. If it is a contributed module (actually any module) then you need to get the maintainer of that module to agree to it as well.
If something you submitted is rejected, explain it better or refine the code to account for the critique.
-sp
---------
Test sites and good habits: Drupal Best Practices Guide.
Back Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
crac, please!
crac, I searched the issues, might hae missed some, but teh only issue i could find is the one about the image galleries not validating XHML. (http://drupal.org/node/24365)
Robrechtj treated you really nice there. He was carefull when closing the bug and even politely asking you to reopen it if you had more information.
So please. Leave your personal grievances off these frontpage posts and take then to the issues where they appeared, or even mail the mailinglists if you think you were treated wrong. But please do not tell others to not close issues, because you feel you were treated injust.
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
There are ways ...
.. to improve the bug-reporting and testing; one could have more accessible ways than just checking out a CVS snapshot of HEAD.
I think developers care for bug-reports, but might not always have the time to correct them.
Therefore it might be better with "more hands" as chx put it in his original post. One way to get more hands would be to further streamline the bug-reporting functionality as well as better labeling of test-snapshots.
With more eyeballs comes more activity, more patches and better progress - for the benefit of all.
block module revised
I just check the pending bug reports of block module.
I didn't change the status yet of the bugs, because I'm waiting for someone else to review them again (or maybe for their authors to respond), I would have another look at them next week, but I think they can be all closed (with a little patch I submitted).
From a "simple user" point of view.
I consider myself "a simple user", but would welcome the opportunity to help in any way. Even us "simple users" can help by closing out our own issues that have been resolved, or otherwise no longer are necessary to keep open. We also can help other users by sharing the solutions we have found with them thereby allowing THEM to close their own. What is the big deal? If you have a problem with response time or being asked to help, you shouldnt be here at all. PAY someone to fix your problems, Pay them to listen to your whining!
I have posted issues and waited for responses, sometimes less than patiently, BUT I appreciate all the help this community of developers give FREELY. As frustrating as it is to have to wait for someone to help, we should not forget these folks are doing this on their own time, they have jobs, families and lives. Asking for a bit of help to clean up things shouldnt be such an issue.
Someone considering Drupal will not be scared away by a "help us". It reiterates that this is a "collaborative project" to which it should be EXPECTED that people will help where they can, no matter how small the contribution.
Re: Help by closing or verifying old bug reports
Perhaps we should set aside a day for cleaning up the issue queue? I posted something throwing up the idea of a bug day where we would either spend the day squashing bugs or just evaluating bugs (or both), but I must've posted it to the wrong forum (infrastructure) since I saw no responses (http://drupal.org/node/27092). I was primarily interested in a bug day for the contributions, but perhaps the core issue queue could use one as well.
But how about it? We could routinely, maybe on a monthly or bi-weekly basis, have a day where a bunch of us meet up in the IRC channel and plow through all the bugs and clean the issue queue of issues that are not outstanding.
Ankur Rishi
(CivicSpace)
Developer releases ...
As discussed in the Drupal Developer releases thread , a way to get "more hands" would be a systemic improvement of the current way to setup a test environment, as well as improvement to the bug reporting.
Having fixed automatic builds of Drupal HEAD snapshots will help a lot in getting "more hands", more bug reporting and bug discussions; in other words - lead to an even more active Drupal community capable of resolving more issues.
That way the "don't need programming skills" can be extended to "don't need programming nor CVS skills".