Hi All I'm sure most of you are aware that on May 10 (us time), PTFS made a whole pile of their hitherto private changes public in the form of a public git repo. Galen (as Release Manager for 3.2) has gone through them and marked the ones that are able to be included in 3.2 and in fact in the last day we have integrated most of those. But since we are well inside feature freeze, the new features need to wait for 3.4 (along with everyone else's new features). So it becomes part of my responsibility (as RM for 3.4) to work on the integration of them, new features from everyone else, and to make sure the work on things like C4::Search, C4::Languages, DBIx::Class, etc which are slated for 3.4 doesn't get lost. To that end, we have a wiki page http://wiki.koha-community.org/wiki/PTFS_Harley_Integration where we will be tracking integration. What my plan is, is to get each of the features isolated into a branch based off master. Then QA (Colin) can look at them and make any recommendations needed. Once they pass QA, then I will apply the usual RM rules: does this feature or bugfix cause any regressions, does it change the default behaviour in unexpected ways, and so on. Then if problems are found they can be fixed and the code resubmitted for inclusion. Just to reiterate, there is no special treatment involved here, the same rules that apply for every other developer apply, what makes this different is that there are just a big pile of commits to work through at one time. Here is a feature branch that I have created by cherry-picking the relevant code from the ptfs/Bug3469 branch. http://git.koha-community.org/gitweb/?p=koha.git;a=shortlog;h=refs/heads/new... I'm hoping that PTFS can help creating these branches, but anyone can do so at let me know where to pull from. They need to have the changes isolated if possible and be based on new_features. (Which at the moment tracks master). The faster we can get these feature branches created, the sooner we will be able to step through the next parts of integration. If there are dependencies - and I have been warned granular permissions is a prerequisite for a lot of the new features - this should be noted clearly on the wiki page. If we have the features isolated as much as possible, then they can be integrated independently, which would mean that one features' failure to meet the test for inclusion would not stop all the others being included. So this is our first step. It also allows people to merge that feature and test it only. Looking forward to having many of you helping create these branches :) Chris Cormack RM Koha 3.4
Thanks a lot to PTFS for contributing back to Koha its customer's code.
I'm hoping that PTFS can help creating these branches, but anyone can do so at let me know where to pull from. They need to have the changes isolated if possible and be based on new_features. (Which at the moment tracks master).
A very valuable and detailed documentation is available in "Harley": http://github.com/ptfs/Koha-PTFS/raw/harley/HarleyReleaseNotes.pdf It would be great if PTFS technical redactor who edited this precious document could cut-and-past its content per new functionality into Koha wiki. For the future, new functionalities developments could follow this path: 1. Specifications are published on Koha wiki in RFC section. 2. Developers design, code, test and validate with sponsoring library. 3. Then a "developer level" documentation is published on Koha wiki at the same time the code is proposed to the RM. 4. After integration of new code to main Koha, the Documentation Manager documents the new functionality based on the wiki documentation. This process would avoid having orphan functionalities without any documentation or with incomplete documentation. -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html
On Wed, May 12, 2010 at 1:20 AM, Frederic Demians <frederic@tamil.fr> wrote:
Thanks a lot to PTFS for contributing back to Koha its customer's code.
Ditto from me!! It is awesome to see so many new developments made public for all to benefit from. [snip]
This process would avoid having orphan functionalities without any documentation or with incomplete documentation.
Better yet, this process makes it so that other developers don't start working on the same functionalities - having everything documented up front makes it so that each developer can seek sponsorship for a new feature instead of doubling the work that another developer is already doing Thanks Nicole C. Engard
Re: "1. Specifications are published on Koha wiki in RFC section." in your message. At and after Kohacon last year, the general understanding for developers was that new development should be posted in bugzilla as enhancements instead of to the wiki RFC, and that's the procedure we followed. Most of the bug reports for these features have been in bugzilla since last summer. Has there been a change/reversion in procedure? Or has this question ever been resolved? 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 -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Frederic Demians Sent: Wednesday, May 12, 2010 1:21 AM To: Chris Cormack Cc: koha-devel Subject: Re: [Koha-devel] Integrating PTFS code into 3.4 Thanks a lot to PTFS for contributing back to Koha its customer's code.
I'm hoping that PTFS can help creating these branches, but anyone can do so at let me know where to pull from. They need to have the changes isolated if possible and be based on new_features. (Which at the moment tracks master).
A very valuable and detailed documentation is available in "Harley": http://github.com/ptfs/Koha-PTFS/raw/harley/HarleyReleaseNotes.pdf It would be great if PTFS technical redactor who edited this precious document could cut-and-past its content per new functionality into Koha wiki. For the future, new functionalities developments could follow this path: 1. Specifications are published on Koha wiki in RFC section. 2. Developers design, code, test and validate with sponsoring library. 3. Then a "developer level" documentation is published on Koha wiki at the same time the code is proposed to the RM. 4. After integration of new code to main Koha, the Documentation Manager documents the new functionality based on the wiki documentation. This process would avoid having orphan functionalities without any documentation or with incomplete documentation. -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On Wed, May 12, 2010 at 9:01 AM, Jane Wagner <jwagner@ptfs.com> wrote:
Re: "1. Specifications are published on Koha wiki in RFC section." in your message. At and after Kohacon last year, the general understanding for developers was that new development should be posted in bugzilla as enhancements instead of to the wiki RFC, and that's the procedure we followed. Most of the bug reports for these features have been in bugzilla since last summer.
Jane, I do remember that now that you mention it!! That said, the 3.4 RFCs are already on the wiki - well are being moved to the wiki: http://wiki.koha-community.org/wiki/RFCs_for_Koha_3.4 So, I too ask what the procedure is - should we put them on the wiki & bugzilla? or just the wiki? or just bugzilla? Nicole
Hi, On Wed, May 12, 2010 at 9:04 AM, Nicole Engard <nengard@gmail.com> wrote:
So, I too ask what the procedure is - should we put them on the wiki & bugzilla? or just the wiki? or just bugzilla?
Both - the bugs database and the emailed RFCs and wiki serve slightly different purposes: * bugs database: complete database of all bugs and enhancements and (via the voting mechanism) a way of gauging interest in a new feature * RFCs - emailed announcement of major new development to solicit feedback on the feature and its design and implementation and to help find anybody who has parallel work underway * wiki - summary of RFCs, another spot to hash out architectural issues, and ideally a starting point for the release notes. This approach does have some redundancy, but that redundancy is a feature, not a bug, as it were. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
Okey Dokey, all of the 3.4 RFCs have been moved to the new wiki: http://wiki.koha-community.org/wiki/RFCs_for_Koha_3.4 -- please add any that are missing there. Nicole On Wed, May 12, 2010 at 9:14 AM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Wed, May 12, 2010 at 9:04 AM, Nicole Engard <nengard@gmail.com> wrote:
So, I too ask what the procedure is - should we put them on the wiki & bugzilla? or just the wiki? or just bugzilla?
Both - the bugs database and the emailed RFCs and wiki serve slightly different purposes:
* bugs database: complete database of all bugs and enhancements and (via the voting mechanism) a way of gauging interest in a new feature * RFCs - emailed announcement of major new development to solicit feedback on the feature and its design and implementation and to help find anybody who has parallel work underway * wiki - summary of RFCs, another spot to hash out architectural issues, and ideally a starting point for the release notes.
This approach does have some redundancy, but that redundancy is a feature, not a bug, as it were.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
participants (5)
-
Chris Cormack -
Frederic Demians -
Galen Charlton -
Jane Wagner -
Nicole Engard