I personally don't like working with diffs. But will try to make friends
with them, sounds like a reasonable idea to use them for bug reproducing
purposes.
Pozdrawiam / Regards / Med venlig hilsen
Tomasz Guziałek
2015-11-29 9:30 GMT+01:00 Kasper Sørensen <i.am.kasper.soren...@gmail.com>:
> 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.
> > >
> >
>
