Hi all, Now that pierrick has retired as QA manager ... This email is to remind everyone that the 'stable' branch of Koha is so-named because it's supposed be the most 'bug-free' version of Koha. Especially since we're nearing the release of 2.2.6, it's very important that all commits don't break existing functionality. Please, I can't stress this enough, before you commit something, please test the function completely to make sure it works. Also, test any related functions that may be affected by your commit. This may take a few extra minutes, but it will save the rest of us hours of troubleshooting a so-called 'stable' branch. If you do happen to commit something that breaks Koha, please either fix the bugs immediately, or revert the code back to a working state. There's nothing more annoying than trying to troubleshoot someone else's buggy code. Remember, if you wrote something, it will take you much less time to fix a bug than someone else. As a further reminder, there are still 9 'blocker' bugs that we know about, preventing us from releasing 2.2.6. If you own these bugs, please try to either fix them or revert to the last working copy as soon as possible. (here are the blockers: http://tinyurl.com/fvfxw) Thanks, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro a écrit :
Hi all,
Now that pierrick has retired as QA manager ...
This email is to remind everyone that the 'stable' branch of Koha is so-named because it's supposed be the most 'bug-free' version of Koha. Especially since we're nearing the release of 2.2.6, it's very important that all commits don't break existing functionality.
Please, I can't stress this enough, before you commit something, please test the function completely to make sure it works. Also, test any related functions that may be affected by your commit. This may take a few extra minutes, but it will save the rest of us hours of troubleshooting a so-called 'stable' branch.
Joshua & me spoke of this on the chat yesterday (private channel don't search the logs) We are caught between 2 positions : - libraries that want Koha as it is, but bug free. - libraries that want -minor- new features, and they want them NOW. In 2.2.x branch, if you look at my release notes, I had announced when releasing 2.2.5 that it will be the last in branch 2.2 with new features. In the next weeks, I will release a 2.2.6 that has few bugfixes, and so many new features or major improvement. Let me list them quickly : - changes in MARC editor to handle correctly MARC21. The problem was small, the solution heavy (=need for XML packages...) - changes in acquisitions : libraries did not understand how receive worked. hdl added some features to create "parcels". they are nice, but introduced new problems - changes in serials to handle expected date & real receive date. It was requested, but introduced many new problems too. That's because of those new features that I released 2.2.6RC1 then 2.2.6RC2. You will note that I did not release 2.2.5RC1 previously ! so, I think joshua is right here : we must try to have a 2.2 branch as stable as possible. But I'm afraid we will stay between the hammer and the ??? (dunno the english word) for a while...
If you do happen to commit something that breaks Koha, please either fix the bugs immediately, or revert the code back to a working state. There's nothing more annoying than trying to troubleshoot someone else's buggy code.
Nobody (at least not me) commit something knowing it's buggy (or I say it in commit notes). But only heavy testing shows some problems. I just hope everybody will understand your mail as a reminder to be as careful as possible. At least, that's how I understand it & will take it for me.
Remember, if you wrote something, it will take you much less time to fix a bug than someone else.
for sure !
As a further reminder, there are still 9 'blocker' bugs that we know about, preventing us from releasing 2.2.6.
only 7 now, and i'll work on some this afternoon. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
Hi Koha core community, Joshua wrote:
Now that pierrick has retired as QA manager ...
I would like to give an external point of view, a kind of advice due to my experience on widely distributed project: on a stable branch, no new feature. Not even a single new field or anything. Only bug correction. I would even say: only trivial bug and blocking bug. Keep bug with workaround for next stable branch. This may sound crazy, but you must understand that if users agree to make many tests when migrating to a new stable release (eg from 2.2.x to 2.4.0), they certainly consider they can upgrade from 2.2.x to 2.2.x+1 without needing to check that the application still works. The real problem with this QA policy is the frequency of creation of stable branches. This is why a fixed length period of 6 months (more or less) between two stable branches is fine: each user know that she will have to wait no more than 6 months before having her feature made official. When a project has a variable length period between two stable branches, many problems come from the fact that users want their feature right now is the current stable branch because they have no idea how long they will have to wait before having it a new stable branch. Cheers -- Pierrick LE GALL http://le-gall.net/pierrick
Pierrick LE GALL a écrit :
Hi Koha core community,
Joshua wrote:
Now that pierrick has retired as QA manager ...
I would like to give an external point of view, a kind of advice due to my experience on widely distributed project: on a stable branch, no new feature. Not even a single new field or anything. Only bug correction. I would even say: only trivial bug and blocking bug. Keep bug with workaround for next stable branch.
Hi Pierrick, I agree with what you say, but you have forgotten one important point : we don't have users, we have ... customers ... And we can't limit our stable branch too strictly, otherwise our libraries won't adopt Koha. I frankly think we do what is the best : improving the software on the stable branch, with non-core features. I mean features that don't affect the DB schema. I decided to release Koha 2.0.0 3(?) years ago, not because it was bug free or feature complete, but because it was DB stable. Since 2.0.0, we added only 3 or 4 minor fields in the database, none of them being important. But now, the new deal is that 3.0 is not too far. So I think we should put our (limited) strengthes on it, and keep 2.2 as it is and just fix bugs. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
participants (3)
-
Joshua Ferraro -
Paul POULAIN -
Pierrick LE GALL