Clarifying history of PTFS feature releases
I'd like to clarify a few things and clear up some misconceptions about PTFS's existing code releases (including the Harley features) that have crept into this lengthy discussion. This is not meant to cover our future development and release plans; that's a separate discussion. But comments like the one below trouble me. -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Frederic Demians Sent: Wednesday, July 07, 2010 4:09 AM To: Chris Cormack Cc: koha Subject: Re: [Koha] Koha releases - Clarification/correction
Having said that, currently the 2 people rebasing the harley code (developed and released by ptfs, not inherited by anyone) are the 3.2 and 3.4 release managers, while dealing with patches and branches that don't need to be rebased ...... slow going.
Does it mean that Galen (3.2 RM) and you Chris (3.4 RM) are working on Harley integration for PTFS for free? Please tell your kids, cats, wifes and mistresses to ask directly to PTFS for food, and keep up the good work. -- Frédéric ----------------- PTFS has always committed to releasing these features. We followed the development rules as they were established at the Koha conference in Plano last March -- I created bugzilla entries for each of our features to let everyone know what was in the works (roughly 70 in the end), updated bugzilla with details and screen shots, and used the bug number for the feature branches. Per the discussion at the Plano conference (since reversed), entering new features on the RFC page was not required. We tried very hard to get the development done before the code freeze for 3.2 (the first of September). Some of our features were released over the summer and are now in head, but we were unable to get the rest done, tested, and approved by the sponsoring customers before the code freeze. At that time and at several subsequent times, various members of the community including the release managers encouraged us to just put our branches out on a git repository and issue a git pull request; others would happy to help integrate them. When we finally had the features ready to go, I said so on the IRC, pointing out that there would be a delay in releasing because the features would have to be rebased to current head; with the LibLime acquisition and accompanying major development projects, our resources were stretched thin at that point. Again, I was encouraged by several people (you know who you are) to just put the branches out and there would be plenty of help integrating them. We were told that people were anxious to get the new features and didn't want to wait until we could allocate the resources to rebasing and updating. We (and others) made it clear at the time that most if not all of these features were too late for 3.2 but would be included for 3.4. We did exactly as we were advised -- we released the Harley features as individual branches (as well as an integrated install package). And we were praised highly for it at the time -- see the listserv archives and IRC logs from two months ago. Since then, I have talked with both Galen and Chris about integrating and I noted areas where there had been parallel development in head. Chris developed a tracking page, and as of last week at ALA, Galen told us he had a plan to proceed with the rebasing and integration. (At least I think that's what I heard in a very noisy exhibit hall.) I am at a loss to understand why everyone is suddenly bashing us for following the rules and the release path we were encouraged to use for these features. Other companies and developers have followed the same procedure (new features released on a public git repository) but that doesn't seem to be a problem, and those features have been updated and integrated. A project with roughly six times the number of patches as ours is currently being worked with resources volunteered by another company. Other development projects have never been entered in bugzilla and come as a surprise when they are submitted. Why is our process in releasing these features a problem? Speaking for myself personally, I am troubled by the repeated attacks on my employer for what does not seem to be any valid reason. This is damaging the reputation of the entity that signs my paycheck and pays my mortgage. It is also potentially damaging to my professional reputation as a project manager and developer associated with this company. Apart from the 70-odd major features in the Harley release, we have contributed patches ever since we began working with Koha, following the rules and our commitment to participation in the Koha project -- I have some 30-40 commits in my own name, let alone those from our other developers. We have also participated actively on the listservs, the IRC, and the various developer meetings. I understand that there are differences of opinion with PTFS on various issues including future releases, but these existing feature releases should not be one of them. In the next few weeks, we will be releasing a very large list of sponsored development items. Our intent with all our development is to release it when it is thoroughly tested and approved by the customers. I would very much like to clarify the desired procedures for announcing, releasing, and integrating large projects such as these. Jane Wagner Library Systems Analyst PTFS Inc. Content Management and Library Solutions 6400 Goldsboro Road, Suite 200 Bethesda, MD 20817 (301) 654-8088 x 151 jwagner@ptfs.com
I am at a loss to understand why everyone is suddenly bashing us for following the rules and the release path we were encouraged to use for these features.
Your recollection differs from mine and your clarification doesn't help much to gain in intelligibility. When July 2nd, Stacy Pober reported that: In the meeting, I asked how long they estimated it would take for the official Koha community to integrate the code once it had been released. First one Liblime staffer said two or three years and then another one said, 'more like four or five years'. We didn't hear you. It wasn't bashing at all, Koha community bashing, just a witty remark I suppose. So please avoid to cite my equally witty remark, authorized and justified by your and yours silence, in order to pose a victim. Take me apart and don't count on me to follow you there and elaborate more on that. Thanks. -- Frédéric
.
In the next few weeks, we will be releasing a very large list of sponsored development items. Our intent with all our development is to release it when it is thoroughly tested and approved by the customers. I would very much like to clarify the desired procedures for announcing, releasing, and integrating large projects such as these.
Well there are a few things, PTFS is the only company who does their own releases .. so i'll ignore that. But when submitting work for inclusion, it must be rebased upon the branch you want to include it on. Otherwise it simply will not apply cleanly. Now the longer it goes without a rebase, for example http://github.com/ptfs/Koha-PTFS/commits/Bug3474 is based on november 09 code. That is nearly 8 months ago and more than a 1000 commits ago. This needs to be rebased on current code, then tested before it can be accepted. Normally the submitter does the rebasing, to date for Harley, this hasn't happened. Hope this clarifies Chris
On 9 July 2010 06:52, Chris Cormack <chris@bigballofwax.co.nz> wrote:
.
In the next few weeks, we will be releasing a very large list of sponsored development items. Our intent with all our development is to release it when it is thoroughly tested and approved by the customers. I would very much like to clarify the desired procedures for announcing, releasing, and integrating large projects such as these.
Well there are a few things, PTFS is the only company who does their own releases .. so i'll ignore that. But when submitting work for inclusion, it must be rebased upon the branch you want to include it on. Otherwise it simply will not apply cleanly. Now the longer it goes without a rebase, for example http://github.com/ptfs/Koha-PTFS/commits/Bug3474 is based on november 09 code. That is nearly 8 months ago and more than a 1000 commits ago. This needs to be rebased on current code, then tested before it can be accepted. Normally the submitter does the rebasing, to date for Harley, this hasn't happened.
Hope this clarifies
Oh and replying to myself ... early in the morning, need more coffee :) I am more than willing to help anyone who wants to learn how I do the cherry-picking and/or rebasing, so that they can help out doing it to. It is so much easier for the people who wrote the particular feature, or bugfix, to fix conflicts as they know what they were trying to do, and which piece of code they should keep. If it's left up to me, I have to take my best guess. That is the reason its much better for the submitter to keep the code up to date with master. Chris
I am at a loss to understand why everyone is suddenly bashing us for following the rules and the release path we were encouraged to use for these features. Other companies and developers have followed the same procedure (new features released on a public git repository) but that doesn't seem to be a problem, and those features have been updated and integrated. A project with roughly six times the number of patches as ours is currently being worked with resources volunteered by another company.
This is untrue, the offer was for Catalyst to help out with community QA, if anything it will result in more errors being found and more work needing to be done by Biblibre. So the QA work is being done by Catalyst for the community, not for Biblibre, it is still their responsibility to rebase and send their patches in a form that can be integrated. However, since Biblibre have never tried to register a trademark in NZ on an indigenous word that is part of my heritage. And in fact have signed over the European Union mark to HLT as requested by the community. I count them as good friend and were they to ask me for help, I would happily give it. Chris
participants (3)
-
Chris Cormack -
Frederic Demians -
Jane Wagner