Re: 2.21.0 Issues all verified!

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sun, May 17, 2020 at 3:12 AM Carl Sorensen <address@hidden> wrote:
>> > Personally, so far my main issue is, well, the workflow bypassing
>> > issues.  Changes that are only presented as merge requests without any
>> > accompanying issue are just too intangible for my taste: those
>> > correspond more to what we previously said "things like that you can
>> > push directly to staging".  I find it awkward to find my way around
>> > them, and after pushing there does not seem an obvious reverse relation
>> > to a tangible report that one could easily derive from seeing the commit
>> > in the repository.
>> >
>> > I prefer having an actual issue number for the details for anything of
>> > non-trivial nature.
>>
>> +1
>>
>> I believe we should declare (and try to enforce) a policy that the
>> name of a branch in a merge request should include an issue number.
>
> I want to dissent here: I think that issues should not be used unless
> there is an actual bug or other effort that needs to be tracked
> separately from the code.
>
> We now have 3 distinct places to put information
>
> 1) issue discussion
> 2) merge request
> 3) commit message
>
> for posterity, it is usually easier to put all info inside the commit
> message, because it doesn't rely on external sites (rietveld,
> sourceforge, gitlab). We need the MRs to discuss the code and commit
> message. What benefit do we get from also having an issue?

The merge requests are not referenceable in the same manner as issues
are.  We have carried over our issue numbers but not the Rietveld
numbers.  So the link from commit message to merge request is just not
there: a merge request does not really fill more of a need than Rietveld
did previously.

The commit message is not, in my book, the right place to carry an
adversarial discussion.  Rather it's the place for the conclusion.
Circumstances may change invalidating the conclusion: without the
possibility to refer back to the previous discussion, understanding the
premises under which a conclusion has been drawn is not possible.

We want to avoid developers stomping over the efforts of other
developers unwittingly because they were not able to look up the
discussions leading to a certain outcome.

> There is a definite downside to using the issue tracker, which is that
> filing bugs becomes harder, because all the chatter from the
> development process makes it harder to find relevant bugs.

The chatter is under a heading.  If you don't select the heading, you
don't get the chatter.

>> With git-cl upload, an issue was automatically created if it didn't
>> already exist.  I really liked that functionality.  If we can't do
>> such a thing automatically in GitLab, I think we should do it by
>> policy.  As you say, it's very hard to track merge requests without a
>> tie to the issue tracker.
>
> what does "track" mean in this context?

Figuring out what discussions and decisions led to a certain approach
being implemented.  In a colloborative development environment, you
don't want every developer inventing the wheel new while deflating
wheels other developers have installed.

-- 
David Kastrup