4 ms·

>It's work in progress. We're working on getting it finished. So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not

by rvrs 3y ago

>It's work in progress. We're working on getting it finished. So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? It's the author's responsibility to get it merged successfully. If they're taking too long and have to rebase and re-work their code to integrate, that's on them. Pushing it into master is either wasting a reader's time (per the original comment) or, worse, inviting an uninitiated collaborator to use it and cause an incident.

hinkley 3y ago
Somewhere along the way, a new generation of developers thought that 'Continuous Integration' means "automated builds". I wonder what they think that 'integration' word is doing there? Since you're here, I'll ask you. What do you think 'integration' means in this context?
- rvrs 3y ago
  "Passing CI" is a low bar -- it is only a single layer of defense. Moreover, code has syntactic properties that aren't necessarily evaluated by CI. My comment claimed that there are readability and usability concerns with unfinished code. This is why we have code review. CI is a signal that the code is good to merge, but as a code reviewer, I have the final say. I don't merge unfinished code. If CI passes on your branch but later fails due to lagging behind master, it is on you to get it working before re-requesting review. PS: The HN guidelines clearly state "Be kind. Don't be snarky." (:
  - gizmo686 3y ago
    Continous Integration is a development methodology, not an automated process. The idea is that developers continuously merge their changes into a shared integration branch. Having long running feature branches that get merged when they are done is a valid methodology, but it is not continuous integration; no matter what your automated build and test pipeline calls it. In practice, I have typically seen CI done with either feature freezes, or release branches to allow creating versions where everything is complete.
  - hinkley 3y ago
    > If CI passes on your branch but later fails due to lagging behind master, That’s the problem, which I already stated before the question. That’s not integration, that’s a build. Integration is testing your changes with all the code around it. Specifically, it’s about testing your changes with changes that started after you began writing your code. Only small changes land in anything like chronological order. On real codebases, even with low to moderate coupling, the rug can get pulled out from underneath of you without you even noticing until something bad starts happening. CI is about exposing your code to feedback at the earliest possible moment, so you 1) don’t continue to build on violated assumptions, 2) you do lots of small merge operations instead of one big one and 3) the thoughts that began the trouble are still fresh in your head. Consequences of decisions become abstract over time. Nobody changes their behavior based on 1 year old bugs found in their code. Long lived branches are a crutch. It’s avoidant behavior. If you can’t figure out how to make your code work with everyone else’s, why do you think waiting longer will make things better? It doesn’t. The mess just gets bigger. I’ve seen it over and over again. The guys who won’t merge early are full of delusions about their own work that doesn’t match up with the bug and incident count. They call it bad luck.
mvdtnz 3y ago
> So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? Because of the thing I said in the sentence before the one you quoted. > If they're taking too long and have to rebase and re-work their code to integrate, that's on them. No, in the organisations I build, we work as a team and if someone is taking too long it's because we don't have the systems in place to help them work faster. There is very clear research on the benefits of working in small batches and integrating continuously. If that research has passed you by then I strongly suggest you go back and take a look.
lmm 3y ago
> What's the use of putting it in master if it's not finished? Visibility, and avoiding duplicated effort. What's the use of keeping it out of master? > Pushing it into master is either wasting a reader's time (per the original comment) The new parts they'll have to read sooner or later, and for the parts that are changing it's better for them to read the new version than the old version. > or, worse, inviting an uninitiated collaborator to use it and cause an incident. Why would that cause an incident? Having someone see the "upcoming" code and realise they can reuse it in something they're working on is the ideal outcome.

by rvrs 3y ago

hinkley 3y ago

Somewhere along the way, a new generation of developers thought that 'Continuous Integration' means "automated builds". I wonder what they think that 'integration' word is doing there? Since you're here, I'll ask you. What do you think 'integration' means in this context?

rvrs 3y ago
"Passing CI" is a low bar -- it is only a single layer of defense. Moreover, code has syntactic properties that aren't necessarily evaluated by CI. My comment claimed that there are readability and usability concerns with unfinished code. This is why we have code review. CI is a signal that the code is good to merge, but as a code reviewer, I have the final say. I don't merge unfinished code. If CI passes on your branch but later fails due to lagging behind master, it is on you to get it working before re-requesting review. PS: The HN guidelines clearly state "Be kind. Don't be snarky." (:
- gizmo686 3y ago
  Continous Integration is a development methodology, not an automated process. The idea is that developers continuously merge their changes into a shared integration branch. Having long running feature branches that get merged when they are done is a valid methodology, but it is not continuous integration; no matter what your automated build and test pipeline calls it. In practice, I have typically seen CI done with either feature freezes, or release branches to allow creating versions where everything is complete.
- hinkley 3y ago
  > If CI passes on your branch but later fails due to lagging behind master, That’s the problem, which I already stated before the question. That’s not integration, that’s a build. Integration is testing your changes with all the code around it. Specifically, it’s about testing your changes with changes that started after you began writing your code. Only small changes land in anything like chronological order. On real codebases, even with low to moderate coupling, the rug can get pulled out from underneath of you without you even noticing until something bad starts happening. CI is about exposing your code to feedback at the earliest possible moment, so you 1) don’t continue to build on violated assumptions, 2) you do lots of small merge operations instead of one big one and 3) the thoughts that began the trouble are still fresh in your head. Consequences of decisions become abstract over time. Nobody changes their behavior based on 1 year old bugs found in their code. Long lived branches are a crutch. It’s avoidant behavior. If you can’t figure out how to make your code work with everyone else’s, why do you think waiting longer will make things better? It doesn’t. The mess just gets bigger. I’ve seen it over and over again. The guys who won’t merge early are full of delusions about their own work that doesn’t match up with the bug and incident count. They call it bad luck.

mvdtnz 3y ago

> So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? Because of the thing I said in the sentence before the one you quoted. > If they're taking too long and have to rebase and re-work their code to integrate, that's on them. No, in the organisations I build, we work as a team and if someone is taking too long it's because we don't have the systems in place to help them work faster. There is very clear research on the benefits of working in small batches and integrating continuously. If that research has passed you by then I strongly suggest you go back and take a look.

lmm 3y ago

> What's the use of putting it in master if it's not finished? Visibility, and avoiding duplicated effort. What's the use of keeping it out of master? > Pushing it into master is either wasting a reader's time (per the original comment) The new parts they'll have to read sooner or later, and for the parts that are changing it's better for them to read the new version than the old version. > or, worse, inviting an uninitiated collaborator to use it and cause an incident. Why would that cause an incident? Having someone see the "upcoming" code and realise they can reuse it in something they're working on is the ideal outcome.