Re: [Koha] Koha releases - Clarification/correction
On Fri, Jul 2, 2010 at 1:01 PM, Stacy Pober <stacy.pober@manhattan.edu> wrote:
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'.
Very nice. An anonymous Liblime troll takes the opportunity to insult the Koha community. Look: Either PTFS/Liblime can integrate the code or not. The Koha community is not going to undertake any four to five year integration process. Anything that would take that long to accomplish would be easier done by starting from scratch.
Today, someone from Liblime contacted me to explain that the estimate of 4 or 5 years as the time for the community to integrate such a large amount of code was a "humorous ad lib comment" rather than a serious answer to my question
Perhaps someone from Liblime could sign up for the mailing list and start communicating directly? What seems clear from this exchange is that PTFS/Liblime believes that it is the responsibility of others to integrate their code into Koha rather than something that is inherent to the process of working on an open source project. If this is the case, then LEK and Harley are not trunks. They're forks. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
What seems clear from this exchange is that PTFS/Liblime believes that it is the responsibility of others to integrate their code into Koha rather than something that is inherent to the process of working on an open source project. If this is the case, then LEK and Harley are not trunks. They're forks.
Owen--how is that clear? When did anyone say that PTFS/LibLime believes that it is not their responsibility to integrate the code? I was at the very same meeting. LEK is a fork that PTFS inherited, yet I understood from the meeting that they are committed to contributing it to Koha, difficult as that may be. Nothing that they said about Harley led me to believe that they think it is the community's responsibility to integrate the code. I believe that there are several people at PTFS/LibLime who understand the process and they have already put a lot of work into Koha. I did take some notes at this meeting. Unfortunately I do not have access to them at the moment and they were not very detailed. I will take a look at them this weekend and see if there was anything useful that I recorded.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
2010/7/2 vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>:
Owen--how is that clear? When did anyone say that PTFS/LibLime believes that it is not their responsibility to integrate the code? I was at the very same meeting. LEK is a fork that PTFS inherited, yet I understood from the meeting that they are committed to contributing it to Koha, difficult as that may be.
I think that Owen is getting that from the summary that Stacy gave and the fact that Harley was was released not as a series of patches to Koha, but as a 'release' of it's own (actions speaking louder than words and all that jazz). At this time the only people integrating the code found in Harley to Koha are Galen and Chris - the release managers for 3.2 and 3.4. That was my understanding by the chart added to the wiki (http://wiki.koha-community.org/wiki/PTFS_Harley_Integration) and the information provided by Stacy. Of course it is always possible that things get lost in translation when coming from someone's notes to an email and I do agree with Owen that hearing things first hand instead of second and third helps a lot with that particular problem. Thanks Nicole C. Engard
On Fri, 2 Jul 2010, vtl@scls.lib.wi.us wrote:
From: "vtl@scls.lib.wi.us" <vtl@scls.lib.wi.us>
What seems clear from this exchange is that PTFS/Liblime believes that it is the responsibility of others to integrate their code into Koha rather than something that is inherent to the process of working on an open source project. If this is the case, then LEK and Harley are not trunks. They're forks.
Owen--how is that clear? When did anyone say that PTFS/LibLime believes that it is not their responsibility to integrate the code? I was at the very same meeting. LEK is a fork that PTFS inherited, yet I understood from the meeting that they are committed to contributing it to Koha, difficult as that may be.
Nothing that they said about Harley led me to believe that they think it is the community's responsibility to integrate the code. I believe that there are several people at PTFS/LibLime who understand the process and they have already put a lot of work into Koha.
both sides will need to work to integrate this functionality (or re-write it if that ends up being easier) having either side take the attitude that it's all up to the other side will only make the problem drag out longer. It's very unfurtunant that this problem is here, but the entities that decided not to merge the code earlier are no longer around, and it's far better to assume good intent on the part of their replacements than it is to punish the reaplacements for the bad actions of their predesessors. David Lang _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
2010/7/7 <david@lang.hm>:
On Fri, 2 Jul 2010, vtl@scls.lib.wi.us wrote:
From: "vtl@scls.lib.wi.us" <vtl@scls.lib.wi.us>
What seems clear from this exchange is that PTFS/Liblime believes that it is the responsibility of others to integrate their code into Koha rather than something that is inherent to the process of working on an open source project. If this is the case, then LEK and Harley are not trunks. They're forks.
Owen--how is that clear? When did anyone say that PTFS/LibLime believes that it is not their responsibility to integrate the code? I was at the very same meeting. LEK is a fork that PTFS inherited, yet I understood from the meeting that they are committed to contributing it to Koha, difficult as that may be.
Nothing that they said about Harley led me to believe that they think it is the community's responsibility to integrate the code. I believe that there are several people at PTFS/LibLime who understand the process and they have already put a lot of work into Koha.
both sides will need to work to integrate this functionality (or re-write it if that ends up being easier)
having either side take the attitude that it's all up to the other side will only make the problem drag out longer. It's very unfurtunant that this problem is here, but the entities that decided not to merge the code earlier are no longer around, and it's far better to assume good intent on the part of their replacements than it is to punish the reaplacements for the bad actions of their predesessors.
Hi David I don't think anyone is punishing the replacements for their predecessors, at least I am not. What I am reacting to is the policy that came out at the liblime users group meeting at ALA. Which states that code will be developed in isolation by PTFS, it will then go through a testing phase, and then liblime customers will get it for a period of 6 months. At that point it will then be placed in a public repository for the rest of the world. At no point in that plan is there any consideration for integration, or is there any recognition of the fact that for the code to have any value at all to the wider koha community that it would need to have been rebased off master at regular intervals. As in illustration, in the last 6 months of koha development, there have been over 1000 patches added to Koha. 2010-07 019 2010-06 103 2010-05 203 2010-04 120 2010-03 146 2010-02 305 2010-01 154 So let alone the time it takes to develop factored in, code based on Koha as it was 6 months ago, needs a significant amount of work to bring it up to a point we could even begin to merge it. What I am is concerned about is that PTFS are repeating the mistakes of their predecessors. There is still no commitment to send patches for the code in a form that can actually be applied. That sounds to me exactly like Owen describes. There is a rumour that a document describing the Liblime development procedure has been sent to the Liblime list, it would be wonderful if that could be made public so that our fears could either be allayed or confirmed. I would like nothing better than for PTFS to begin sending patches, or making feature set branches available in a usable form for the community to integrate, after all we have over 114 developers in the history of Koha, they seem to have managed to be able to do it. Chris
On Wed, 7 Jul 2010, Chris Cormack wrote:
From: Chris Cormack <chris@bigballofwax.co.nz>
2010/7/7 <david@lang.hm>:
On Fri, 2 Jul 2010, vtl@scls.lib.wi.us wrote:
From: "vtl@scls.lib.wi.us" <vtl@scls.lib.wi.us>
What seems clear from this exchange is that PTFS/Liblime believes that it is the responsibility of others to integrate their code into Koha rather than something that is inherent to the process of working on an open source project. If this is the case, then LEK and Harley are not trunks. They're forks.
Owen--how is that clear? When did anyone say that PTFS/LibLime believes that it is not their responsibility to integrate the code? I was at the very same meeting. LEK is a fork that PTFS inherited, yet I understood from the meeting that they are committed to contributing it to Koha, difficult as that may be.
Nothing that they said about Harley led me to believe that they think it is the community's responsibility to integrate the code. I believe that there are several people at PTFS/LibLime who understand the process and they have already put a lot of work into Koha.
both sides will need to work to integrate this functionality (or re-write it if that ends up being easier)
having either side take the attitude that it's all up to the other side will only make the problem drag out longer. It's very unfurtunant that this problem is here, but the entities that decided not to merge the code earlier are no longer around, and it's far better to assume good intent on the part of their replacements than it is to punish the reaplacements for the bad actions of their predesessors.
Hi David
I don't think anyone is punishing the replacements for their predecessors, at least I am not. What I am reacting to is the policy that came out at the liblime users group meeting at ALA. Which states that code will be developed in isolation by PTFS, it will then go through a testing phase, and then liblime customers will get it for a period of 6 months. At that point it will then be placed in a public repository for the rest of the world.
part of what I was responding to was in a message that I appear to have deleted where someone worded it as if the work to be done needed to be done entirely by PTFS. The point I was trying to make is that that attitude is also damaging (or at the very least it can significantly prolong the existing damage)
At no point in that plan is there any consideration for integration, or is there any recognition of the fact that for the code to have any value at all to the wider koha community that it would need to have been rebased off master at regular intervals. As in illustration, in the last 6 months of koha development, there have been over 1000 patches added to Koha.
2010-07 019 2010-06 103 2010-05 203 2010-04 120 2010-03 146 2010-02 305 2010-01 154
So let alone the time it takes to develop factored in, code based on Koha as it was 6 months ago, needs a significant amount of work to bring it up to a point we could even begin to merge it.
I fully recognise this fact. I'm used to thinking in terms of kernel development cycles (much higher rate of change, but also a bigger code base to have changes in)
What I am is concerned about is that PTFS are repeating the mistakes of their predecessors. There is still no commitment to send patches for the code in a form that can actually be applied. That sounds to me exactly like Owen describes.
that is a very valid concern, I'm in no way objecting to it.
There is a rumour that a document describing the Liblime development procedure has been sent to the Liblime list, it would be wonderful if that could be made public so that our fears could either be allayed or confirmed.
I would like nothing better than for PTFS to begin sending patches, or making feature set branches available in a usable form for the community to integrate, after all we have over 114 developers in the history of Koha, they seem to have managed to be able to do it.
agreed on both points David Lang
On 7 July 2010 19:09, <david@lang.hm> wrote:
On Wed, 7 Jul 2010, Chris Cormack wrote:
I don't think anyone is punishing the replacements for their predecessors, at least I am not. What I am reacting to is the policy that came out at the liblime users group meeting at ALA. Which states that code will be developed in isolation by PTFS, it will then go through a testing phase, and then liblime customers will get it for a period of 6 months. At that point it will then be placed in a public repository for the rest of the world.
part of what I was responding to was in a message that I appear to have deleted where someone worded it as if the work to be done needed to be done entirely by PTFS. The point I was trying to make is that that attitude is also damaging (or at the very least it can significantly prolong the existing damage)
Ahh, I think the email said, "It is the developers responsibility to send the patch in a format that can be applied" or words to that effect. IE, the developer should rebase against the branch the patch is to be applied to before sending the patch. Release managers have enough work to do without having to rebase and fix conflicts that they have to guess at the correct resolution for. 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. You can check the progress here http://wiki.koha-community.org/wiki/PTFS_Harley_Integration And the rebased branches are published here http://git.koha-community.org/gitweb/?p=koha.git;a=summary The code will eventually merged, but there's doing it the easy way, and doing it the hard way, this is the hard way, and I see no reason for it. Nor to have to do this all over again every 6 months. Chris
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
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. You can check the progress here http://wiki.koha-community.org/wiki/PTFS_Harley_Integration And the rebased branches are published here http://git.koha-community.org/gitweb/?p=koha.git;a=summary
The code will eventually merged, but there's doing it the easy way, and doing it the hard way, this is the hard way, and I see no reason for it. Nor to have to do this all over again every 6 months.
Why are you rebasing the harley code into 3.2? It was my understanding that PTFS knew it was too late for the code in harley to be included in 3.2, but that it could be integrated properly into 3.4. That is why it was released in its entirety for now rather than as patches. Also, I believe that code will be released more frequently from PTFS than every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first. However, I believe their release cycle will be more frequent than 6 months (though I don't remember the frequency). How do other vendors develop their code? What is harely if it is not a branch? Is it not considered a branch because it has not been rebased since October? (These are sincere questions on my part.) Most of what I'm saying is based on memory of various conversations I've had so I hope I am not mis-stating anything. Vicki
Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
Why are you rebasing the harley code into 3.2? It was my understanding that PTFS knew it was too late for the code in harley to be included in 3.2
If Harley contains a bug-fix for an problem in 3.2 it's logical to try, if possible, to port the change over. Anyway, since Galen and Chris are two of the smartest guys I know I think I trust them to know what they're doing.
Also, I believe that code will be released more frequently from PTFS than every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first.
Why limit testing to customers for any amount of time except to exclude the rest of the world from having access to it as well? Why pass up the chance to get help from other developers and users in testing new code? Why keep the rest of the world in the dark about what developments are coming down the road so that others aren't working on fixes for the same bugs?
What is Harley if it is not a branch?
I might be possible to consider Harley a branch of 3.0.2 or some variant, but the fact that it includes so many changes, made over so much time makes it impossible to consider it a branch in the sense used by developers who are closely collaborating. Here's how I use branches, based on the advice I've received from my fellow developers. For each bug fix or feature I create a new branch from the very latest version of Koha available in our version-control system. For instance, here's a selection of my current working branches: ip-canbookberenewed-2010-02-05 ip-opac-holds-messages-2010-05-10 ip-transferstoreceive-2010-02-17 master ps-Bug-2981-alternate-solution-2010-05-18 ps-Bug-3459-topissues-2010-06-29 ps-Bug-3721-Lists-missing-2010-06-28 When I first sit down to work I create a branch with a prefix "ip-" for "in progress," give it a short title and bug number if I have one, and add the date I started working on it. Once I have finished my work and submitted a patch I rename the branch with "ps-" for "patch sent" and keep the branch until my patch is approved (fingers-crossed). All this is on my computer in a virtual machine, so in my case I'm not being open as I might. If I had the resources to work on a real server, or if I kept my work on a service like GitHub I could share all these branches with everyone, from the time I first started working on it to the time my patch was submitted. If some time has passed and I see that my patch from one of my "patch sent" branches hasn't been approved I'll switch to that branch and rebase: I'll tell git, the version control system, to grab the most recent Koha commits and merge them with the changes in my patch. If not too much time has passed, or the files I changed haven't been worked on by others the rebase will be successful and I'll know I'm still on track. If not I might have to manually make changes to my original commit so that it fits in again with the work others have been doing. I can't submit a patch and expect it to automatically work a month from now, a week from now, or even a day from now. I'm responsible for keeping up. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
2010/7/7 vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>:
Why are you rebasing the harley code into 3.2? It was my understanding that PTFS knew it was too late for the code in harley to be included in 3.2, but that it could be integrated properly into 3.4. That is why it was released in its entirety for now rather than as patches.
Harley is not being rebased over "3.2". Rather it is being rebased over the current HEAD (the tip of the trunk so to speak) which also happens to be the codebase that 3.2 stable will be branched off of. For clarification: 3.2 stable will not include Harley features afaik. What I describe is being accomplished using standard, good development practices and maintaining various Harley integration branches which are, in turn, kept rebased against the current HEAD. A basic understanding of Git version control would probably help clarify the answers to your questions.
Also, I believe that code will be released more frequently from PTFS than every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first. However, I believe their release cycle will be more frequent than 6 months (though I don't remember the frequency).
All of this us pure conjecture until we either a) hear from PTFS directly (Shawn, where are you?) or b) time reveals the truth.
How do other vendors develop their code?
In public git repositories. This has been discussed many, many times on the list. You may see many of them here: http://wiki.koha-community.org/wiki/Public_Git_Repositories
What is harely if it is not a branch?
Harley is at best a very dated topic branch off of some level of the trunk (read "master") back there somewhere.
Is it not considered a branch because it has not been rebased since October?
Technically, any branch is always a branch. However, as time and distance increase, it really becomes its own trunk (again, read "master") and so becomes nearly impossible to merge back into its ancestor without a very great deal of work. It is this "very great deal of work" that Chris and Galen are doing as they have time. And it is true that this work is work that the original developer's should have done if they were interested in being responsible members of the Koha community. Also, the work being done by Chris and Galen in this regard is work most devs would be expected to be paid for. By integrating Harley code back into the official master, these two are saving PTFS hours of labor and, of course, lots of dollars... all for "free."
(These are sincere questions on my part.)
HTH. Kind Regards, Chris
Thanks Owen and Chris for your detailed answers. I'll have to read these later, but they look helpful. I really didn't mean for my first question to be a challenge, it was a legitimate question. I know that Chris and Galen are smart guys. I even had the pleasure of working with Galen for a while. I really am trying to learn and understand this process (as I've been doing for the last two years). Vicki On Wed, Jul 7, 2010 at 9:26 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Why are you rebasing the harley code into 3.2? It was my understanding
2010/7/7 vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>: that
PTFS knew it was too late for the code in harley to be included in 3.2, but that it could be integrated properly into 3.4. That is why it was released in its entirety for now rather than as patches.
Harley is not being rebased over "3.2". Rather it is being rebased over the current HEAD (the tip of the trunk so to speak) which also happens to be the codebase that 3.2 stable will be branched off of. For clarification: 3.2 stable will not include Harley features afaik. What I describe is being accomplished using standard, good development practices and maintaining various Harley integration branches which are, in turn, kept rebased against the current HEAD. A basic understanding of Git version control would probably help clarify the answers to your questions.
Also, I believe that code will be released more frequently from PTFS than every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first. However, I believe their release cycle will be more frequent than 6 months (though I don't remember the frequency).
All of this us pure conjecture until we either a) hear from PTFS directly (Shawn, where are you?) or b) time reveals the truth.
How do other vendors develop their code?
In public git repositories. This has been discussed many, many times on the list. You may see many of them here: http://wiki.koha-community.org/wiki/Public_Git_Repositories
What is harely if it is not a branch?
Harley is at best a very dated topic branch off of some level of the trunk (read "master") back there somewhere.
Is it not considered a branch because it has not been rebased since October?
Technically, any branch is always a branch. However, as time and distance increase, it really becomes its own trunk (again, read "master") and so becomes nearly impossible to merge back into its ancestor without a very great deal of work. It is this "very great deal of work" that Chris and Galen are doing as they have time. And it is true that this work is work that the original developer's should have done if they were interested in being responsible members of the Koha community. Also, the work being done by Chris and Galen in this regard is work most devs would be expected to be paid for. By integrating Harley code back into the official master, these two are saving PTFS hours of labor and, of course, lots of dollars... all for "free."
(These are sincere questions on my part.)
HTH.
Kind Regards, Chris
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
OK. Thanks to Chris, Chris, Owen and Frederick I'm understanding this just a little bit better (tip of the iceberg really). Here's my $64K question. We are sponsoring a lot of features. We need these features when we go live at the end of the year. It's possible some of these features may make it into 3.4. But even if they do, it's not likely that 3.4 would be released in time for us and it would not include everything we need. So, then we are using something like Harley in the mean time, right? At the same time, our code would be rebased to Koha by our feature developers (not the RM). Is this a permissible scenario? By the way, I have looked at Chris and Galen's PTFS_Harley_Integration page and I am heartened to see that much of it is slated for 3.4. And I apologize for not understanding the process a bit better. On Wed, Jul 7, 2010 at 9:45 AM, vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>wrote:
Thanks Owen and Chris for your detailed answers. I'll have to read these later, but they look helpful.
I really didn't mean for my first question to be a challenge, it was a legitimate question. I know that Chris and Galen are smart guys. I even had the pleasure of working with Galen for a while.
I really am trying to learn and understand this process (as I've been doing for the last two years).
Vicki
On Wed, Jul 7, 2010 at 9:26 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Why are you rebasing the harley code into 3.2? It was my understanding
2010/7/7 vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>: that
PTFS knew it was too late for the code in harley to be included in 3.2, but that it could be integrated properly into 3.4. That is why it was released in its entirety for now rather than as patches.
Harley is not being rebased over "3.2". Rather it is being rebased over the current HEAD (the tip of the trunk so to speak) which also happens to be the codebase that 3.2 stable will be branched off of. For clarification: 3.2 stable will not include Harley features afaik. What I describe is being accomplished using standard, good development practices and maintaining various Harley integration branches which are, in turn, kept rebased against the current HEAD. A basic understanding of Git version control would probably help clarify the answers to your questions.
Also, I believe that code will be released more frequently from PTFS
than
every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first. However, I believe their release cycle will be more frequent than 6 months (though I don't remember the frequency).
All of this us pure conjecture until we either a) hear from PTFS directly (Shawn, where are you?) or b) time reveals the truth.
How do other vendors develop their code?
In public git repositories. This has been discussed many, many times on the list. You may see many of them here: http://wiki.koha-community.org/wiki/Public_Git_Repositories
What is harely if it is not a branch?
Harley is at best a very dated topic branch off of some level of the trunk (read "master") back there somewhere.
Is it not considered a branch because it has not been rebased since October?
Technically, any branch is always a branch. However, as time and distance increase, it really becomes its own trunk (again, read "master") and so becomes nearly impossible to merge back into its ancestor without a very great deal of work. It is this "very great deal of work" that Chris and Galen are doing as they have time. And it is true that this work is work that the original developer's should have done if they were interested in being responsible members of the Koha community. Also, the work being done by Chris and Galen in this regard is work most devs would be expected to be paid for. By integrating Harley code back into the official master, these two are saving PTFS hours of labor and, of course, lots of dollars... all for "free."
(These are sincere questions on my part.)
HTH.
Kind Regards, Chris
-- Vicki Teal Lovely
Helping our 52 member libraries provide the best possible service to the public.
ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
2010/7/8 vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>:
OK. Thanks to Chris, Chris, Owen and Frederick I'm understanding this just a little bit better (tip of the iceberg really).
Here's my $64K question. We are sponsoring a lot of features. We need these features when we go live at the end of the year. It's possible some of these features may make it into 3.4. But even if they do, it's not likely that 3.4 would be released in time for us and it would not include everything we need. So, then we are using something like Harley in the mean time, right?
Id hope 3.4 is released by Christmas, thats what I'm aiming for. They certainly wont make it into 3.4 unless the plan is changed though. Because 6 months from now is January, and since your features haven't been released to the PTFS users, the 6 month clock hasn't started yet. If they were sent as patches as they were done, no reason they couldn't make it into 3.4. Subject to passing QA of course.
At the same time, our code would be rebased to Koha by our feature developers (not the RM).
That would make it much more useful if, when it is submitted for inclusion for Koha, it is in a format that can be integrated it makes its' inclusion a lot more likely.
Is this a permissible scenario?
Having patches or branches submitted that are based off current master is a 1000 times better than code based on something that existed 9 months ago. I still think the 6 month lag is going to cause problems, but if PTFS are rebasing the problems are now theirs instead of inflicted on the community. If you can get them to buy into that idea, it would be great. The other thing that needs to be done is a migration path from Harley back to Koha, so that you can get back in the mainstream if you desire to.
By the way, I have looked at Chris and Galen's PTFS_Harley_Integration page and I am heartened to see that much of it is slated for 3.4. And I apologize for not understanding the process a bit better.
It would go a lot faster if there were some people who wrote the code helping with the rebasing, this is not aimed at any of the developers at PTFS, but rather at the people who tell them what to work on. Chris
Why are you rebasing the harley code into 3.2? It was my understanding that PTFS knew it was too late for the code in harley to be included in 3.2, but that it could be integrated properly into 3.4. That is why it was released in its entirety for now rather than as patches.
Galen rebases code into 3.2, enhancements or bug fixes of interest for the upcoming 3.2 version. And Chris rebases code into futur 3.4: that's rather new functionalities that can't be integrated into 3.2.
Also, I believe that code will be released more frequently from PTFS than every 6 months. It is just that any given piece of code is going to be tested by the PTFS customer base first. However, I believe their release cycle will be more frequent than 6 months (though I don't remember the frequency).
How do other vendors develop their code? What is harely if it is not a branch? Is it not considered a branch because it has not been rebased since October? (These are sincere questions on my part.)
What's required by release managers is not a unique branch per vendor, based on a 9 month old Koha code, but a branch per feature/bug fix. And each feature branch, as already explained by Chris and others several times, must be rebased regularly into current version of Koha. The 'rebasing' process has to be done by the feature developer. Rebasing means that you have to manage conflicts, merge portions of code, and so one. This task could be time consuming and mustn't be supported by release managers but by feature developer who has been paid to do his development and to contribute it back into Koha. -- Frédéric
participants (7)
-
Chris Cormack -
Chris Nighswonger -
david＠lang.hm -
Frederic Demians -
Nicole Engard -
Owen Leonard -
vtl＠scls.lib.wi.us