splitting gtk-support-3 branch

[Matthew Scott]

Pat,

Can you briefly comment on the state of the gtk-support-3 branch?

I'd like to spend some time this week breaking out and reviewing the
general Schevo enhancements you've made to it, so we can fold those into
trunk for a September release.

I don't want to do that if you are still on a tight deadline with it
though. I'm also not sure of your current confidence level with regards
to the reliability and backwards-compatibility of the the upgrades and
changes you've made to schevo.store, so if you could comment on that
specifically that would be great.

Thanks!

[Patrick K. O'Brien]

Post by Matthew Scott
Pat,
Can you briefly comment on the state of the gtk-support-3 branch?
I'd like to spend some time this week breaking out and reviewing the
general Schevo enhancements you've made to it, so we can fold those into
trunk for a September release.

That would be fantastic and now is a great time to do so.

Post by Matthew Scott
I don't want to do that if you are still on a tight deadline with it
though. I'm also not sure of your current confidence level with regards
to the reliability and backwards-compatibility of the the upgrades and
changes you've made to schevo.store, so if you could comment on that
specifically that would be great.

I'm confident enough that I'm using it for my production applications.
I would be more confident if there were more unit tests, but that would
take time that I don't have at the moment. So I'm willing to go forward
without them for the moment. Unfortunately, the Durus unit tests (which
I have converted and all pass with my modified fork) are not as
comprehensive as I would like or would have expected. For example, they
did not catch one edge case that I overlooked. I have fixed that edge
case, but I could probably think of others that lack unit tests. For
me, the memory savings of my durus fork are too good to pass up.

All in all I feel good about the entire branch.

[Matthew Scott]

Post by Patrick K. O'Brien
All in all I feel good about the entire branch.

If you have time in the next couple of hours while I'm at lunch, can you
reconcile the fact that this was never merged into the gtk-support-3 branch?

http://schevo.org/trac/changeset/2280

As it stands, this version
http://schevo.org/trac/browser/branches/gtk-support-3/Schevo/schevo/field.py
only validates min_value and max_value on Integer fields, but not Float
or Money fields.

Attempting to merge 2279:2280 into gtk-support-3 results in conflicts,
and there have been many changes to field.py and test_field.py in that
branch that didn't go through the branch/review/merge routine.

Rather than getting myself frustrated and confused, I thought I'd just
see if you could provide some input on this. As it stands, even if it
is fixed in gtk-support-3, I think we may still run into conflicts
merging into trunk, unless we tiptoe carefully between trunk,
gtk-support-3, and nongtk-41.

There are many circumstances by multiple parties that contributed to the
lack of the branch/review/merge process over the last couple of months,
but it's things like the above that make me hope that we can get back on
track with that as we move forward.

Perhaps we can look at the perception of that process being
time-consuming or a hindrance, and rather than avoid the process, figure
out ways to make it more streamlined -- and also make it work better in
the face of deadline pressures and developer absences.

[Matthew Scott]

Post by Matthew Scott
There are many circumstances by multiple parties that contributed to the
lack of the branch/review/merge process over the last couple of months,
but it's things like the above that make me hope that we can get back on
track with that as we move forward.

Another side-effect:

Using the Schevo in gtk-support-3, running unit tests on the app I'm
responsible for (and that is also in production use using Schevo trunk)
results in many errors that amount to:

"""
TransactionFieldsNotChanged: A transaction must have at least one field
changed.
"""

So the time is definitely right to feature-freeze and get this all
straightened out.