XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk
  1. Board index / 
  2. Xoops Development / 
  3. Xoops Development 
  4.  / How to handle bugfixes short term after release version
Register
1
Bender
How to handle bugfixes short term after release version

  • 2004/6/18 9:47

  • Bender

  • Home away from home

  • Posts: 1899

  • Since: 2003/3/10



I just take this discussion up from the comments of the release of XOOPS 2.0.7 into the forum because i think its worth discussing it:

Quote:
stewdio wrote
Now to ramble a little off topic if I may...

I would also like to suggest at this time, that we start a new download section for quick fixes and separate files that have been changed.

Sometimes a fix is in place, yet users have to search high and low (through this site, sometimes with no success) just to edit what ever file they need to fix. Most fixes do not warrant a new release of all the core files (or an upgrade), but it would be extremely helpful to those that are not comfortable with editing php code (even if it's just copy/paste).

Sometimes it's much easier to just point to a file for download so that they can be fixed. The fixes are all here on the boards, but they are impossible to find (for some), or they are lengthy at best. With each new release, a new download section should be created for placement of quick fixes and other files. Yes, it's (dup)replication, but it's also convienent for new comers not familiar with the development mindset and Sourceforge stylings. It also makes everyone life easier in a reply; Yes, you can download the fix for this here.

A more robust tracking system and user friendly page should be created on the mainsite, away from the intimidating (to some) Sourceforge site. Not everyone uses the tracker nor should they be forced to, although it is highly encouraged.

I've been told numerous times to use the tracker, even for small stuff like this suggestion. I just can't be bothered, it feels like way too much effort. Alas, I'm lazy, but there are others who may find this step confusing, and I'm getting off track.

It's a long road ahead and I would rather not have to wait until a full point upgrade has been released. Yes, there's CVS and Sourceforge, again, confusing for some. (Although not for me) Just something to consider in the name of convienence and consideration for new users and veterans alike.

</2cents>

I know I went on a little bit much there, saying more then I should have, or maybe not saying or clarifiying what I want to say properly. Anyway, it's there as it is, merely a suggestion to make the XOOPS experience all that much easier for this great community we have here. Take it with a grain of salt, nothing serious was intended.

Cheers all
Happy XOOPSing!


Quote:
Herko replied:
Stew: your idea of quick fixes is basically releasing patches on a per-bug basis. And as you can see in 2.0.7, some bugs are more complex and can't be fixed quickly. Also, it will confuse a LOT of users as to what their version is, and what they should update when a bugfix release comes out. In fact, it would only begate the purpose of a version and bring chaos to the upgrade process.

As you can read here, some fixes are very server/php/OS specific, and a quick fix section will definately not help in that department. I forsee chaos...

If you can't be bothered to edit a file, or report a fix to sourceforge.net, I suggest you use a propietary system, as upgrading (if any) is mostly done with a few clicks. Part of working with an Open Source product is it's accessibility and community interation (can't believe I'm telling you this), and it's just how this thing works...

Herko (a bit disappointed)

2
Bender
Re: How to handle bugfixes short term after release version

  • 2004/6/18 9:47

  • Bender

  • Home away from home

  • Posts: 1899

  • Since: 2003/3/10


and now .... the conclusion. [size=x-small]/* watching too much Star Trek[/size]



Well i understand (in a way) Herkos dissapointment and in another way i am partly with what Stewdio wrote.

Actually i was about to do a posting anyway concerning the bugfixes but it hasn´t really matured in my mind (which it still hasn´t). I think there are two things here to think about. First one is how easy should XOOPS updating/bugfixing be for the enduser and second one which audience is targeted by xoops.

For both points we should have a look what kind of users are there now and what is their behavior. I think we have at least the following 'types':

- several techie people with knowledge in webservers, php, sql. Those are following the forums constantly and easily apply changes, hotfixes and so on to their system.

- several people with basic understanding in the afforementioned things but they are usually not in the business of writing code themselves. Most of them will follow the forum/news regulary.

- another group of people using xoops, having an idea what the basic things are XOOPS is based on but finally they are endusers. They are happy when their XOOPS installation worked and then just use the functions offered by XOOPS and additional modules. Those will follow the forums/news randomly. Most times when they run into trouble or are looking for additions to their system

- a group of real beginners. They found their way to XOOPS by random and will just play around with it or maybe a friend talked about it or installed it for them. They don´t have a real idea what php/sql are and how a webserver works. They might start too read the forums/news but don´t understand many of it so they won´t stay there too long.


The question how to handle the bugfixes after release of a new version should be based on the question where the line will be drawn in the targeted audience.

My personal opinion is that the required level of the usergroup should be quite low. Obviously there is somewhere a point where the needed afford doesn´t justify targetting a group. But open source is getting to a point where it adresses more and more the general public and tries to replace commercial products. Therefore open source has to adress the problems that come with that. And that after all is support for not so techie people too. And to look at it from the other site: It´s not only about giving to the people. There are quite a lot of people that can´t contribute with code but have other skills instead. Like in graphics or just suggesting features to improve XOOPS in many ways.

So back to the starting point of how to proceed with adding the bugfixes to the actual 2.0.7 release.

My suggestion:

As noticed i don´t have a concept that really covers my own expectations of easy following up. At this moment i would suggest to have a page 'Important release notes' which lists the required/advised changes since the release of the last version. Having a short description of the problems found, of the steps a user has to take to fix it and a source link to the corresponding discussion in forums/comments for the issue. Also a list of known bugs should be added there.

Also depending on the number of bugs or problems found over the next some weeks in 2.0.7 it should be considered to either have a subversion like to 2.0.7.1 or a 2.0.8 release. I don´t see that as a neccessarity yet but on the other hand it would make life easier for new people and also for those not so conveniant in file editing.


3
m0nty
Re: How to handle bugfixes short term after release version

  • 2004/6/18 10:56

  • m0nty

  • XOOPS is my life!

  • Posts: 3337

  • Since: 2003/10/24


whilst i agree in some ways with bender and stu.. i agree with herko too.

some bug fixes are more technical and require lots of changes to many files, and unless they are a major bug that stops something working completely or it's a security issue then i think it shud be reported but is ok to wait till a next release version when many bugs collected over the months should be included in a new release.. maybe a upgrade version once every 6 months if need be.. which will cover the majority of bugs discovered in the previous 6 months..

obviously secuirty issues need to be resolved as early as possible if it's a risk..

but small bug fixes can be tedious and doesn't really affect all users as it depends what the users conditions are.. platform, os, modules installed etc.. the majority of problems people report are for module probs and not so much XOOPS core..

and out of the majority of posts dealt with that i have read in the last 6 months, i lost count the amount of times module developers, XOOPS developers and even myself and lots of others have repeated ourselves explaining the same problems, because a lot of people don't use the search function as they should do to find if the topic has arisen before.

if u open a section dealing with bug reports who is going to a) keep it up to date, b) search round and post relevant forum links to topics involved and generally organise it? the developers themselves can't really be asked to do that as they have a life outside XOOPS too along with needing to concentrate on developments. agreed if a problem arises they are around to offer advice and fixes..

a system like ur asking wouldn't last long because people are people.. even if there's a topic in front of them saying for example: agendax upload problem. they still go ahead and start a new topic different title but same problem.. the problem cud have been answered and fixed in the other thread but the developers or whatever then have to answer the same question, or then search for that link again to direct em to the other thread..

I think a better way would be to try and employ a method of getting users to be aware and start using the search function more..

and now i'm rambling.. but thats me with lack of sleep in 3 days.. i guess this thread is gonna turn into a long read for people.. lol
4
tl
Re: How to handle bugfixes short term after release version

  • 2004/6/18 13:30

  • tl

  • Friend of XOOPS

  • Posts: 999

  • Since: 2002/6/23


Quote:

m0nty wrote:
...

I think a better way would be to try and employ a method of getting users to be aware and start using the search function more..



Couldn't have said it better.

But you never know, even the relavent thread were right under the nose, people would start a new thread.
5
kahumbu
Re: How to handle bugfixes short term after release version

  • 2004/6/18 15:16

  • kahumbu

  • Documentation Writer

  • Posts: 277

  • Since: 2003/8/23


At the risk of over-generalization, we find major 'public' problems with release versions from the actions of those too eager to update but lack enough skills (PHP or XOOPS) to really know what they are doing.

I feel that those who have used XOOPS for some time know enough to test release versions on test sites or local setup. It is not meant for the weak of heart.

I have a local setup that serves as a backup of my site. I also use it to experiment with new modules and upgrades, if I have the time. If I find some errors or bugs, I would definitely report it here. But if I don't have time, I usually wait for some bug reports here. Nobody should immediately upgrade their live site just hours from a new patch release, unless they know what they are doing.

This is not to undermine the devs efforts. I could feel the sense of accomplishment from the devs when they released the new version. But all products have to be tested and, as with most open-source, the community does the testing. XOOPS is actually lucky that a bug was found hours after release. It was easy to pull back without widespread damage.

New XOOPS users should be aware of the community testing phase of open-source, especially for release versions. It is not like proprietary software or an anti-virus software where you can just click a button to update virus defs.

For the other issue of old problems answered but continually re-surface, we are hoping that some good documentation would minimize that--and the Documentation team is hoping to make contributions in that aspect.

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

91 user(s) are online (60 user(s) are browsing Support Forums)

Members: 0

Guests: 91

more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits