Hmmm... How about just attaching it as a diff to the related issue description?
Since there is no actual functionality, "only" a demonstration of a problem, I'm not sure a branch is the best place to keep these. /Dennis ________________________________________ From: Kasper Sørensen <[email protected]> Sent: Saturday, November 28, 2015 10:42 To: [email protected] Subject: Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs. Good discussion point Tomasz. From my point of view, it is very nice to reproduce a bug with a unittest. If it is trivial I usually simply inline the unittest in the JIRA issue in a {code} block. But for committers it's certainly also possible that we create branches on the central/shared repo. I agree that creating such a branch on a fork is a bit messy in the long run. Regardless how it's done - I think demonstrating a bug with a failing unittest is a great practice and we should encourage that a lot. I would be happy to agree on making it standard practice to make remote branches on the MM central git repo to represent such bug tests. Maybe we should just always prefix such branch names with "bug/..." or something like that. 2015-11-28 10:31 GMT+01:00 Tomasz Guziałek <[email protected]>: > Hello everyone, > > I would like to discuss with you what would be the preferred way to > checking-in code that is a unit test reproducing an issue, but not fixing > it. > > I created branches in my own fork of MetaModel with failing unit tests for > several tickets. Currently only one of them is still open and no fix is on > the way: > https://issues.apache.org/jira/browse/METAMODEL-167 > > Such branches should not be merged into master as the build will fail, but > they are a valuable documentation of the issues. As mentioned, the branches > live only in a fork, but maybe we should consider checking-in them into the > main repo? > > I am starting the discussion right now, because I would like to nuke my own > fork soon. I made some commits on my fork's master branch by mistake and it > keeps polluting subsequent branches I create. I know that is probably > killing the fly with a bazooka, but it will save me much time carefully > fixing the mess. > > I would love to hear your suggestions regarding the process how we deal > with "red" branches in MetaModel - no doubt that the situatio of > reproducing bugs with unit tests will come up again in the nearest future. >
