Release process updates

The mission of the ASF is to release software as source, and to ensure that the released source is available under the Apache Licence. Before a release can be approved it must be voted on by the PMC. The review process needs to establish that the proposed source release meets those aims. It's all

Re: Release process updates

I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, sebb wrote:

Re: Release process updates

Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather tha

Re: Release process updates

For record keeping purposes, the SVN revision + tag combo is better because some RM's have inadvertently reused RC tags in the past. As Sebb pointed out tags are mutable. Gary On Tue, Jun 25, 2013 at 1:52 PM, Ralph Goers wrote: > I disagree that the revision is required. I know that the RM is

Re: Release process updates

Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. At this point the tag is still junk to eve

Re: Release process updates

On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers wrote: > Again I have to disagree. The release manager will send an email closing > the prior release. At this point all the prior release artifacts are junk > even if they still exist. At some point the release manager will delete > the tag and reru

Re: Release process updates

Le mardi 25 juin 2013 17:52:20 sebb a écrit : > And it's not unknown for spurious files to creep into a release > (perhaps from a stale workspace - are releases always built from a > fresh checkout of the tag?) we use the release plugin, which does the release from a fresh checkout (FYI causing pr

Re: Release process updates

Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: > On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers > wrote: > >> Again I have to disagree. The release manager will send an email clos

RE: Release process updates

-Original Message- > From: sebb [mailto:seb...@gmail.com] > Sent: Tuesday, June 25, 2013 6:52 PM > To: dev@maven.apache.org > Subject: Release process updates > > The mission of the ASF is to release software as source, and to ensure that > the released source is

Re: Release process updates

> > > > -Original Message- > > From: sebb [mailto:seb...@gmail.com] > > Sent: Tuesday, June 25, 2013 6:52 PM > > To: dev@maven.apache.org > > Subject: Release process updates > > > > The mission of the ASF is to release software as sourc

Re: Release process updates

Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit : > This is a slightly different > workflow, but is proven to work since years now. great workflow here, at maven project, we use release plugin: this is a slightly different workflow, but is proven to work since years now. Regards, Hervé ---

Re: Release process updates

Especially in other environments where it's used properly, by its own principals! :-p On Tue, Jun 25, 2013 at 9:43 PM, Hervé BOUTEMY wrote: > Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit : > > This is a slightly different > > workflow, but is proven to work since years now. > great workfl

Re: Release process updates

On 25 June 2013 19:19, Ralph Goers wrote: > Again I have to disagree. The release manager will send an email closing the > prior release. At this point all the prior release artifacts are junk even > if they still exist. At some point the release manager will delete the tag > and rerun the r

Re: Release process updates

It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. On 25 June 2013 19:38, Ralph Goers wrote: > Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed > release vote instead of deleting them. > > > On Jun 25, 2013, at 11:23 AM, Gary

Re: Release process updates

On 25 June 2013 19:33, Hervé BOUTEMY wrote: > Le mardi 25 juin 2013 17:52:20 sebb a écrit : >> And it's not unknown for spurious files to creep into a release >> (perhaps from a stale workspace - are releases always built from a >> fresh checkout of the tag?) > we use the release plugin, which doe

Re: Release process updates

2013/6/26 sebb : > It would be a lot better to use RC1 RC2 etc initially, and copy the > successful tag to the GA tag. > this mean modifying manually the pom to change version (from 1.0-RC1 to 1.0) before copying teh RC tag, changing the scm information etc... Rebuild jars ? because if you change t

Re: Release process updates

This appears to be a variant of the "Do we reuse version numbers?" discussion of recent times. That was resolved. Can we please not rehash this? -Chris On Wed, Jun 26, 2013 at 2:52 AM, sebb wrote: > The mission of the ASF is to release software as source, and to ensure > that the released sour

Re: Release process updates

On Tue, Jun 25, 2013 at 7:14 PM, sebb wrote: > It would be a lot better to use RC1 RC2 etc initially, and copy the > successful tag to the GA tag. > +1 ! :) Gary > > On 25 June 2013 19:38, Ralph Goers wrote: > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed > relea

Re: Release process updates

-1 Except then the poms will point to the wrong place. On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory wrote: > On Tue, Jun 25, 2013 at 7:14 PM, sebb wrote: > > > It would be a lot better to use RC1 RC2 etc initially, and copy the > > successful tag to the GA tag. > > > > +1 ! :) > > Gary > > >

Re: Release process updates

On 26 June 2013 01:04, Chris Graham wrote: > -1 > Except then the poms will point to the wrong place. Depends how the poms are updated. > > > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory wrote: > >> On Tue, Jun 25, 2013 at 7:14 PM, sebb wrote: >> >> > It would be a lot better to use RC1 RC2 e

Re: Release process updates

On 26 June 2013 00:34, Chris Graham wrote: > This appears to be a variant of the "Do we reuse version numbers?" > discussion of recent times. > That was resolved. > Can we please not rehash this? > > -Chris > > > On Wed, Jun 26, 2013 at 2:52 AM, sebb wrote: > >> The mission of the ASF is to relea

Re: Release process updates

> And if the "mvn deploy" fails for any reason? We get this often enough with a crappy connection to our nexus servers. > Is it necessary to re-run release:perform? release:perform may be at the stage where it has deleted the configuration file details, in which case you just revert to the manua

Re: Release process updates

On 26 June 2013 01:25, Barrie Treloar wrote: >> And if the "mvn deploy" fails for any reason? > > We get this often enough with a crappy connection to our nexus servers. > >> Is it necessary to re-run release:perform? > > release:perform may be at the stage where it has deleted the > configuration

Re: Release process updates

You havn't done this much have you? mvn release:perform can be rerun and if you clean it the checkout will always be into a clean location ./target/checkout/ by default. On Wed, Jun 26, 2013 at 10:11 AM, sebb wrote: > On 26 June 2013 00:34, Chris Graham wrote: > > This appears to be a variant

Re: Release process updates

correct. In case of failure during deploy: * cd target/checkout && mvn clean deploy -Papache-release or * export/checkout the tag && mvn clean deploy -Papache-release 2013/6/26 Barrie Treloar : >> And if the "mvn deploy" fails for any reason? > > We get this often enough with a crappy connection

Re: Release process updates

>> From: sebb [mailto:seb...@gmail.com] >> Sent: Tuesday, June 25, 2013 6:52 PM >> To: dev@maven.apache.org >> Subject: Release process updates >> >> The mission of the ASF is to release software as source, and to ensure that >> the released source is av

Re: Release process updates

On Wed, Jun 26, 2013 at 10:36 AM, sebb wrote: > However there is also the possibility that vital files are missing > from the source archive. > For that to be detected, a comparison with the SVN tag is needed. > > How? Given the source archive is built from the checked out tag? Please go and run

Re: Release process updates

On 26 June 2013 01:43, Chris Graham wrote: > On Wed, Jun 26, 2013 at 10:36 AM, sebb wrote: > >> However there is also the possibility that vital files are missing >> from the source archive. >> For that to be detected, a comparison with the SVN tag is needed. >> >> > How? Given the source archive

Re: Release process updates

On 26 June 2013 01:41, Olivier Lamy wrote: > correct. > In case of failure during deploy: > * cd target/checkout && mvn clean deploy -Papache-release > or > * export/checkout the tag && mvn clean deploy -Papache-release Neither of those guarantee that the workspace agrees with the tag. Only by c

Re: Release process updates

On 26 June 2013 10:19, sebb wrote: > On 26 June 2013 01:41, Olivier Lamy wrote: >> correct. >> In case of failure during deploy: >> * cd target/checkout && mvn clean deploy -Papache-release >> or >> * export/checkout the tag && mvn clean deploy -Papache-release > > Neither of those guarantee that

Re: Release process updates

On 26 June 2013 02:18, Barrie Treloar wrote: > On 26 June 2013 10:19, sebb wrote: >> On 26 June 2013 01:41, Olivier Lamy wrote: >>> correct. >>> In case of failure during deploy: >>> * cd target/checkout && mvn clean deploy -Papache-release >>> or >>> * export/checkout the tag && mvn clean deplo

Re: Release process updates

>> Then replace >> cd target/checkout && mvn clean deploy -Papache-release >> with >> delete target/checkout >> svn co to target/checkout >> mvn clean deploy -Papache-release >> >> Since it was mvn release:perform that created target/checkout in the >> first place and no one has made any changes i

Re: Release process updates

the jar content isn't updated: so you have jar artifacts inconsistent with svn Le mercredi 26 juin 2013 01:08:59 sebb a écrit : > On 26 June 2013 01:04, Chris Graham wrote: > > -1 > > Except then the poms will point to the wrong place. > > Depends how the poms are updated. > > > On Wed, Jun 26,

Re: Release process updates

+1 easy to use, very powerful, and produces artifacts consistent with scm and for those who didn't read the doc: prepare [1] and perform [2] [1] http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html [2] http://maven.apache.org/maven-release/maven-release-plug

Re: Release process updates

I meant: if the pom is created with the correct final URLs in the first place, it won't have to be changed. It might need a tweak to the appropriate plugin, but it's not impossible to achieve. The same process would work with the system used by Lucene. On 26 June 2013 06:48, Hervé BOUTEMY wrote

Re: Release process updates

On Wed, Jun 26, 2013 at 7:06 PM, sebb wrote: > I meant: if the pom is created with the correct final URLs in the > first place, it won't have to be changed. > > They are. If you'd used the release plugin, then you would have seen this. > It might need a tweak to the appropriate plugin, but it's

Re: Release process updates

On 26 June 2013 02:59, Barrie Treloar wrote: >>> Then replace >>> cd target/checkout && mvn clean deploy -Papache-release >>> with >>> delete target/checkout >>> svn co to target/checkout >>> mvn clean deploy -Papache-release >>> >>> Since it was mvn release:perform that created target/checkout i

Re: Release process updates

On 26 June 2013 10:56, Chris Graham wrote: > On Wed, Jun 26, 2013 at 7:06 PM, sebb wrote: > >> I meant: if the pom is created with the correct final URLs in the >> first place, it won't have to be changed. >> >> > They are. If you'd used the release plugin, then you would have seen this. > I was

Re: Release process updates

Hello there, when. respinning a release it would of help IMO instead of deleting the tag to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using "svn mv". By means of this you are able to easily diff between e.g. released 2.8 and the final 2.9 as well as between 2.9-rc1 and the final 2.9. Regard

Re: Release process updates

Sounds a good idea for me (probably until someone else complain :-) ). And if that stop discussions and move people to working on code/fixing issues (i.e something very important for users) that will be great! 2013/6/27 Mirko Friedenhagen : > Hello there, > > when. respinning a release it would o

Re: Release process updates

Yes, tags are cheap so can be kept until no longer useful. If there are a lot of stale tags it can get difficult to navigate the tags directory, so it makes sense to delete all but the successful tag once the vote has completed. There should be no need to keep failed tags once the vote is complete.

Re: Release process updates

I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid. Have you ever used the release plugin? If not, I would suggest you try it

Re: Release process updates

Agreed. Our tooling and policy is embodied in the release plugin. I am personally fine with any policy changes that are required, but would argue anything we have is grandfathered in because we've been doing it so long. If changes are required, my requirement is that I do nothing more than I cu

Re: Release process updates

On 27 June 2013 15:05, Ralph Goers wrote: > I do not believe that can be done with the release plugins as the pom has to > specify the same version as the tag. If you then rename the tag you would > have to modify the poms in the tag, which makes the release invalid. > > Have you ever used the

Re: Release process updates

Hello, this seems to be the most popular discussion, so another 2 cents: - Today I read the man page of git-tag again. - It states very clearly you should never reuse tags, because unlike is the case with subversion, once a git tag is out in the wild (and pushing to git-wip is the jungle here), ev

Re: Release process updates

Can you provide the steps required to get the release plugin to work this way? Ralph On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote: > Hello, > > this seems to be the most popular discussion, so another 2 cents: > - Today I read the man page of git-tag again. > - It states very clearly y

Re: Release process updates

This suggestion is much like what we came up with the last time we discussed this - about 3 weeks ago. This behaviour is simple to achieve without a single line of change; the release plugin already asks for a SCM tag name distinct from the version number. (we *could* add some kind of support for

Re: Release process updates

On Thu, Jun 27, 2013 at 4:39 PM, Jason van Zyl wrote: > Agreed. > > Our tooling and policy is embodied in the release plugin. I am personally > fine with any policy changes that are required, but would argue anything we > have is grandfathered in because we've been doing it so long. If changes a

Re: Release process updates

+1 to change our tags convention if it solves this issue by avoiding to reuse tag names to give a better visibility from where a release was done On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > This suggestion is much like what we came up with the las

Re: Release process updates

The re-use of tags is a side-issue to this thread, though I'm glad to see some support for using immutable tags, whatever route is chosen Please start a new thread to continue that discussion. The vote e-mail must have the revision and tag name/trunk URL in it else it is not complete. Just as Mav

Re: Release process updates

For git the unique hash is sufficient, you don't really need the tag at all, they simply point to the unique hash (or another tag, in a chain). If Git was the SCM of choice, I'd use RCX tags, and then not retag for final, but rather point the final tag AT the last, accepted RC tag. For example ar

Re: Release process updates

On Fri, Jun 28, 2013 at 8:35 PM, sebb wrote: > The re-use of tags is a side-issue to this thread, though I'm glad to > see some support for using immutable tags, whatever route is chosen > Please start a new thread to continue that discussion. > > We had that discussion, as already noted here, ab

Re: Release process updates

On Fri, Jun 28, 2013 at 9:04 PM, Fred Cooke wrote: > In terms of current SVN usage, the "SVN mv" command is probably a good > choice, as already discussed. You could argue that a "cp" would be better, > but this creates wholesale duplication, which is never good. > > The SVN SCM provider uses the

Re: Release process updates

On Jun 28, 2013, at 7:05, Fred Cooke wrote: For git the unique hash is sufficient, you don't really need the tag at all, they simply point to the unique hash (or another tag, in a chain). If Git was the SCM of choice, I'd use RCX tags, and then not retag for final, but rather point the final tag

Re: Release process updates

@ Chris Graham email 1 If you had, you'd have seen that the release plugin > uses a svn copy to create the tag. A tag, in this instance is a lebel, or > sym link for a revision. > These two sentences together are pure comedy gold. The second one is purely false. A tag in SVN is nothing more than

Re: Release process updates

On Friday, 28 June 2013, Fred Cooke wrote: > For git the unique hash is sufficient, you don't really need the tag at > all, they simply point to the unique hash (or another tag, in a chain). If > Git was the SCM of choice, I'd use RCX tags, and then not retag for final, > but rather point the fina

Re: Release process updates

Someone else already covered that. The tag can live forever as it always was in the POM. In the SVN version you can either lie before or after, in the Git version you can use final or RC and they'll end up pointing at the same commit. Having said that, I never understood why that was done anyway. M

Re: Release process updates

2013/6/28 Fred Cooke > Someone else already covered that. The tag can live forever as it always > was in the POM. In the SVN version you can either lie before or after, in > the Git version you can use final or RC and they'll end up pointing at the > same commit. Having said that, I never underst

Re: Release process updates

Kristian, # could lead to a lot of problems when used with dereferencing http-proxies, because it separates the http-url fragment[1]. AFAIK Debian packages use ~ (tilde) as separator for beta packages which has no special semantics AFAIK in URLs. [1] http://en.wikipedia.org/wiki/Fragment_identifi

Re: Release process updates

I'll accept any separator as long as we standardize, but I do not think mixing internal project process (dealing with tags, votes and failed internal release attempts) with the final produced artifact. So IMO the project could decide to *stage* and publish foobar-1.0-rc1 (which it actually promotes

Re: Release process updates

What we could do is adding some sort of stageTagName to the prepare goal of maven-release-plugin. The project will initially be tagged with this value, but the pom.xml still contains the final tag location. A new goal could be introduced where you only have to specify the stagingScmUrl. The p

Re: Release process updates

Yup, or the prepare goal actually has some kind of "auto suggest tagname" option; which involves scanning for existing tags according and proposing a new tag according to the same algorithm. So when you say you want to release foobar-1.2, it'll actually look for foobar-1.2§1 and auto-suggest fooba

Re: Release process updates

Revisions are not important for the pom.xml and should not be registered there. It is only important within the artifact to trace back its origins. One location would be the Manifest file[1] by the buildnumber-maven-plugin And you might want to patch the pom.xml which is bundled with the artifac

Re: Release process updates

I had that idea too. 'Static' is the easy solution, 'suggest' the next improved one :) Robert Op Fri, 28 Jun 2013 20:40:58 +0200 schreef Kristian Rosenvold : Yup, or the prepare goal actually has some kind of "auto suggest tagname" option; which involves scanning for existing tags accordi

Re: Release process updates

Moreover, the discussion is very SVN/GIT centric. The release plugin and continuum (as far as I know) are the primary users of the SCM api. The entire scm api is an abstraction layer that is very cvs/svn centric (for historical reasons) but an abstraction layer all the same, and abstraction layers

Re: Release process updates

Hello, I think svn/git are most interesting, as AFAIK all core-plugins reside in these SCMs :-).[1] Being able to easily review the code diff between several takes or releases has a value of it's own IMO. With websvn, gitweb or github e.g., it is quite trivial to create a link which shows the com

Re: Release process updates

2013/6/26 sebb : > The mission of the ASF is to release software as source, and to ensure > that the released source is available under the Apache Licence. Excuse me but I have always understand the ASF mission as building communities around softwares. Community over Code and not Process over Code

Re: Release process updates

> 2013/6/26 sebb >: > > The mission of the ASF is to release software as source, and to ensure > > that the released source is available under the Apache Licence. > > Excuse me but I have always understand the ASF mission as building > communities around softwares. > Community over Code and not Pro

Re: Release process updates

On 1 July 2013 08:17, Andreas Gudian wrote: >> 2013/6/26 sebb >: >> > The mission of the ASF is to release software as source, and to ensure >> > that the released source is available under the Apache Licence. >> >> Excuse me but I have always understand the ASF mission as building >> communities

Release process updates (try 2)

The mission of the ASF is to release software as source, and to ensure that the released source is available under the Apache Licence. Before a release can be approved it must be voted on by the PMC. The review process needs to establish that the proposed source release meets those aims. It's all

Re: Release process updates (try 2)

For Git the only thing that is needed is the unique 40 character hash such as this: FreeAir:youtube-dl fred$ git rev-parse HEAD 48bfb5f2387ab47e1973d9db0782a9af66ffc4e6 It's just sloppy not to do this; if a quality release process is required, so is the SVN rev number. If "good enough" is OK, the

Re: Release process updates (try 2)

Fine with me. Thanks for the explanation sebb. Gary On Jun 30, 2013, at 14:20, sebb wrote: > The mission of the ASF is to release software as source, and to ensure > that the released source is available under the Apache Licence. > > Before a release can be approved it must be voted on by the P

Re: Release process updates (try 2)

On 30 June 2013 19:48, Fred Cooke wrote: > For Git the only thing that is needed is the unique 40 character hash such > as this: > > FreeAir:youtube-dl fred$ git rev-parse HEAD > 48bfb5f2387ab47e1973d9db0782a9af66ffc4e6 OK, so what is the Git command to download a copy of the sources that are par

Re: Release process updates (try 2)

> > OK, so what is the Git command to download a copy of the sources that > are part of the hash? > git checkout Then observe the tree. You can also export an archive, though I don't recall the exact command off the top of my hand. > Don't I need to know something about the Git repo it comes f

Re: Release process updates (try 2)

On the one hand, I think that, in many Apache communities, comparing the source release to the VCS is the exception and not the rule, and may never have happened, even once. (I think that there is at least an even chance that some crusty veteran of httpd will arrive in this thread and call me out o

Re: Release process updates (try 2)

On 30 June 2013 19:20, sebb wrote: > The mission of the ASF is to release software as source, and to ensure > that the released source is available under the Apache Licence. > > Before a release can be approved it must be voted on by the PMC. > The review process needs to establish that the propos

Re: Release process updates (try 2)

On 30 June 2013 23:32, Benson Margulies wrote: > On the one hand, I think that, in many Apache communities, comparing the > source release to the VCS is the exception and not the rule, and may never > have happened, even once. (I think that there is at least an even chance > that some crusty veter

Re: Release process updates (try 2)

On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > Reminder: all this thread is just about is adding the following lines > to vote e-mails: > > SVN Tag: > > https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ > (r1496317

Re: Release process updates (try 2)

On 1 July 2013 07:18, Chris Graham wrote: > On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317<

Re: Release process updates (try 2)

On 1 July 2013 07:18, Chris Graham wrote: > On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317<

Re: Release process updates (try 2)

On 30 June 2013 23:33, sebb wrote: > On 30 June 2013 19:20, sebb wrote: >> Reminder: all this thread is just about is adding the following lines >> to vote e-mails: >> >> SVN Tag: >> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ >> (r1496317) > > An alternativ

Re: Release process updates (try 2)

On Mon, Jul 1, 2013 at 7:14 PM, sebb wrote: > On 1 July 2013 07:18, Chris Graham wrote: > > On Mon, Jul 1, 2013 at 4:20 AM, sebb wrote: > > > >> Reminder: all this thread is just about is adding the following lines > >> to vote e-mails: > >> > >> SVN Tag: > >> > >> > https://svn.apache.org/repo

Re: Release process updates (try 2)

> > > > So, if everyone here likes this idea, by all means let's do that. On the > > other hand, if there is no consensus here, I wish that the Foundation > had a > > clearer venue for discussing global policies like this. > > I hope I don't have to argue that it is ASF policy to only release > sou

Re: Release process updates (try 2)

+1 - I agree with Chris. Besides, if something DOES change in the svn/git tag, we get an email notification so we can immediately figure out what's going on. In addition, if you compare what you are voting on to whatever is the latest version of the the tag, if there is any difference

Re: Release process updates (try 2)

Deleting and recreating a Git tag once published is an *extremely* stupid thing to do, at least an order of magnitude more so than the same action in SVN. I sincerely hope that developers in this community would not engage in such activities. Nevertheless, this thread isn't about that, it's about

Re: Release process updates (try 2)

Guys, even if not convinced this is really useful, I suppose voting template could just be adjusted so that the sha1 or svn revision be added in the VOTE thread, and then get back to code as usual? As it is just a 5 seconds additional operation to be done by the RM, I think this is acceptable if t

Re: Release process updates (try 2)

On Monday, 1 July 2013, Baptiste MATHUS wrote: > Guys, even if not convinced this is really useful, > I suppose voting template could just be adjusted so that the sha1 > or svn revision be added in the VOTE thread, and then get back to code as > usual? +1 > > As it is just a 5 seconds additional

Unique Git coordinates (was: Release process updates (try 2))

On 30 June 2013 21:56, Fred Cooke wrote: >> >> OK, so what is the Git command to download a copy of the sources that >> > are part of the hash? >> > > git checkout Does not work for me. I get the following error message: fatal: Not a git repository (or any of the parent directories): .git Thi

Re: Unique Git coordinates (was: Release process updates (try 2))

On Sunday, 30 June 2013, sebb wrote: > On 30 June 2013 21:56, Fred Cooke > > wrote: > >> > >> OK, so what is the Git command to download a copy of the sources that > >> > > are part of the hash? > >> > > > > git checkout > > Does not work for me. Until I hear otherwise, the reviewers for whom t

Re: Unique Git coordinates (was: Release process updates (try 2))

On 30 June 2013 23:28, Stephen Connolly wrote: > On Sunday, 30 June 2013, sebb wrote: > >> On 30 June 2013 21:56, Fred Cooke > >> wrote: >> >> >> >> OK, so what is the Git command to download a copy of the sources that >> >> >> > are part of the hash? >> >> >> > >> > git checkout >> >> Does not w