You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2007/12/19 21:23:05 UTC
Release Upload
/dist/incubator/uima now exists on people. feel free to upload the
latest release, sums, sigs, KEYS and documentation. the release
shouldn't be announced until the mirroring script is done and tests
but there's no need for the upload to wait on the script.
NB
1. ***NEVER*** alter any document placed in dist
2. check that public keys are in place (see
http://www.apache.org/dev/new-committers-guide.html#pgp)
3. double check permissions on releases after upload
if anyone has any questions, please feel free to ask
- robert
Re: Release Upload
Posted by Michael Baessler <mb...@michael-baessler.de>.
Robert Burrell Donkin wrote:
> On Dec 20, 2007 5:08 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> Robert Burrell Donkin wrote:
>>
>>> /dist/incubator/uima now exists on people. feel free to upload the
>>> latest release, sums, sigs, KEYS and documentation. the release
>>> shouldn't be announced until the mirroring script is done and tests
>>> but there's no need for the upload to wait on the script.
>>>
>>> NB
>>>
>>> 1. ***NEVER*** alter any document placed in dist
>>>
>>>
>> Robert - several of the projects we see have a file "KEYS" at the top
>> level. As new people join the set of code-signers, I presume this file
>> would be altered? In dist/httpd, the date of the KEYS file is quite recent.
>>
>> So - is a KEYS file an exception to #1 above?
>>
>
> yes
>
>
>> If so, what is the underlying principal for #1?
>>
>
> specifically the released artifacts should never be changed. (for
> security, release artifacts in dist are scanned for changes.) if any
> problems are found with a release after it's been uploaded to dist, a
> new release should be cut with a new release number rather than
> replacing the old one.
>
> - robert
>
OK, I already uploaded the KEYS file on request of infrastructure.
-- Michael
Re: Release Upload
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Dec 20, 2007 5:08 PM, Marshall Schor <ms...@schor.com> wrote:
> Robert Burrell Donkin wrote:
> > /dist/incubator/uima now exists on people. feel free to upload the
> > latest release, sums, sigs, KEYS and documentation. the release
> > shouldn't be announced until the mirroring script is done and tests
> > but there's no need for the upload to wait on the script.
> >
> > NB
> >
> > 1. ***NEVER*** alter any document placed in dist
> >
> Robert - several of the projects we see have a file "KEYS" at the top
> level. As new people join the set of code-signers, I presume this file
> would be altered? In dist/httpd, the date of the KEYS file is quite recent.
>
> So - is a KEYS file an exception to #1 above?
yes
> If so, what is the underlying principal for #1?
specifically the released artifacts should never be changed. (for
security, release artifacts in dist are scanned for changes.) if any
problems are found with a release after it's been uploaded to dist, a
new release should be cut with a new release number rather than
replacing the old one.
- robert
Re: Release Upload
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> Robert Burrell Donkin wrote:
>
>> /dist/incubator/uima now exists on people. feel free to upload the
>> latest release, sums, sigs, KEYS and documentation. the release
>> shouldn't be announced until the mirroring script is done and tests
>> but there's no need for the upload to wait on the script.
>>
>> NB
>>
>> 1. ***NEVER*** alter any document placed in dist
>>
>>
> Robert - several of the projects we see have a file "KEYS" at the top
> level. As new people join the set of code-signers, I presume this file
> would be altered? In dist/httpd, the date of the KEYS file is quite recent.
>
> So - is a KEYS file an exception to #1 above? If so, what is the
> underlying principal for #1?
>
> -Marshall\
>
So far I did not upload the KEYS files. This is done quickly when we get
the advice how to do.
-- Michael
Re: Release Upload
Posted by Marshall Schor <ms...@schor.com>.
Robert Burrell Donkin wrote:
> /dist/incubator/uima now exists on people. feel free to upload the
> latest release, sums, sigs, KEYS and documentation. the release
> shouldn't be announced until the mirroring script is done and tests
> but there's no need for the upload to wait on the script.
>
> NB
>
> 1. ***NEVER*** alter any document placed in dist
>
Robert - several of the projects we see have a file "KEYS" at the top
level. As new people join the set of code-signers, I presume this file
would be altered? In dist/httpd, the date of the KEYS file is quite recent.
So - is a KEYS file an exception to #1 above? If so, what is the
underlying principal for #1?
-Marshall\
Re: Release Upload
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Dec 19, 2007 9:28 PM, Marshall Schor <ms...@schor.com> wrote:
> Michael, can you upload?
it's late here and i think i'll be out the next two evenings. i should
be able to check that everything's ok on saturday and answer mail
before then.
if you discover any urgent questions, ask on IRC or the infrastructure list
cheers
- robert
Re: Release Upload
Posted by Michael Baessler <mb...@michael-baessler.de>.
Michael Baessler wrote:
> Robert Burrell Donkin wrote:
>> On Dec 19, 2007 9:28 PM, Marshall Schor <ms...@schor.com> wrote:
>>
>>> Michael, can you upload? I think a good candidate layout for uploading
>>> would be:
>>>
>>> ...dist/uima/KEYS where the public keys go
>>>
>>> The httpd project has an organization of
>>> binaries / release-id'd artifacts << for binaries
>>> docs / release-id'd artifacts << for documentation
>>> (nothing) / release-id'd artifacts << for source,
>>> announcements
>>>
>>> They also have at the top level, besides the KEYS dir,
>>> Announcement-<release-version>
>>> CHANGES-<release-version>
>>>
>>
>> if you're going to stuff at the top level, a header.html can sometimes
>> be useful (see eg http://www.apache.org/dist/httpd/)
>>
>>
>>> libapreq << a place to put libraries which are prereqs, I think,
>>> which don't change from release to release.
>>> patches << a place to put patches to releases
>>> tools << tools they use to create releases (this seems the
>>> wrong place to put such things, to me).
>>>
>>> An alternative would be to switch the order:
>>> start with the release-id (e.g. uimaj-2.2.1-incubating)
>>> and have under it:
>>> bin
>>> src
>>> doc
>>>
>>> Any opinions as to preferences? Robert - is there a "best practice"
>>> here?
>>>
>>
>> there are several reasonable starting points for developing a process
>> that works.
>>
>> you've already highlighted httpd which usually sets a standard.
>>
>> ant is another standard followed by many projects including commons.
>> see http://www.apache.org/dist/ant/ and
>> http://commons.apache.org/releases/mirror.html. the idea is that easy
>> symlinks are available from the top level.
>>
>> review a few strategies and then see what's likely to works best for
>> UIMA
>>
>>
>>> My slight preference is to have, for those things that occur with every
>>> release, the organization of
>>> uimaj-2.2.1-incubating / bin
>>> uimaj-2.2.1-incubating / src
>>> uimaj-2.2.1-incubating / doc
>>>
>>> I think this will make "archiving the release as a unit, somewhat
>>> easier.
>>>
>>
>> archiving is done automatically (by a sync). all that matters is to
>> remember to delete old releases from dist (it's usually a release
>> manager task - when a new release is added, an older one is deleted.)
>>
>> - robert
>>
> I would prefer an organization similar to ant or http like:
>
> binaries/uimaj-2.2.1-incubating/<artifacts>
> source/uimaj-2.2.1-incubating/<artifacts>
> docs/uimaj-2.2.1-incubating/<artifacts>
> KEYS/<keys file>
>
> with that layout the automatic archiving is structured as well. Since
> we have the same layout.
> As far as I understand the automatic archiving.
>
> Do all agree with that layout?
>
> -- Michael
>
>
I added a preview of the upload to p.a.o/home/mbaessler/mirrorLayout
-- Michael
Re: Release Upload
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Dec 20, 2007 10:15 AM, Michael Baessler <mb...@michael-baessler.de> wrote:
<snip>
> I would prefer an organization similar to ant or http like:
>
> binaries/uimaj-2.2.1-incubating/<artifacts>
> source/uimaj-2.2.1-incubating/<artifacts>
> docs/uimaj-2.2.1-incubating/<artifacts>
> KEYS/<keys file>
>
> with that layout the automatic archiving is structured as well. Since we have the same layout.
> As far as I understand the automatic archiving.
the automatic archiving just sync's the contents of
www.apache.org/dist. anything contained will be archived as originally
laid out.
- robert
Re: Release Upload
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Adam Lally wrote:
>> On Dec 20, 2007 12:19 PM, Marshall Schor <ms...@schor.com> wrote:
>>
>>> So - my preference would be mostly one of "don't care", but with a very
>>> slight leaning toward having the release event result in the
>>> creation of
>>> a new subdir under d/i/uima/<release-identification> and under that,
>>> the
>>> set of files that go with that release; with files that don't change
>>> with each release, like KEYS, at the top. Such an organization would
>>> allow a user browsing the directories to download both the binary and
>>> source releases for a particular version, perhaps slightly more easily.
>>>
>>> I can also see the value of top level "binaries, source, docs"
>>> organization, because a user browsing the directory would likely
>>> have in
>>> mind one of these things they want to go after (although, that might
>>> run
>>> into difficulties if we distribute things that don't fall into these
>>> categories, at some point).
>>>
>>>
>>
>> I also see value both ways. But given that ant, commons, and httpd do
>> it with the top-level "binaries, source, docs" organization, my
>> (slight) preference would be to do it that way. If there are any
>> users who actually go poking around directly in dist/incubator, it
>> would be nice for them if there was some consistency.
>>
>> -Adam
>>
> Let's stop discussing and make progress :-) Which way should we go. I
> think Adam is right, we should do it the most common way.
> So do you all agree with my preview layout?
Yes, let's go with it.
-Marshall
Re: Release Upload
Posted by Thilo Goetz <tw...@gmx.de>.
Michael Baessler wrote:
> Adam Lally wrote:
>> On Dec 20, 2007 12:19 PM, Marshall Schor <ms...@schor.com> wrote:
>>
>>> So - my preference would be mostly one of "don't care", but with a very
>>> slight leaning toward having the release event result in the creation of
>>> a new subdir under d/i/uima/<release-identification> and under that, the
>>> set of files that go with that release; with files that don't change
>>> with each release, like KEYS, at the top. Such an organization would
>>> allow a user browsing the directories to download both the binary and
>>> source releases for a particular version, perhaps slightly more easily.
>>>
>>> I can also see the value of top level "binaries, source, docs"
>>> organization, because a user browsing the directory would likely have in
>>> mind one of these things they want to go after (although, that might run
>>> into difficulties if we distribute things that don't fall into these
>>> categories, at some point).
>>>
>>>
>>
>> I also see value both ways. But given that ant, commons, and httpd do
>> it with the top-level "binaries, source, docs" organization, my
>> (slight) preference would be to do it that way. If there are any
>> users who actually go poking around directly in dist/incubator, it
>> would be nice for them if there was some consistency.
>>
>> -Adam
>>
> Let's stop discussing and make progress :-) Which way should we go. I
> think Adam is right, we should do it the most common way.
> So do you all agree with my preview layout?
>
> -- Michael
+1
Re: Release Upload
Posted by Michael Baessler <mb...@michael-baessler.de>.
Michael Baessler wrote:
> Adam Lally wrote:
>> On Dec 20, 2007 12:19 PM, Marshall Schor <ms...@schor.com> wrote:
>>
>>> So - my preference would be mostly one of "don't care", but with a very
>>> slight leaning toward having the release event result in the
>>> creation of
>>> a new subdir under d/i/uima/<release-identification> and under that,
>>> the
>>> set of files that go with that release; with files that don't change
>>> with each release, like KEYS, at the top. Such an organization would
>>> allow a user browsing the directories to download both the binary and
>>> source releases for a particular version, perhaps slightly more easily.
>>>
>>> I can also see the value of top level "binaries, source, docs"
>>> organization, because a user browsing the directory would likely
>>> have in
>>> mind one of these things they want to go after (although, that might
>>> run
>>> into difficulties if we distribute things that don't fall into these
>>> categories, at some point).
>>>
>>>
>>
>> I also see value both ways. But given that ant, commons, and httpd do
>> it with the top-level "binaries, source, docs" organization, my
>> (slight) preference would be to do it that way. If there are any
>> users who actually go poking around directly in dist/incubator, it
>> would be nice for them if there was some consistency.
>>
>> -Adam
>>
> Let's stop discussing and make progress :-) Which way should we go. I
> think Adam is right, we should do it the most common way.
> So do you all agree with my preview layout?
>
> -- Michael
I uploaded the uimaj-2.2.1-incubating release to
people.apache.org/www/www.apache.org/dist/incubator/uima
Now the header and script files can be added when the files are reviewed.
-- Michael
Re: Release Upload
Posted by Michael Baessler <mb...@michael-baessler.de>.
Adam Lally wrote:
> On Dec 20, 2007 12:19 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> So - my preference would be mostly one of "don't care", but with a very
>> slight leaning toward having the release event result in the creation of
>> a new subdir under d/i/uima/<release-identification> and under that, the
>> set of files that go with that release; with files that don't change
>> with each release, like KEYS, at the top. Such an organization would
>> allow a user browsing the directories to download both the binary and
>> source releases for a particular version, perhaps slightly more easily.
>>
>> I can also see the value of top level "binaries, source, docs"
>> organization, because a user browsing the directory would likely have in
>> mind one of these things they want to go after (although, that might run
>> into difficulties if we distribute things that don't fall into these
>> categories, at some point).
>>
>>
>
> I also see value both ways. But given that ant, commons, and httpd do
> it with the top-level "binaries, source, docs" organization, my
> (slight) preference would be to do it that way. If there are any
> users who actually go poking around directly in dist/incubator, it
> would be nice for them if there was some consistency.
>
> -Adam
>
Let's stop discussing and make progress :-) Which way should we go. I
think Adam is right, we should do it the most common way.
So do you all agree with my preview layout?
-- Michael
Re: Release Upload
Posted by Adam Lally <al...@alum.rpi.edu>.
On Dec 20, 2007 12:19 PM, Marshall Schor <ms...@schor.com> wrote:
> So - my preference would be mostly one of "don't care", but with a very
> slight leaning toward having the release event result in the creation of
> a new subdir under d/i/uima/<release-identification> and under that, the
> set of files that go with that release; with files that don't change
> with each release, like KEYS, at the top. Such an organization would
> allow a user browsing the directories to download both the binary and
> source releases for a particular version, perhaps slightly more easily.
>
> I can also see the value of top level "binaries, source, docs"
> organization, because a user browsing the directory would likely have in
> mind one of these things they want to go after (although, that might run
> into difficulties if we distribute things that don't fall into these
> categories, at some point).
>
I also see value both ways. But given that ant, commons, and httpd do
it with the top-level "binaries, source, docs" organization, my
(slight) preference would be to do it that way. If there are any
users who actually go poking around directly in dist/incubator, it
would be nice for them if there was some consistency.
-Adam
Re: Release Upload
Posted by Marshall Schor <ms...@schor.com>.
As Robert has pointed out (several times, I think :-) ) we should not
take "archiving" issues into account in doing the layout. This is
because whatever we upload into dist/incubator/uima, in whatever
directory layout, is rapidly copied, using that same directory layout,
to the archive place and remains there forever.
So - I think we should consider this decision, not from archiving ease
point of view, but rather from our users point of view, and our own
point of view.
It's up to us to decide when to "archive" (that is, delete from the
dist/incubator/uima) a particular release. Many projects keep several
releases on the mirrors, especially if new downloaders would have a
particular reason to want to download a previous release. In UIMA's
case, so far - I don't think we will have much traffic wanting to
download previous releases, but if we do a major change (like, for
instance, next year, we might want to be changing things to align with
the to-be-released UIMA Standard), then we might want to have 2 releases
on dist/incubator/uima.
>From the user's point of view, our download HTML page can make this
clear, and this would be quite independent of the actual layout in
dist/incubator/uima (henceforth, written as d/i/uima). I do note that
some users might want to actually look at the d/i/uima "directory"
instead of looking at the download HTML page; so there's some value in
having an easy-to-understand organization there.
So - my preference would be mostly one of "don't care", but with a very
slight leaning toward having the release event result in the creation of
a new subdir under d/i/uima/<release-identification> and under that, the
set of files that go with that release; with files that don't change
with each release, like KEYS, at the top. Such an organization would
allow a user browsing the directories to download both the binary and
source releases for a particular version, perhaps slightly more easily.
I can also see the value of top level "binaries, source, docs"
organization, because a user browsing the directory would likely have in
mind one of these things they want to go after (although, that might run
into difficulties if we distribute things that don't fall into these
categories, at some point).
-Marshall
Michael Baessler wrote:
> Robert Burrell Donkin wrote:
>> On Dec 19, 2007 9:28 PM, Marshall Schor <ms...@schor.com> wrote:
>>
>>> Michael, can you upload? I think a good candidate layout for uploading
>>> would be:
>>>
>>> ...dist/uima/KEYS where the public keys go
>>>
>>> The httpd project has an organization of
>>> binaries / release-id'd artifacts << for binaries
>>> docs / release-id'd artifacts << for documentation
>>> (nothing) / release-id'd artifacts << for source,
>>> announcements
>>>
>>> They also have at the top level, besides the KEYS dir,
>>> Announcement-<release-version>
>>> CHANGES-<release-version>
>>>
>>
>> if you're going to stuff at the top level, a header.html can sometimes
>> be useful (see eg http://www.apache.org/dist/httpd/)
>>
>>
>>> libapreq << a place to put libraries which are prereqs, I think,
>>> which don't change from release to release.
>>> patches << a place to put patches to releases
>>> tools << tools they use to create releases (this seems the
>>> wrong place to put such things, to me).
>>>
>>> An alternative would be to switch the order:
>>> start with the release-id (e.g. uimaj-2.2.1-incubating)
>>> and have under it:
>>> bin
>>> src
>>> doc
>>>
>>> Any opinions as to preferences? Robert - is there a "best practice"
>>> here?
>>>
>>
>> there are several reasonable starting points for developing a process
>> that works.
>>
>> you've already highlighted httpd which usually sets a standard.
>>
>> ant is another standard followed by many projects including commons.
>> see http://www.apache.org/dist/ant/ and
>> http://commons.apache.org/releases/mirror.html. the idea is that easy
>> symlinks are available from the top level.
>>
>> review a few strategies and then see what's likely to works best for
>> UIMA
>>
>>
>>> My slight preference is to have, for those things that occur with every
>>> release, the organization of
>>> uimaj-2.2.1-incubating / bin
>>> uimaj-2.2.1-incubating / src
>>> uimaj-2.2.1-incubating / doc
>>>
>>> I think this will make "archiving the release as a unit, somewhat
>>> easier.
>>>
>>
>> archiving is done automatically (by a sync). all that matters is to
>> remember to delete old releases from dist (it's usually a release
>> manager task - when a new release is added, an older one is deleted.)
>>
>> - robert
>>
> I would prefer an organization similar to ant or http like:
>
> binaries/uimaj-2.2.1-incubating/<artifacts>
> source/uimaj-2.2.1-incubating/<artifacts>
> docs/uimaj-2.2.1-incubating/<artifacts>
> KEYS/<keys file>
>
> with that layout the automatic archiving is structured as well. Since
> we have the same layout.
> As far as I understand the automatic archiving.
>
> Do all agree with that layout?
>
> -- Michael
>
>
>
>
Re: Release Upload
Posted by Michael Baessler <mb...@michael-baessler.de>.
Robert Burrell Donkin wrote:
> On Dec 19, 2007 9:28 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> Michael, can you upload? I think a good candidate layout for uploading
>> would be:
>>
>> ...dist/uima/KEYS where the public keys go
>>
>> The httpd project has an organization of
>> binaries / release-id'd artifacts << for binaries
>> docs / release-id'd artifacts << for documentation
>> (nothing) / release-id'd artifacts << for source, announcements
>>
>> They also have at the top level, besides the KEYS dir,
>> Announcement-<release-version>
>> CHANGES-<release-version>
>>
>
> if you're going to stuff at the top level, a header.html can sometimes
> be useful (see eg http://www.apache.org/dist/httpd/)
>
>
>> libapreq << a place to put libraries which are prereqs, I think,
>> which don't change from release to release.
>> patches << a place to put patches to releases
>> tools << tools they use to create releases (this seems the
>> wrong place to put such things, to me).
>>
>> An alternative would be to switch the order:
>> start with the release-id (e.g. uimaj-2.2.1-incubating)
>> and have under it:
>> bin
>> src
>> doc
>>
>> Any opinions as to preferences? Robert - is there a "best practice" here?
>>
>
> there are several reasonable starting points for developing a process
> that works.
>
> you've already highlighted httpd which usually sets a standard.
>
> ant is another standard followed by many projects including commons.
> see http://www.apache.org/dist/ant/ and
> http://commons.apache.org/releases/mirror.html. the idea is that easy
> symlinks are available from the top level.
>
> review a few strategies and then see what's likely to works best for UIMA
>
>
>> My slight preference is to have, for those things that occur with every
>> release, the organization of
>> uimaj-2.2.1-incubating / bin
>> uimaj-2.2.1-incubating / src
>> uimaj-2.2.1-incubating / doc
>>
>> I think this will make "archiving the release as a unit, somewhat easier.
>>
>
> archiving is done automatically (by a sync). all that matters is to
> remember to delete old releases from dist (it's usually a release
> manager task - when a new release is added, an older one is deleted.)
>
> - robert
>
I would prefer an organization similar to ant or http like:
binaries/uimaj-2.2.1-incubating/<artifacts>
source/uimaj-2.2.1-incubating/<artifacts>
docs/uimaj-2.2.1-incubating/<artifacts>
KEYS/<keys file>
with that layout the automatic archiving is structured as well. Since we have the same layout.
As far as I understand the automatic archiving.
Do all agree with that layout?
-- Michael
Re: Release Upload
Posted by Marshall Schor <ms...@schor.com>.
Robert Burrell Donkin wrote:
> ...
> if you're going to stuff at the top level, a header.html can sometimes
> be useful (see eg http://www.apache.org/dist/httpd/)
>
I see in that directory two "special" files: HEADER.html and
README.html. When the httpd server builds a page for the directory
listing, it shows:
HEADER
directory content display (minus the HEADER and README)
README
I found this reference that describes what's going on:
http://hoohoo.ncsa.uiuc.edu/docs/tutorials/index-tutorial.html
-Marshall
Re: Release Upload
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Dec 19, 2007 9:28 PM, Marshall Schor <ms...@schor.com> wrote:
> Michael, can you upload? I think a good candidate layout for uploading
> would be:
>
> ...dist/uima/KEYS where the public keys go
>
> The httpd project has an organization of
> binaries / release-id'd artifacts << for binaries
> docs / release-id'd artifacts << for documentation
> (nothing) / release-id'd artifacts << for source, announcements
>
> They also have at the top level, besides the KEYS dir,
> Announcement-<release-version>
> CHANGES-<release-version>
if you're going to stuff at the top level, a header.html can sometimes
be useful (see eg http://www.apache.org/dist/httpd/)
> libapreq << a place to put libraries which are prereqs, I think,
> which don't change from release to release.
> patches << a place to put patches to releases
> tools << tools they use to create releases (this seems the
> wrong place to put such things, to me).
>
> An alternative would be to switch the order:
> start with the release-id (e.g. uimaj-2.2.1-incubating)
> and have under it:
> bin
> src
> doc
>
> Any opinions as to preferences? Robert - is there a "best practice" here?
there are several reasonable starting points for developing a process
that works.
you've already highlighted httpd which usually sets a standard.
ant is another standard followed by many projects including commons.
see http://www.apache.org/dist/ant/ and
http://commons.apache.org/releases/mirror.html. the idea is that easy
symlinks are available from the top level.
review a few strategies and then see what's likely to works best for UIMA
> My slight preference is to have, for those things that occur with every
> release, the organization of
> uimaj-2.2.1-incubating / bin
> uimaj-2.2.1-incubating / src
> uimaj-2.2.1-incubating / doc
>
> I think this will make "archiving the release as a unit, somewhat easier.
archiving is done automatically (by a sync). all that matters is to
remember to delete old releases from dist (it's usually a release
manager task - when a new release is added, an older one is deleted.)
- robert
Re: Release Upload
Posted by Marshall Schor <ms...@schor.com>.
Michael, can you upload? I think a good candidate layout for uploading
would be:
...dist/uima/KEYS where the public keys go
The httpd project has an organization of
binaries / release-id'd artifacts << for binaries
docs / release-id'd artifacts << for documentation
(nothing) / release-id'd artifacts << for source, announcements
They also have at the top level, besides the KEYS dir,
Announcement-<release-version>
CHANGES-<release-version>
libapreq << a place to put libraries which are prereqs, I think,
which don't change from release to release.
patches << a place to put patches to releases
tools << tools they use to create releases (this seems the
wrong place to put such things, to me).
An alternative would be to switch the order:
start with the release-id (e.g. uimaj-2.2.1-incubating)
and have under it:
bin
src
doc
Any opinions as to preferences? Robert - is there a "best practice" here?
My slight preference is to have, for those things that occur with every
release, the organization of
uimaj-2.2.1-incubating / bin
uimaj-2.2.1-incubating / src
uimaj-2.2.1-incubating / doc
I think this will make "archiving the release as a unit, somewhat easier.
For things that users may want to "scan" in order to pick the "right"
release, we probably should pull these up to the top level, like in
httpd. I'm thinking here of
Announcement<version> and
Changes<version>
-Marshall
Robert Burrell Donkin wrote:
> /dist/incubator/uima now exists on people. feel free to upload the
> latest release, sums, sigs, KEYS and documentation. the release
> shouldn't be announced until the mirroring script is done and tests
> but there's no need for the upload to wait on the script.
>
> NB
>
> 1. ***NEVER*** alter any document placed in dist
> 2. check that public keys are in place (see
> http://www.apache.org/dev/new-committers-guide.html#pgp)
> 3. double check permissions on releases after upload
>
> if anyone has any questions, please feel free to ask
>
> - robert
>
>
>