From 3019c1e3a12f7c8135a6a417655b0ec2d4fa5b6e Mon Sep 17 00:00:00 2001 From: Andrey Miroshnikov Date: Mon, 15 Jan 2024 19:04:50 +0000 Subject: [PATCH] sync_up: Discussion, add rest of points from thread --- .../sync_up_2024-01-16_discussion.mdwn | 68 ++++++++++++++++++- 1 file changed, 67 insertions(+), 1 deletion(-) diff --git a/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn b/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn index 1da0ebe36..b54cf4417 100644 --- a/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn +++ b/meetings/sync_up/discussion/sync_up_2024-01-16_discussion.mdwn @@ -9,7 +9,7 @@ in the wiki. ## Points to be discussed -Dmitry's main point of concern: +Dmitry's points of concern: * As a developer, I should have a liberty to interactively rebase, fixup, squash commits, commit when I can and want, and same for push. If there are @@ -17,6 +17,55 @@ restrictions on this from NLnet side, these must be explicitly published on their own guidelines. I'm sure they have different forms than the ones exposed. +* My point is, as I work on it as an individual in my free time, I +should have flexibility to a certain degree to develop it when and how +I want. And I commit the code when it's at least somewhat "ready" and +"stable" and "beautiful" according to my personal standards. I +extensively use interactive rebase to make the history readable. When +I find that some branch commit introduced an error, I go back there +and edit it interactively, then force push. This makes the linear +history work when the master is rebased, decreases the chance of the +later bisect and simply avoids the trash like "oh look I fixed a typo" +for the code which just got rebased into the master (unless required). + +* Obviously this works better in branches or in master if you have force +push rights (and likely develop alone); but it has its own benefits. +Obviously it isn't a silver bullet, but it makes the history way +better, and that's the approach I always follow. And now, despite that +nobody had problems with this before, now we have this discussion. +This is not the first time we have some rules established for which we +lack the explicit requirements. The lack of these is fine as long as +there's a technical rationale. I doubt any real SW project has a +"commit whatever you have" policy. Real SW projects follow "commit +respectively and wisely" policies instead. + +* Indeed, these statements are vague and reflect my own personal +experience and preferences. But, unless you have a real severe cause +to completely bend someone else's behavior and habits into the way you +like it, I'd prefer to avoid it. You know I don't have massive chunks +of the code with me (I wouldn't even if I had time, what's the +purpose?). But I try to avoid "trash" commits, I try to commit things +which work, and I always worked this way. After all, it's an Open +Source development, not some corporate idiocracy. + +* As for "we're afraid something might get lost", I'd recommend starting +with the different places to think about. For example, git and CI. +These seem to be much better targets; these are the real points of +failure. + +* Yes this is subjective; I hope we _all_ are subjects though. "Commit +once you think it's good enough to show to others, it breaks nothing, +there's nothing to be ashamed of, you find it appropriate to publish +at this stage" -- these all look reasonable. The beauty is in the eyes +of the beholder. + +Dmitry's point on his personal time: + +* My point is, I +really have not much time to work, and I indeed try hard to dedicate +all the free time I have. Please don't make me feel that I waste this +time taking the spokes out of the wheels. :-) + Jacob's response: * Assuming you're not working directly on the master branch, I think it @@ -33,6 +82,16 @@ code -- after all it's really hard to spot bugs in code you can't see! * I don't think there are any NLNet restrictions other than that code needs to be public before submitting RFPs. +* we should probably put our conclusions in the developer documentation, +Andrey would you be willing to do that? icr if that docs bug is closed +yet...there's probably a good task to put this under. + +* maybe just expand the existing wiki section somewhat? + +*(Andrey: I agree. A first rough draft will probably be this page. +Only the most important points the team agrees on will be written +into HDL_workflow, if not already present.)* + Luke's responses: The "regular commit push" approach imitates corporate backup systems: @@ -149,6 +208,13 @@ get paid for private work, as this directly conflicts with NLnet's "Works for the Public Good" mandate. ``` +Luke on git history cleanup: + +``` +i worked out Dmitry, that you probably actually enjoy doing the +git history cleanup, it is a sense of satisfaction and pride :) +``` + Point made by Andrey to Dmitry: * I understand your concern of being able to develop independently, -- 2.30.2