NOTICE: Gitolite migration is complete.

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

NOTICE: Gitolite migration is complete.

Austin Seipp-4
All,

Push access is now restored and Gitolite is in place! This brings some
nice updates:

 * There's now access to the 'git' protocol for cloning anonymously.
This lets you clone even the biggest repos extremely quickly, and is
the fastest method for getting a copy of the tree.
 * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git,
meaning it should be faster too!
 * We will soon have Gitweb available, once our git.haskell.org CNAME
is in place. Eventually we'd like something akin to
https://git.kernel.org/cgit/ possibly.
 * None of you have shell access to ghc.haskell.org anymore (well,
this is a nice update for us administrators :)

The following people have had their keys re-added, and should be able
to push and pull from the new setup.

 * Andreas Voellmy
 * Austin Seipp
 * Ben Lippmeier
 * Iavor Diatchki
 * David Terei
 * David Waern
 * Dimitrios Vytiniotis
 * Duncan Coutts
 * Edsko de Vries
 * Erik de Castro Lopo
 * Edward Yang
 * Geoffrey Mainland
 * Gabor Greif
 * Herbert Valerio Riedel
 * Ian Lynagh
 * Ilya Sergey
 * Johan Tibell
 * Jos? Pedro Magalh?es
 * Jan Stolarek
 * Manuel Chakravarty
 * Max Bolingbroke
 * Nicholas Frisby
 * Paolo Capriotti
 * Richard Eisenberg
 * Roman Leshchinskiy
 * Ross Patterson
 * Simon Hengel
 * Simon Marlow
 * Simon Peyton Jones
 * Thomas Schilling

The following people still have shell access for any administrative needs:

 * Austin Seipp (and the remaining haskell.org infrastructure team.)
 * Herbert Valerio Riedel
 * Ian Lynagh

I have undoubtedly missed some people. Please talk to me and we'll get
you set up!

If you're a developer, please read about developer changes here:

 * http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan#Developerchanges

TL;DR: if you have an old tree, run the following four commands from
the root to fix the push/pull URLs.

$ git checkout master
$ git pull https://github.com/ghc/ghc.git master
$ ./sync-all -r ssh://git at ghc.haskell.org remote set-url origin
$ ./sync-all -r ssh://git at ghc.haskell.org remote set-url --push origin

The reason you must get the latest-copy of ./sync-all is because
Herbert made some last minute bug fixes. Technically, you could just
download the latest copy and run it directly, but this is easier and
fairly straight forward.

Please direct any concerns to me, like if you need something off the
server, need your shell account back, or need commit access. Over the
next few days, I'll be cleaning up the wiki - updating references and
guides on how to check out the source for users and developer. I also
might be sending out some emails with questions while we refine the
new setup in the next few days (there were some Trac integration
changes.)

Also, a gigantic applause for Herbert, who did a lot of the work here!

--
Regards,
Austin - PGP: 4096R/0x91384671



Reply | Threaded
Open this post in threaded view
|

NOTICE: Gitolite migration is complete.

Malcolm Wallace-2

On 9 Aug 2013, at 23:19, Austin Seipp wrote:

> * None of you have shell access to ghc.haskell.org anymore (well,
> this is a nice update for us administrators :)

Is ghc.haskell.org the same machine as darcs.haskell.org?
I notice that my nightly build of nhc98 failed a few hours ago with the error:

darcs failed:  Not a repository: darcs.haskell.org:/home/darcs/nhc98 ((scp) failed to fetch: darcs.haskell.org:/home/darcs/nhc98/_darcs/inventory)

whilst it certainly succeeded the night before.
Also, manual use of ssh now refuses me access to the machine:

$ ssh darcs.haskell.org
Permission denied (publickey).

Anything you can do to fix that?  Darcs depends on the ssh protocol for transfers.

Regards,
    Malcolm


Reply | Threaded
Open this post in threaded view
|

NOTICE: Gitolite migration is complete.

Herbert Valerio Riedel
In reply to this post by Austin Seipp-4
Hello GHC Devs,

Let me add some details and clarifications to yesterday's
migration completion notice:

On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
> Push access is now restored and Gitolite is in place! This brings some
> nice updates:

>  * There's now access to the 'git' protocol for cloning anonymously.
>    This lets you clone even the biggest repos extremely quickly, and is
>    the fastest method for getting a copy of the tree.

Consequently, if you are a developer (and not behind a firewall that
filters port 9418) you should try out the following assymetric
configuration:

  ./sync-all -r git://ghc.haskell.org remote set-url origin
  ./sync-all -r ssh://git at ghc.haskell.org remote set-url --push origin

This uses the unauthenticated low-latency git:// protocol for fetching
repository data, and the authenticated encrypted high-latency ssh://
protocol for pushing into the GHC repositories.

This setup has the advantage over using the GitHub GHC mirrors, that the
fetch and push locations are really identical and never out-of-sync
(e.g. if the Git mirroring breaks or lags for some reason)

>  * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git,
>    meaning it should be faster too!
>  * We will soon have Gitweb available, once our git.haskell.org CNAME
>    is in place. Eventually we'd like something akin to

Small clarification: Smart HTTP Git transport is only enabled on
http://git.haskell.org/; The legacy URLs at http://darcs.haskell.org/
are is still served "dumbly".

If you don't want to wait for the DNS CNAME entry, you can fake the DNS
entry to point to ghc.haskell.org, e.g. by

  echo "88.198.224.241 git.haskell.org" >> /etc/hosts

(...and don't forget to remove that entry once the real DNS CNAME entry
is in place) and then just point your browser to http://git.haskell.org/

> The following people have had their keys re-added, and should be able
> to push and pull from the new setup.
> [...]

You should all check your current permissions by invoking

  ssh git at ghc.haskell.org info

you should see something like

,----
| hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git 1.7.10.4
| the gitolite config gives you the following access:
|     @R   W ghc
|     @R   W ghc-tarballs
|     @R   W git-sandbox
|     @R   W haddock
| [...]
|     @R   W packages/unix
|     @R   W packages/vector
|     @R   W packages/xhtml
|     @R   W testsuite
`----

Please make sure, *YOUR* username shows up in place of $USERNAME, to
find out whether we mixed up your public keys.

(See http://gitolite.com/gitolite/g2/info_expand.html#info, if you want
to know more about the meaning of the output)

Note: The current setup denies non-fast-forward and ref-deletion updates
via "git push". This will be relaxed once we reach an agreement over
what the Git heads/tag refs namespace policy shall be (i.e. who is
allowed to create/delete/non-fwd-update heads/tags (and which ones)).

If you want to debug/test 'git push', feel free to push whatever you
like to the 'git-sandbox' repository.

> Please direct any concerns to me, like if you need something off the
> server, need your shell account back, or need commit access.

For technical problems with Trac&Git(olite) itself, please CC me as
well; as I am in a different timezone from Austin, this may help reduce
the response time for solving the issue at hand. Alternatively, you can
also reach us on freenode's #haskell-infrastructure

And finally, the changes resulting from the new Trac commit-hook
integration is worth a separate posting of its own to follow shortly.

Cheers,
  hvr



Reply | Threaded
Open this post in threaded view
|

New Git-commit-message -> Trac-ticket interaction (was: NOTICE: Gitolite migration is complete.)

Herbert Valerio Riedel
On 2013-08-10 at 11:06:06 +0200, Herbert Valerio Riedel wrote:
> And finally, the changes resulting from the new Trac commit-hook
> integration is worth a separate posting of its own to follow shortly.

The new post-receive hook for notifying Trac about new commits has been
updated to use Trac's CommitTicketUpdater[1]

One of the changes is the way commit messages are added to a ticket
comment:

 - Previously, the commit message was put into a verbatim code block, as in
   http://ghc.haskell.org/trac/ghc/ticket/8121#comment:2

 - Now, the commit message is wrapped in a code block using Trac's
   CommitTicketReference wiki processor which effectively interprets the
   commit message as Trac wiki markup[2]. This is more consistent with the
   way commit messages are exposed in other places throughout Trac and
   allows for proper Wiki and URL links in the ticket comment view.

   For instance, http://ghc.haskell.org/trac/ghc/ticket/8121#comment:3


As for *when* a Git commit is actually associated with a ticket:

 - Currently, only the 4 Git repos associated with GHC Trac
   (ghc,nofib,testuite,base; [3]) are scanned for ticket
   references.

 - Currently, only if a commit becomes reachable during a "git push"
   from the 'master' branch it gets scanned for trigger words. This is
   the simplest way to avoid duplicate commit messages getting added as
   comments to tickets (and avoid premature ticket closing).[4]

 - The ticket-referencing syntax explained below must be used, for the
   ticket reference to get recognized.


To quote the documentation[1]:

,----
| The basic syntax is of the form [command] [ticketreference]. A colon
| between the command and the ticket reference is allowed. The
| ticketreference also allows to list multiple ticket numbers separated by
| spaces and/or comma. The word 'and' is also allowed between ticket
| numbers.
|
| You can optionally refer to tickets with the following words
|
| ticket, issue, bug
| Examples (note: not verified!):
|
| close #10
| closed: #10
| closes ticket #10
| closes ticket:10
| fixes #10
| fixes bug: #10
| see issue #5
| references #5, #6
| fixes bug #10 and #11
|
| A fairly complicated example of what you can do is with a commit
| message of:
|
| Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
|
| This will close #10 and #12, and add a note to #12.
`----

The command verbs currently recognized for referencing a ticket are
currently:

| addressing addresses re references refs see Trac

...and the verbs currently recognized for referencing *and* closing a
ticket are

| close closed closes fix fixed fixes

Consequently, if you just write "Fixes Trac #1234" in your commit (which
occurs quite often in the git history), this will only reference the
ticket but *not* close the ticket.

If closing from commits is not desired or causes problems, we can move
the close/fix verbs into the "reference-only" set of verbs and be done
with it.

If there's something you'd like to behave differently, please tell us.
If accomplishable with reasonable effort, we're happy to implement it.


The information from this posting may/should/shall/will be put on the
GHC Trac Wiki as well for future reference.

Cheers,
  hvr

 [1]: http://trac.edgewall.org/wiki/CommitTicketUpdater
 [2]: http://ghc.haskell.org/trac/ghc/wiki/WikiFormatting
 [3]: http://ghc.haskell.org/trac/ghc/browser
 [4]: Should the need arise, we can consider a more sophisticated
      approach can be used, which would consider commits in more than
      just the 'master' branch.



Reply | Threaded
Open this post in threaded view
|

NOTICE: Gitolite migration is complete.

Herbert Valerio Riedel
In reply to this post by Malcolm Wallace-2
Hello Malcolm,

On 2013-08-10 at 09:57:34 +0200, Malcolm Wallace wrote:
>> * None of you have shell access to ghc.haskell.org anymore (well,
>> this is a nice update for us administrators :)
> Is ghc.haskell.org the same machine as darcs.haskell.org?

Yes

> I notice that my nightly build of nhc98 failed a few hours ago with the error:
>
> darcs failed:  Not a repository: darcs.haskell.org:/home/darcs/nhc98 ((scp) failed to fetch: darcs.haskell.org:/home/darcs/nhc98/_darcs/inventory)
>
> whilst it certainly succeeded the night before.
> Also, manual use of ssh now refuses me access to the machine:
>
> $ ssh darcs.haskell.org
> Permission denied (publickey).
>
> Anything you can do to fix that?  Darcs depends on the ssh protocol
> for transfers.

Btw, I assumed Darcs required only ssh for write access to a Darcs repo?

However, if this helps, we could create a user account 'darcs' (in the
style of the current 'git' gitolite user) with a darcs-wrapper.pl and
add the ssh pubkeys from users needing darcs/ssh access as described in
[1]; this would still satisfy the least-privilege principle as no full
shell account would be given out on ghc.haskell.org.

Would that help?

 [1]: http://darcs.net/RepoViaSSH



Reply | Threaded
Open this post in threaded view
|

New Git-commit-message -> Trac-ticket interaction

Simon Marlow-7
In reply to this post by Herbert Valerio Riedel
On 10/08/13 10:57, Herbert Valerio Riedel wrote:

> The command verbs currently recognized for referencing a ticket are
> currently:
>
> | addressing addresses re references refs see Trac
>
> ...and the verbs currently recognized for referencing *and* closing a
> ticket are
>
> | close closed closes fix fixed fixes
>
> Consequently, if you just write "Fixes Trac #1234" in your commit (which
> occurs quite often in the git history), this will only reference the
> ticket but *not* close the ticket.
>
> If closing from commits is not desired or causes problems, we can move
> the close/fix verbs into the "reference-only" set of verbs and be done
> with it.

One reason that we didn't enable this feature before was that we often
want to move the ticket into the merge state after committing the fix.

So perhaps we should either have a new keyword ("mergefix"?) for fixes
we want to merge, or we should not have the auto-close behaviour.

Cheers,
        Simon




Reply | Threaded
Open this post in threaded view
|

HEADS UP! was: Re: New Git-commit-message -> Trac-ticket interaction

Simon Marlow-7
In reply to this post by Herbert Valerio Riedel
Just in case there are other people (like me) who didn't notice this,
the syntax for telling git that you want to update a Trac ticket in the
commit log has changed.  Read Herbet's message for details.

I used to just mention the ticket number in the commit message "blah
blah (#1234)", the new syntax for this is "blah blah (see #1234)".

I have updated
http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git to mention
this, but it could probably do with more complete docs since the
standard Trac docs don't take into account our local settings.  Herbert,
could you expand that please?

Cheers,
        Simon


On 10/08/13 10:57, Herbert Valerio Riedel wrote:

> On 2013-08-10 at 11:06:06 +0200, Herbert Valerio Riedel wrote:
>> And finally, the changes resulting from the new Trac commit-hook
>> integration is worth a separate posting of its own to follow shortly.
>
> The new post-receive hook for notifying Trac about new commits has been
> updated to use Trac's CommitTicketUpdater[1]
>
> One of the changes is the way commit messages are added to a ticket
> comment:
>
>   - Previously, the commit message was put into a verbatim code block, as in
>     http://ghc.haskell.org/trac/ghc/ticket/8121#comment:2
>
>   - Now, the commit message is wrapped in a code block using Trac's
>     CommitTicketReference wiki processor which effectively interprets the
>     commit message as Trac wiki markup[2]. This is more consistent with the
>     way commit messages are exposed in other places throughout Trac and
>     allows for proper Wiki and URL links in the ticket comment view.
>
>     For instance, http://ghc.haskell.org/trac/ghc/ticket/8121#comment:3
>
>
> As for *when* a Git commit is actually associated with a ticket:
>
>   - Currently, only the 4 Git repos associated with GHC Trac
>     (ghc,nofib,testuite,base; [3]) are scanned for ticket
>     references.
>
>   - Currently, only if a commit becomes reachable during a "git push"
>     from the 'master' branch it gets scanned for trigger words. This is
>     the simplest way to avoid duplicate commit messages getting added as
>     comments to tickets (and avoid premature ticket closing).[4]
>
>   - The ticket-referencing syntax explained below must be used, for the
>     ticket reference to get recognized.
>
>
> To quote the documentation[1]:
>
> ,----
> | The basic syntax is of the form [command] [ticketreference]. A colon
> | between the command and the ticket reference is allowed. The
> | ticketreference also allows to list multiple ticket numbers separated by
> | spaces and/or comma. The word 'and' is also allowed between ticket
> | numbers.
> |
> | You can optionally refer to tickets with the following words
> |
> | ticket, issue, bug
> | Examples (note: not verified!):
> |
> | close #10
> | closed: #10
> | closes ticket #10
> | closes ticket:10
> | fixes #10
> | fixes bug: #10
> | see issue #5
> | references #5, #6
> | fixes bug #10 and #11
> |
> | A fairly complicated example of what you can do is with a commit
> | message of:
> |
> | Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
> |
> | This will close #10 and #12, and add a note to #12.
> `----
>
> The command verbs currently recognized for referencing a ticket are
> currently:
>
> | addressing addresses re references refs see Trac
>
> ...and the verbs currently recognized for referencing *and* closing a
> ticket are
>
> | close closed closes fix fixed fixes
>
> Consequently, if you just write "Fixes Trac #1234" in your commit (which
> occurs quite often in the git history), this will only reference the
> ticket but *not* close the ticket.
>
> If closing from commits is not desired or causes problems, we can move
> the close/fix verbs into the "reference-only" set of verbs and be done
> with it.
>
> If there's something you'd like to behave differently, please tell us.
> If accomplishable with reasonable effort, we're happy to implement it.
>
>
> The information from this posting may/should/shall/will be put on the
> GHC Trac Wiki as well for future reference.
>
> Cheers,
>    hvr
>
>   [1]: http://trac.edgewall.org/wiki/CommitTicketUpdater
>   [2]: http://ghc.haskell.org/trac/ghc/wiki/WikiFormatting
>   [3]: http://ghc.haskell.org/trac/ghc/browser
>   [4]: Should the need arise, we can consider a more sophisticated
>        approach can be used, which would consider commits in more than
>        just the 'master' branch.
>
> _______________________________________________
> 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
|

NOTICE: Gitolite migration is complete.

Edward Z. Yang
In reply to this post by Herbert Valerio Riedel
What happened to the libraries repositories?

    ezyang at javelin:~/Dev/ghc-clean/libraries/binary$ cat .git/config
    [core]
            repositoryformatversion = 0
            filemode = true
            bare = false
            logallrefupdates = true
            ignorecase = true
    [remote "origin"]
            fetch = +refs/heads/*:refs/remotes/origin/*
            url = git://ghc.haskell.org/libraries/binary
            pushurl = ssh://git at ghc.haskell.org/libraries/binary
    [branch "master"]
            remote = origin
            merge = refs/heads/master
    ezyang at javelin:~/Dev/ghc-clean/libraries/binary$ git pull
    fatal: remote error: access denied or repository not exported: /libraries/binary

Edward

Excerpts from Herbert Valerio Riedel's message of Sat Aug 10 05:06:06 -0400 2013:

> Hello GHC Devs,
>
> Let me add some details and clarifications to yesterday's
> migration completion notice:
>
> On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
> > Push access is now restored and Gitolite is in place! This brings some
> > nice updates:
>
> >  * There's now access to the 'git' protocol for cloning anonymously.
> >    This lets you clone even the biggest repos extremely quickly, and is
> >    the fastest method for getting a copy of the tree.
>
> Consequently, if you are a developer (and not behind a firewall that
> filters port 9418) you should try out the following assymetric
> configuration:
>
>   ./sync-all -r git://ghc.haskell.org remote set-url origin
>   ./sync-all -r ssh://git at ghc.haskell.org remote set-url --push origin
>
> This uses the unauthenticated low-latency git:// protocol for fetching
> repository data, and the authenticated encrypted high-latency ssh://
> protocol for pushing into the GHC repositories.
>
> This setup has the advantage over using the GitHub GHC mirrors, that the
> fetch and push locations are really identical and never out-of-sync
> (e.g. if the Git mirroring breaks or lags for some reason)
>
> >  * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git,
> >    meaning it should be faster too!
> >  * We will soon have Gitweb available, once our git.haskell.org CNAME
> >    is in place. Eventually we'd like something akin to
>
> Small clarification: Smart HTTP Git transport is only enabled on
> http://git.haskell.org/; The legacy URLs at http://darcs.haskell.org/
> are is still served "dumbly".
>
> If you don't want to wait for the DNS CNAME entry, you can fake the DNS
> entry to point to ghc.haskell.org, e.g. by
>
>   echo "88.198.224.241 git.haskell.org" >> /etc/hosts
>
> (...and don't forget to remove that entry once the real DNS CNAME entry
> is in place) and then just point your browser to http://git.haskell.org/
>
> > The following people have had their keys re-added, and should be able
> > to push and pull from the new setup.
> > [...]
>
> You should all check your current permissions by invoking
>
>   ssh git at ghc.haskell.org info
>
> you should see something like
>
> ,----
> | hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git 1.7.10.4
> | the gitolite config gives you the following access:
> |     @R   W     ghc
> |     @R   W     ghc-tarballs
> |     @R   W     git-sandbox
> |     @R   W     haddock
> | [...]
> |     @R   W     packages/unix
> |     @R   W     packages/vector
> |     @R   W     packages/xhtml
> |     @R   W     testsuite
> `----
>
> Please make sure, *YOUR* username shows up in place of $USERNAME, to
> find out whether we mixed up your public keys.
>
> (See http://gitolite.com/gitolite/g2/info_expand.html#info, if you want
> to know more about the meaning of the output)
>
> Note: The current setup denies non-fast-forward and ref-deletion updates
> via "git push". This will be relaxed once we reach an agreement over
> what the Git heads/tag refs namespace policy shall be (i.e. who is
> allowed to create/delete/non-fwd-update heads/tags (and which ones)).
>
> If you want to debug/test 'git push', feel free to push whatever you
> like to the 'git-sandbox' repository.
>
> > Please direct any concerns to me, like if you need something off the
> > server, need your shell account back, or need commit access.
>
> For technical problems with Trac&Git(olite) itself, please CC me as
> well; as I am in a different timezone from Austin, this may help reduce
> the response time for solving the issue at hand. Alternatively, you can
> also reach us on freenode's #haskell-infrastructure
>
> And finally, the changes resulting from the new Trac commit-hook
> integration is worth a separate posting of its own to follow shortly.
>
> Cheers,
>   hvr
>



Reply | Threaded
Open this post in threaded view
|

NOTICE: Gitolite migration is complete.

Herbert Valerio Riedel
Hello Edward,

On 2013-08-13 at 15:39:20 +0200, Edward Z. Yang wrote:
> What happened to the libraries repositories?

They are still there, but only in the /packages directory (as declared
in the 'packages' file in the remotepath columns, see also [1]); you
need to run

>>   ./sync-all -r git://ghc.haskell.org remote set-url origin
>>   ./sync-all -r ssh://git at ghc.haskell.org remote set-url --push origin

with a recent version of 'sync-all' which contains [2], then that should
be taken care of automatically.

HTH,
  hvr

 [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/1713
 [2]: http://ghc.haskell.org/trac/ghc/changeset/4f43572224b3c8723dc1bf0e886313b0e9c92049/ghc





Reply | Threaded
Open this post in threaded view
|

HEADS UP! was: Re: New Git-commit-message -> Trac-ticket interaction

Herbert Valerio Riedel
In reply to this post by Simon Marlow-7
On 2013-08-13 at 14:20:59 +0200, Simon Marlow wrote:

[...]

> I have updated
> http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git to mention
> this, but it could probably do with more complete docs since the
> standard Trac docs don't take into account our local settings.

> Herbert, could you expand that please?

I've just expanded that section; please review

I've added a reference to [1] (even though almost all commit
messages I've seen already follow that convention anyway).

I refrained from mentioning some of the additional syntax variants
recognized by the commit message parser (such as "closes issue 1234" as
alternative for "closes #1234") as it makes grepping through commit
messages more difficult.

While at it, I added "resolve{,s,ed}" to the list of verbs to mimic
GitHub's supported keywords[2]. Btw, if this is desired, we could make a
commit add a ticket comment as soon as the respective ticket-number
occurs (i.e. w/o any preceding verb). This would effectively make Trac
recognize a subset of GitHub's syntax. I could implement this together
with the mergefix-verb feature you proposed.

 [1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
 [2]: https://help.github.com/articles/closing-issues-via-commit-messages

Cheers,
  hvr



Reply | Threaded
Open this post in threaded view
|

HEADS UP! was: Re: New Git-commit-message -> Trac-ticket interaction

Jan Stolarek
> Btw, if this is desired, we could make a
> commit add a ticket comment as soon as the respective ticket-number
> occurs (i.e. w/o any preceding verb).

I consider this useful. I want to write commit messages in the tesuite like "Add regression test for #1234" instead of "Add regression test. See #1234" or sth even more awkward.

Janek



Reply | Threaded
Open this post in threaded view
|

New Git-commit-message -> Trac-ticket interaction

Simon Peyton Jones
In reply to this post by Simon Marlow-7
Herbert

My gut feel is that it's fragile and unexpected to have tickets change status based on commit messages. Revisiting the ticket itself can remind you
  that the fix is only partial, or
  that there is another related ticket to look at, or
  that you need to add a regression test, or
  something else

Too much automation can be confusing.  I'd suggest (fairly strongly -- but resist if you feel otherwise) making status changes only based on explicit user actions.  It doesn't take long to do!

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
|  Marlow
|  Sent: 13 August 2013 13:17
|  To: Herbert Valerio Riedel
|  Cc: ghc-devs at haskell.org
|  Subject: Re: New Git-commit-message -> Trac-ticket interaction
|  
|  On 10/08/13 10:57, Herbert Valerio Riedel wrote:
|  
|  > The command verbs currently recognized for referencing a ticket are
|  > currently:
|  >
|  > | addressing addresses re references refs see Trac
|  >
|  > ...and the verbs currently recognized for referencing *and* closing a
|  > ticket are
|  >
|  > | close closed closes fix fixed fixes
|  >
|  > Consequently, if you just write "Fixes Trac #1234" in your commit (which
|  > occurs quite often in the git history), this will only reference the
|  > ticket but *not* close the ticket.
|  >
|  > If closing from commits is not desired or causes problems, we can move
|  > the close/fix verbs into the "reference-only" set of verbs and be done
|  > with it.
|  
|  One reason that we didn't enable this feature before was that we often
|  want to move the ticket into the merge state after committing the fix.
|  
|  So perhaps we should either have a new keyword ("mergefix"?) for fixes
|  we want to merge, or we should not have the auto-close behaviour.
|  
|  Cheers,
|   Simon
|  
|  
|  _______________________________________________
|  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
|

Previous commit ticket ref syntax restored (was: New Git-commit-message -> Trac-ticket interaction)

Herbert Valerio Riedel
Hello Simon,

On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:

> My gut feel is that it's fragile and unexpected to have tickets change
> status based on commit messages. Revisiting the ticket itself can
> remind you
>   that the fix is only partial, or
>   that there is another related ticket to look at, or
>   that you need to add a regression test, or
>   something else
>
> Too much automation can be confusing.  I'd suggest (fairly strongly --
> but resist if you feel otherwise) making status changes only based on
> explicit user actions.  It doesn't take long to do!

Well, I'm somewhat convinced (and I don't have a solution to offer
addressing your concerns at the moment).

Moreover, as it's easier right now to just configure more or less what the previous
semantics were and post-pone devising a more elaborate ticket/commit action
command system, I've reconfigured the Trac instance as follows:

 - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in
   a commit's message (which became newly reachable from the `master`
   branch with the current `git push` operation), the commit is added as
   a comment to the referenced ticket.

 - Aside from adding comments to a ticket, no other actions are
   triggered by Git commit messages.

Is this acceptable?

Cheers,
  hvr



Reply | Threaded
Open this post in threaded view
|

Previous commit ticket ref syntax restored

Simon Marlow-7
On 15/08/13 14:36, Herbert Valerio Riedel wrote:

> Hello Simon,
>
> On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:
>> My gut feel is that it's fragile and unexpected to have tickets change
>> status based on commit messages. Revisiting the ticket itself can
>> remind you
>>    that the fix is only partial, or
>>    that there is another related ticket to look at, or
>>    that you need to add a regression test, or
>>    something else
>>
>> Too much automation can be confusing.  I'd suggest (fairly strongly --
>> but resist if you feel otherwise) making status changes only based on
>> explicit user actions.  It doesn't take long to do!
>
> Well, I'm somewhat convinced (and I don't have a solution to offer
> addressing your concerns at the moment).
>
> Moreover, as it's easier right now to just configure more or less what the previous
> semantics were and post-pone devising a more elaborate ticket/commit action
> command system, I've reconfigured the Trac instance as follows:
>
>   - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in
>     a commit's message (which became newly reachable from the `master`
>     branch with the current `git push` operation), the commit is added as
>     a comment to the referenced ticket.
>
>   - Aside from adding comments to a ticket, no other actions are
>     triggered by Git commit messages.
>
> Is this acceptable?

That's great.  I also quite liked the previous behaviour.

Cheers,
        Simon





Reply | Threaded
Open this post in threaded view
|

Previous commit ticket ref syntax restored (was: New Git-commit-message -> Trac-ticket interaction)

Simon Peyton Jones
In reply to this post by Herbert Valerio Riedel
|   - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in
|     a commit's message (which became newly reachable from the `master`
|     branch with the current `git push` operation), the commit is added as
|     a comment to the referenced ticket.
|  
|   - Aside from adding comments to a ticket, no other actions are
|     triggered by Git commit messages.
|  
|  Is this acceptable?

That sounds good to me, thanks.

Don't forget to update the wiki though.

Thanks

Simon

|  -----Original Message-----
|  From: Herbert Valerio Riedel [mailto:hvr at gnu.org]
|  Sent: 15 August 2013 14:36
|  To: Simon Peyton-Jones
|  Cc: Herbert Valerio Riedel; Simon Marlow; ghc-devs at haskell.org
|  Subject: Previous commit ticket ref syntax restored (was: New Git-commit-
|  message -> Trac-ticket interaction)
|  
|  Hello Simon,
|  
|  On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:
|  > My gut feel is that it's fragile and unexpected to have tickets change
|  > status based on commit messages. Revisiting the ticket itself can
|  > remind you
|  >   that the fix is only partial, or
|  >   that there is another related ticket to look at, or
|  >   that you need to add a regression test, or
|  >   something else
|  >
|  > Too much automation can be confusing.  I'd suggest (fairly strongly --
|  > but resist if you feel otherwise) making status changes only based on
|  > explicit user actions.  It doesn't take long to do!
|  
|  Well, I'm somewhat convinced (and I don't have a solution to offer
|  addressing your concerns at the moment).
|  
|  Moreover, as it's easier right now to just configure more or less what the previous
|  semantics were and post-pone devising a more elaborate ticket/commit action
|  command system, I've reconfigured the Trac instance as follows:
|  
|   - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in
|     a commit's message (which became newly reachable from the `master`
|     branch with the current `git push` operation), the commit is added as
|     a comment to the referenced ticket.
|  
|   - Aside from adding comments to a ticket, no other actions are
|     triggered by Git commit messages.
|  
|  Is this acceptable?
|  
|  Cheers,
|    hvr