commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [COLLECTIONS] 3.3 RC1 for review
Date Mon, 25 May 2009 08:33:35 GMT
On Sat, May 23, 2009 at 3:33 AM, sebb <sebbaz@gmail.com> wrote:
> On 23/05/2009, Henri Yandell <flamefew@gmail.com> wrote:

>> Maven release plugin is the one doing the copy to the branch. So I
>>  don't see the commit message (well.. it's probably somewhere in the
>>  huge load of text that passes through). It also changes things before
>>  the copy, and afterwards, so svn info won't give correct info.
>
> The revision is in the message sent to commits @ c.a.o which all
> developers should follow.
>
> AFAIK, Maven does not change the tag after it has created it, so the
> SVN Info will be accurate - though you need to look at Last Changed
> Revision, which will be the same as when the tag was created.

And at the end of the day you still have to trust me as the RM that
what I built came from that tag? (or in fact that tag happened
somewhere in the middle of the release plugin). It's a lot of
make-work as far as I can tell.

>>  If I wasn't using the maven release plugin then I'd be building from
>>  an export of svn. Then svn info could be used.
>>
>>  [says I with some level of irkdoom. When you try to control someone's
>>  development process, you remove their ability to be agile in
>>  situations like this].
>>
>
> Huh?
>
> All I'm saying is that the URL needs to be qualified with the revision
> otherwise it's not guaranteed unique. One small piece of information
> to be added to the VOTE message.

It's unnecessary. We have social conventions in place - ie) don't
modify tags; we have commit mails to show whether they have been; we
have a do-magic tool that doesn't explain what it built the release
from and you want the revision # for a URL that is only added to the
release mail as an afterthought. :)

I agree fully that a URL isn't guaranteed unique - but I don't see the
point in needing it.

Anyway - you can see the commit mails too, I've no clue which one is
the one used to make the source (yup, I feel queasy using the mvn
release-plugin as I don't like releasing with a magic red button, but
am not taking the time to pull it apart and learn what it does).

>>  >>  >>  Binaries:
>>  >>  >>
>>  >>  >>  http://people.apache.org/builds/commons/collections/3.3/RC1/staged/commons-collections/commons-collections/3.3/
>>  >>  >
>>  >>  > It would be useful to record the Md5 hashes, because the same file
>>  >>  > names will be used for RC2 etc:
>>  >>
>>  >>
>>  >> I don't understand.
>>  >>
>>  >
>>  > The file names don't include the RCn suffix, so a second RC would use
>>  > the same name.
>>  > The MD5s are needed to ensure that we are voting on the same artifacts.
>>
>>
>> But you're not. New artifacts are generated.
>
> Yes, but the same artifact names are re-used. Sometimes the same
> directory name is re-used as well.
>
> So to ensure that we are all voting on the same versions of the
> artifacts, the hashes are needed.

They are in md5 files next to the files themselves.

I'm still not getting it.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message