I think that also sounds like a good idea. Agree that rarely the branch is
needed.
2015-11-28 13:09 GMT+01:00 Du Krøger, Dennis <
dennis.dukro...@humaninference.com>:
> 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 <i.am.kasper.soren...@gmail.com>
> Sent: Saturday, November 28, 2015 10:42
> To: dev@metamodel.apache.org
> 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 <tomaszguzia...@apache.org>:
>
> > 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.
> >
>
