Just to throw in on this thread for ByWater Solutions: It is company policy to obtain at least one signoff from another staff member before submitting a patch to the community. We do not anticipate that this will be sufficient for inclusion into master (except perhaps on very simple patches), and hope other members of the community will sign off on our patches. We will do the same for others in the community as often as we can.
The end goal of all our development is inclusion into master. We are willing to do whatever the Quality Assurance manager and Release Manager need to make our developments worthy of inclusion (provided we can do so and still meet our clients' needs). If this means recoding in a more generic way, so be it. All our work is done on separate branches, based off the current HEAD of master, and rebased/merged as needed to keep it applicable. You can see it at http://git.bywatersolutions.com. It would be helpful to have some kind of general guidelines for inclusion (i.e. follow the coding style rules, have working unit tests, include relevant documentation, etc.), even if in the end, it's up to the Release Manager's expert opinion. Perhaps this is something we can discuss in an IRC meeting? We've started on this (and must continue) to post all our feature ideas on the wiki. I'd like those to be public, working "open spec" that anyone is free to edit and enhance until someone can sponsor all or part of the feature(s). Even if no library has the money to pay for the creation of these features right now, we can all figure out what they'd need to be in order to meet our needs, worldwide. Perhaps the unsponsored RFCs can serve as a rough roadmap for the longterm of Koha (beyond the next release). I think running a demo site with code that's partially through the Quality Assurance process, and soliciting librarian feedback would be a good idea, provided we could actually get librarians to take time to test a system that's not theirs. That's all for now. It's been great meeting so many of you at KohaCon and the following hackfest. I look forward to working together with you all to make 3.4 something great. Now, off to explore some more of New Zealand before I have to head home. Cheers, -Ian 2010/11/2 Chris Nighswonger <cnighswon...@foundations.edu> > On Tue, Nov 2, 2010 at 5:57 PM, Paul Poulain <paul.poul...@biblibre.com>wrote: > >> Le 02/11/2010 22:27, Paul Poulain a écrit : >> > SUGGESTIONS TO DISCUSS: >> > * branch next version when the RM declare feature freeze for a given >> version >> > > I'll let this one alone for now. > > >> > * have a website rebuilded every night (week ?) (from which branch ? a >> > waiting_librarian_feedback one ?), with all marc21 default values fitted >> > in (with maybe a few biblios added), the librarians being requested to >> > test from a functionnal point of view after the techies QA validation >> >> > I think this is a great idea. If Hudson can do auto builds, surely we can > setup a server with auto-built test installs for various branches. This > would have to be limited to some reasonable number, though. > > Kind Regards, > Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.wa...@bywatersolutions.com Twitter: @sekjal
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
