[Koha-devel] A Discussion on A Policy Setting Forth Standards of Code Submission, etc. [WAS: RFCs for 3.4 from BibLibre (serials & acquisitions)]

[Clay Fouts]

Releasing earlier is absolutely a factor in this, and I'm heartened that
you've made it a priority for 3.4.

Because Koha's API and schema lack consistency, abstraction, and isolation
of concerns, adding nearly anything substantial demands that those elements
change in ways that affect other areas radically. The amount of resources
required to rebase dozens of individual feature branches when half of them
require meddling with the key internals in way that will affect others
increases in a non-linear fashion with the passage of time.

Until Koha has a stable and more sophisticated API, short release cycles of
working code is a necessity for developers who are creating lots of features
stand a chance at being able to cooperate with each other in the long term.
As is, it's very expensive for a developer to maintain a slew of feature
branches compared to keeping a unified development trunk of their own.

Clay


On Tue, Nov 2, 2010 at 3:05 PM, Chris Cormack <chris at bigballofwax.co.nz>wrote:

> On 3 November 2010 10:27, Paul Poulain <paul.poulain at biblibre.com> wrote:
>
> > We haven't started working on any of those RFCs (except solR, to have a
> > proof of concept).
> > What has really be a problem for us is that we published RFCs for Lyon3
> > university a long time ago (mail from Nicolas on koha-devel oct, 12,
> > 2009), there has been strictly no reaction/feedback to those RFCs.
> > Now they are done, and we have rebased them vs head (huge work, and huge
> > QA to do, and probably a lot of time lost)
> > Could they be rejected by the community ? hopefully I hope no, but I
> > frankly don't know what we (BibLibre) could do if it were :-((( (because
> > the customers are live now !)
> > I think we (all) failed because Koha 3.2 was 9 months late. Well, in
> > fact, I think the mistake was not to branch 3.4 immediatly on feature
> > freeze. That would have been much less pain for us (that are
> > customer-planning driven) (suggestion below).
>
> What would have caused much much much less pain for you, was to
> develop your features in small branches, rather than one monolithic
> branch which makes rebasing much harder than it needs to be.
>
> This is a lesson that cannot be overstated, topic/bug/feature branches
> make everyones lives much easier. And they mean that if one feature is
> rejected ... then the whole stack doesn't need to be.
>
> I don't think branching sooner or an earlier release would have helped
> anywhere near as much as developing in smaller branches, not one huge
> one.
>
> Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101109/b5a48d91/attachment.htm>