I am going to start using PR's

[Edward K. Ream]

The days of cowboy commits are coming to an end.

In future, I plan to create a PR for all my work. A PR is a good record of what has been done, and it should help prevent unwanted merge conflicts.

I think separate PR's for all work makes sense for all of Leo's devs. What do you think?

Edward

[Thomas Passin]

I'd go for that.  PRs, I have noticed on other projects, can support a good discussion before the thing is finalized.

[lun...@gmail.com]

More than anything else, they force a stronger self documenting style of coding. That said PR history is github proprietary (if of course you're using github for your PRs). It may be prudent to occasionally back up your data: https://github.blog/2018-12-19-download-your-data/ .

[Edward K. Ream]

On Tue, Aug 18, 2020 at 7:17 AM lun...@gmail.com <lun...@gmail.com> wrote:

More than anything else, they force a stronger self documenting style of coding. That said PR history is github proprietary (if of course you're using github for your PRs). It may be prudent to occasionally back up your data: https://github.blog/2018-12-19-download-your-data/ .

leoPyRef.leo contains @button backup-repo, which I run from time to time.

Edward

[Offray Vladimir Luna Cárdenas]

I dislike them. I think they introduce an unnecessary bureaucracy in
most projects with small/solo developers and that good commit messages +
actual diffs can be good enough for most project as commit
documentation. But of course, each project and its developer community
have different styles and ways to work together.

Cheers,

Offray

[lun...@gmail.com]

@offay, I've seen similar comments on the Fossil forums.

I don't have faith in developers to write "good commit messages". You need only see this comic to understand my feelings:  https://xkcd.com/1296/ . Developers (in general) are lazy, and this is not entirely caused by "laziness", but these days more often due to lack of established best practices and lack of time. Developers will perform the least amount of steps to get code into production. PRs, while being bureaucratic, put a hard stop in front of developers which forces them to think much harder about their proposed changes and how they will be used and perceived by others. While this slows down development, even in small teams, it is a net win for code quality.

My biggest complaint with PRs with git is that the PRs and not wholly encapsulated within the repo. This is bad for privacy, bad for custody, and bad for archivability. But better documentation and more deliberate contributions are worth these trade-offs, if a better system comes around I'm always interested.

[Edward K. Ream]

On Fri, Aug 21, 2020 at 3:01 PM lun...@gmail.com <lun...@gmail.com> wrote:

@offay, I've seen similar comments on the Fossil forums.

I don't have faith in developers to write "good commit messages".

Imo, commit messages usually only need to be a readable tag. There are exceptions, but they are few.

Let's try using PR's for a while. We can always go back to the wild west if we want :-)

Edward

[Offray Vladimir Luna Cárdenas]

Lunzer,

I may share the Fossil comments, as I'm an avid user of it. Paraphrasing Conway's Law[1] culture and infrastructure reflect each other and I think that Git reflect the bureaucracy of Linux Kernel development with its fork and PR by default, while Fossil considers a small group of developers who mostly know each other [2] and has a more lean/agile approach.

[1] https://en.wikipedia.org/wiki/Conway%27s_law
[2] https://fossil-scm.org/fossil/doc/bsd-vs-gpl/www/fossil-v-git.wiki

I program mostly solo projects and when I hopefully I will pass to projects with few well trusted developers. Seeing from the quality of SQLite and Linux, PR's presence or absence are not a warranty over code quality, but for sure PRs are sign of the believe in quality through bureaucracy and self-restrain. Of course commit message as XKCD are pretty useless (and funny ;-)), but in my case they (+diff) have been working kind of well. I have seen similar behavior on non solo projects like Fossil and SQLite.

But I'm not an active Leo code contributor. So I was just giving my opinion but in the end, core contributors should choose what works best for the developers.

Cheers,

Offray

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/e3fcfb9e-c9fc-4795-a8bc-a59add33207fn%40googlegroups.com.

[Thomas Passin]

I'm not crazy about bureaucracy, but  I have noticed that the PR can lead to a lot of good discussion, and what gets added in the end may not be exactly what was in the PR at the start.

To unsubscribe from this group and stop receiving emails from it, send an email to leo-e...@googlegroups.com.

[Edward K. Ream]

On Fri, Aug 21, 2020 at 9:36 PM Thomas Passin <tbp1...@gmail.com> wrote:

I'm not crazy about bureaucracy, but  I have noticed that the PR can lead to a lot of good discussion, and what gets added in the end may not be exactly what was in the PR at the start.

Imo, "bureaucracy" is a misleading word. True, PR's require more work. The question is, when is the work justified?

As you say, PR's provide a platform for discussion and review. They are typically a permanent record of particular code changes. As we consider Leo without me, I think PR's will help democratize changes. Looking back, a PR for the fast read code that I "borrowed" from Vitalije might have avoided some hard feelings.

Edward

[Thomas Passin]

I submitted a PR for one module in rst2pdf.  We had about three months of discussions - and I discovered I had to make a change to my code update - before everyone was satisfied and the PR was approved.  You can read through the thread and see how much went into it before the PR ended p being approved.  That would never have happened without the PR process (and my original change wouldn't always have worked).  Here's the thread -

https://github.com/rst2pdf/rst2pdf/pull/826

[Offray Vladimir Luna Cárdenas]

Hi,

I have seen healthy discussion of features and commits in the Fossil Forum[1], without PR mechanism. I have seen a lot of discussion about features here with the engineering  notebooks withtout PR. Again not a prerequisite. But whatever works best for the community should be adopted.

[1] https://fossil-scm.org/forum/forummain

Tools inform thinking and viceversa. Git/GitHub and kind of formatting processes to the image of the Linux Kernel development. I think that is important, particularly in early moments before a decision, to be aware of the parallel paths to follow. I like the way Leo followed and shown me a less traversed path, opening the world of outlining to me. But of course this doesn't mean that Leo needs to follow the uncommon path everywhere. Having a latent community repertoire of solutions is worthy, even to be used in other projects.

Cheers,

Offray

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.

To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS34ub-7WtBQHjgj2a4%2BMD4Zae9EhJxdEjUDWi9NXhjviw%40mail.gmail.com.

[Offray Vladimir Luna Cárdenas]

On 22/08/20 10:37 a. m., Offray Vladimir Luna Cárdenas wrote:
> Git/GitHub and kind of formatting processes to the image of the Linux
> Kernel development

Git/GitHub *is* kind of formatting processes to the image of the Linux
Kernel development

[Thomas Passin]

As long as we're on the subject, someone made some changes to viewrendered3 *in my github repo* that I didn't know about.  There is a syntax error in these changes, and I *think* something else got inadvertently changed, and I will have to fix that up, too.  Now if they had put in a PR, it would have been better.

BTW, how do I activate the "Issues" tab in github?  At least we'd have a place to discuss prospective changes like this.

I think it's not thoughtful to go ahead and make changes to someone else's development repo without discussing them first.  Please don't do that.

[Thomas Passin]

It looks like the changes to vr3 came via a change in the devel branch, and those must have come from leo-editor's devel branch.  So it probably wasn't someone changing my repo directly.  Still, there should have been some discussion somewhere first.

[Thomas Passin]

What's weird is that I don't see any comment or commit for the changes that I found.  Not in my repo or Leo's.  Anyway, I reverted the changes and added a better way to accomplish the same thing.  I have put in a pull request  for this version.