On Wed, 3 Nov 2010, Irma Birchall wrote:
There is also the problem of coordinating development of features.
* how do we coordinate development? * who decides? * what is the structure for deciding?
this at lease seems like it should have a straightforward set of answers. Q: how do we coordinate development? by announceing what you are working on on this mailing list and letting other people comment if they are working on the same thing (or want to work with you on the feature) Q: who decides? Q: what is the structure for deciding? whoever is willing to do the work decides that a feature is being worked on. If there are disagreements on how a feature should be implemented (either due to multiple people working on the feature, or due to reviews of the code disputing details) the matter gets discussed on the mailing list. when the matter settles to a concensus, the release manager (or whoever is allowed to put code in the main tree) can then accept the code. As far as the issue of needing to do things between official releases, I would suggest that community opinion and preasure push really hard for this sort of change to be accepted into the central tree before it's shipped by anyone to customers. If this is not done, the company shipping the change is running the risk that it will not be accepted upstream and they will have to maintain it as a fork forever. If this is done there is little risk that the code will change significantly before the next release. While this second version is technically still a fork, it's a very closely related fork that is clearly temporary and will disappear as soon as the next official release takes place. note that faster releases significantly reduce this problem. David Lang _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha