An idea for improving workflow

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

An idea for improving workflow

Jan Stolarek
I've been reading the ghc-devs list for quite some time now and I noticed that it often happens
that one of the developers pushes the changes to the ghc.git repo but forgets to push the
corresponding changes to the testsuite, which results in people trying to figure out why their
validation fails. I was thinking if this problem could be eliminated. Perhaps it would make sense
to add a server-side hook to the ghc.git repo that would display a message reminding to push the
changes to the testsuite? That's definitely not an ultimate solution to the problem, but I think
it could reduce the number of such situations. I played a bit with server-side hooks in git to
see how that looks. The message is interspersed with other output from git, but I think we can
make it visible enough. The message can even be displayed in color, though I am not sure how
portable is this accross different terminals.

Janek


Reply | Threaded
Open this post in threaded view
|

An idea for improving workflow

Daniel Trstenjak-2

Hi Jan,

On Mon, Mar 25, 2013 at 03:36:38PM +0100, Jan Stolarek wrote:
> I've been reading the ghc-devs list for quite some time now and I noticed that it often happens
> that one of the developers pushes the changes to the ghc.git repo but forgets to push the
> corresponding changes to the testsuite, which results in people trying to figure out why their
> validation fails.

I quite like having the shell prompt indicating if there're uncommited changes.

A "clean" repo just displays the branch name:
dan at machine ~/.../somePath [BranchName]>

With uncommited changes:
dan at machine ~/.../somePath [BranchName *]>

Something stashed:
dan at machine ~/.../somePath [BranchName $]>

Untracked files:
dan at machine ~/.../somePath [BranchName %]>


The prompt relevant settings for the bash shell (.bashrc) are:

# which kind of state should be displayed
export GIT_PS1_SHOWDIRTYSTATE=1
export GIT_PS1_SHOWSTASHSTATE=1
export GIT_PS1_SHOWUNTRACKEDFILES=1

# the prompt
export PS1='\u@\h \w$(__git_ps1 " [%s]")> '


The git relevant part of the prompt is: $(__git_ps1 " [%s]")


Greetings,
Daniel


Reply | Threaded
Open this post in threaded view
|

An idea for improving workflow

Jan Stolarek
Daniel,

this is a nice idea, but it does not address the issue I am mentioning. The problem is that GHC an
testsuite are two diferent repositories. One might commit changes to both of them, but if only
one repo is pushed to the central git server, the problem with failing validation might occur.
Also, every developer would have to set this up on her own, whereas my proposal is set up on the
central server and automatically affects everyone pushing to the repo.

Janek

Dnia poniedzia?ek, 25 marca 2013, Daniel Trstenjak napisa?:

> Hi Jan,
>
> On Mon, Mar 25, 2013 at 03:36:38PM +0100, Jan Stolarek wrote:
> > I've been reading the ghc-devs list for quite some time now and I noticed
> > that it often happens that one of the developers pushes the changes to
> > the ghc.git repo but forgets to push the corresponding changes to the
> > testsuite, which results in people trying to figure out why their
> > validation fails.
>
> I quite like having the shell prompt indicating if there're uncommited
> changes.
>
> A "clean" repo just displays the branch name:
> dan at machine ~/.../somePath [BranchName]>
>
> With uncommited changes:
> dan at machine ~/.../somePath [BranchName *]>
>
> Something stashed:
> dan at machine ~/.../somePath [BranchName $]>
>
> Untracked files:
> dan at machine ~/.../somePath [BranchName %]>
>
>
> The prompt relevant settings for the bash shell (.bashrc) are:
>
> # which kind of state should be displayed
> export GIT_PS1_SHOWDIRTYSTATE=1
> export GIT_PS1_SHOWSTASHSTATE=1
> export GIT_PS1_SHOWUNTRACKEDFILES=1
>
> # the prompt
> export PS1='\u@\h \w$(__git_ps1 " [%s]")> '
>
>
> The git relevant part of the prompt is: $(__git_ps1 " [%s]")
>
>
> Greetings,
> Daniel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs




Reply | Threaded
Open this post in threaded view
|

An idea for improving workflow

Daniel Trstenjak-2

Hi Jan,

On Mon, Mar 25, 2013 at 09:09:26PM +0100, Jan Stolarek wrote:
> The problem is that GHC an testsuite are two diferent repositories.
> One might commit changes to both of them, but if only one repo is
> pushed to the central git server, the problem with failing validation
> might occur.

Than perhaps the real problem is having two repos?

If you checkout a former ghc commit, how do you get a fitting test suite?

If someone develops a feature inside of a branch and also changes/extends
the test suite, does he than have a branch in the ghc repo and one in
the test suite repo?

If there's such a big dependency between the two, than separating them
seems only to introduce more hassle.

Or is there something special about the ghc test suite, why it shouldn't be
part of the ghc repo?

Sorry for my ignorance, if that's the case.


Greetings,
Daniel


Reply | Threaded
Open this post in threaded view
|

An idea for improving workflow

Jan Stolarek
Daniel,

I'm also a bit ignorant as to why there are two different repos. Indeed putting the testsuite into
the same repo as GHC seems to be the best option, but I'm assuming that since the GHC team has
placed these projects into separate repos there must be a Good Reason to do so. Or perhaps there
is no such reason? I really don't know - I'm just observing what is going on on the list and I
see that something definitely is wrong with the workflow.

> If you checkout a former ghc commit, how do you get a fitting test suite?
Um... you don'?

> If someone develops a feature inside of a branch and also changes/extends
> the test suite, does he than have a branch in the ghc repo and one in
> the test suite repo?
That's what I'm doing. Not sure if there is an alternative.

Janek