On Sun, May 17, 2020 at 3:12 AM Carl Sorensen <carl.d.soren...@gmail.com> 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? 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. > 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? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
