Re: some action

Anatoly Techtonik wrote:

Hello Lukas,

I am splitting up my answer two. My idea was to promote this all as a single action, but the details can be worked out separately.

LS> As documenting things is likely to bring up some questions or even bug LS> reports due to closer examination of special cases this will be followed LS> up by a "developer appreciation" bug hunt. Where developers can adopt LS> packts of 5 open bug reports. The bug packages will be put together by LS> the QA team and should be coherent (either on a specific package, or a LS> specific issue spanning multiple packages etc). Developers are of course LS> free to pick up more bug packs. From that description it seems that vehicle was already invented before us. It is trackers. Otherwise it is not clear for me what is "bug hunt".

The idea is that we have 340+ bugs in the bug database. That number is likely to increase with the documentation event. The php QA team has had the same issues and have organized bug hunts for this purpose. Its just giving people a sizeable piece of work with the gratification of success lurking relatively closely. <offtopic>

Again you can call for brainstorming for specific package, but since existing PEAR developers are too busy, you need to redefine rules and principles for PEAR authorship, maintaining and participation to incline towards "community" or "society" than to "individuality" or "ownership". To me you pretty much contradict trying to guard code from "others" (non-developers) and bugfix it with the help of these "others" at the same time.

This issue is unrelated to my proposal. What you are talking about is reorganizing the very fundaments of PEAR. That will never happen. It would be a waste of time too. If the current PEAR model is so fundamentally flawed it should be replaced and adapted. We are not a nation. We are just a loosly coupled bunch of developers that happens to have a strong relation to a pile of code. However we can easily venture elsewhere and certainly people can easily take our code. Its much easier to start from scratch then to have PEAR reinvent itself in a different form. </offtopic>

Although wiki is good as information storage it is hardly automated to provide notifications, bug status refresh and other things. It is also not a source for trustworthy information, which can be misleading and deprecated. User notes are much better this way.

Maybe I wasnt clear. But the wiki will solely be used to manage the event. Actual bug reports will remain in our bug tracker and so will the discussion of that bug.

LS> Also lead maintainers are allowed to opt out with their packages. Those LS> who dont opt out allow the person who took up the pack to mess around LS> with the bug report etc. They dont grant that person to mess with CVS LS> though (although they may do so if they wish), so the person handling LS> the bug pack should submit patches inside the bug report. That is more interesting. What if to think about it without wiki? What is "to take bug pack"? Even now users can freely commit patches to bureporting system, where they stored for quite long time before being noticed by some sympathetic person from current PEAR developers. What problems do you want to solve with these "bug packs"? To me problem with opened bugs is in lack of contributors and not in rules deficiency.

The idea is to get some momentum. The idea also is to ensure a somewhat reliable quality. I try to implement patches quickly, but they often need adjustments. They rarely follow the PEAR CS or common PEAR standards and development methods. However they do help in the logic bugs. So it would be great for a lead to know that the standards, PEAR CS and logic are all solved. This will mean that its actually a time safer for developers. Also the idea is to focus the efforts on bug reports for which the lead maintain is actually receptive of patches.

You can always make changes in separate CVS branch and merge that later. I can't see wiki role in this process. There is no even system to attach patches to bugreports and safely view them.

Personally I find branches of little help. They just make everything very confusing especially for end users checking out bug fixes in CVS or viewing files on cvs.php.net. regards, Lukas