Issues that straddle releases

45 views
Skip to first unread message

Edward K. Ream

unread,
Feb 27, 2020, 11:41:03 AM2/27/20
to leo-editor
I don't like to fix bugs involving Leo's most crucial code late in a release cycle. Imo, such bugs should be fixed early in the next release cycle. That way the new can be thoroughly tested.

In the past, I have just postponed work on such issues until an official release has gone out the door. Now I see that such delay is not needed. I can create a new branch for any issue at any time! Doh! This seems obvious now, but it didn't become obvious to me until just a few days ago.

Issues deferred to Leo 6.3

The following issues entail significant changes to Leo's core. I have rescheduled them all for Leo 6.3.

- #1510: invalid characters in .leo files.
- #1497: auto-save.
- #1493: python import problems.
- #1484: problems with marks.
- #1475: sentinels in body text.

Last, and most importantly:

- #1437: gnx problems in Leo's bridge. This issue has languished for far too long.

Summary

At last I see that I can begin work on a potentially dangerous issue now, even if it is prudent to include the issue in some later release. This allows important bug fixes to be tested immediately.

The five bugs schedule for Leo 6.3 all now have the "First" label, meaning that they should be merged into devel as soon as possible after Leo 6.2.

The last four bugs scheduled for Leo 6.2 should be safe to fix. They do not imply significant or dangerous changes to Leo's core.

Edward

Edward K. Ream

unread,
Feb 27, 2020, 12:13:36 PM2/27/20
to leo-editor
On Thursday, February 27, 2020 at 10:41:03 AM UTC-6, Edward K. Ream wrote:

At last I see that I can begin work on a potentially dangerous issue now, even if it is prudent to include the issue in some later release. This allows important bug fixes to be tested immediately.

Some additional thoughts:

1. This work flow reduces the coupling between issues and releases.

The only constraint is that significant fixes should be merged into devel early in a release cycle.

2. This work flow privileges those who use Leo's github repo.

Imo, that's exactly as it should be. Yes, there is value in having official releases, but those releases should not impair development in any significant way. And now they don't :-)

Edward

Thomas Passin

unread,
Feb 27, 2020, 8:20:41 PM2/27/20
to leo-editor
Yes, and some would say that you should open a separate new branch for every single bug.  If you haven't seen it, Raymond Chen's The Old New Thing had a whole series on how to organize, merge, and commit git branches to avoid strange problems like giving the "blame" to the wrong person.  Very worth reading if you haven't encountered the series yet. (What he's dealing with is way beyond anything I've had to deal with, but you are working on a much larger code base with many more contributors than I).

The series starts here:

Edward K. Ream

unread,
Feb 28, 2020, 6:15:10 AM2/28/20
to leo-editor
On Thu, Feb 27, 2020 at 7:20 PM Thomas Passin <tbp1...@gmail.com> wrote:

Thanks for the link.

Edward
Reply all
Reply to author
Forward
0 new messages