db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject RE: Planning
Date Mon, 08 Oct 2012 18:45:46 GMT
> 1) It is still undecided whether we want to include documentation with the
>    binary releases. Currently they only contain the jar and their 
>    dependencies.

AFAIK, there is no requirement for this. I do think it's important for folks
to be able to be able to access offline docs for a specific version. But the
binary jars does not seem to be the right place for this. I'd say that there
docs should be in the source or a separate download and the binary distro
readme should point to where they can be downloaded. 

> 2) It is also undecided whether we want to provide source packages for the
>    single modules.

The requirements in www.apache.org/dev/release.html says: 

... must contain a source package, which must be sufficient for a user to 
build and test the release..

Unless we plan to change our release/versioning process to allow for different
versions of sub modules, I think the single all in one source is fine.
> 3) We need to switch the site publishing mechanism to svnpubsub until the
>    end of year [1]. So some change in the site publishing mechanism is 
>    needed. We need to consider the following:
>  - We need a location for the site in svn (currently the "default location"   
>    db/torque/site is occupied by the torque 3 site project, see also (5))
>  - We probably want to retain the documentation for older releases
>  - It should be no hassle to create a new site version directory (as we now 
>    have for the old docs of 3.1, 3.2, and the new 4.0 but not the current
>    3.3 docs)

The strategy Thomas F proposes seems OK. E.g. site-svnpubsub with subdirs for
each release. Maybe scm-site or site-scm would be a shorter name?

> 4) How much time do we allow for testing before the first attempt to release
>    4.0 ?

4.0 is a major change.  I think folks will be a bit slow to start kicking 
the tires due to the learning curve.  2 months might be enough, but I don't
think we'd really get a lot of extra testers in that time frame.  

On the other hand, if stuff pops up after 4.0 is released, it seems like all
the good work done to automate the release process would make it easier to
do a 4.1 with fixes.

I think as long as we know there wouldn't be too many months between
missing features reports (e.g. I used to be able to do..) and a release
that corrects them, a short 2 month test time is OK.

BTW - Did any notices of the beta release go out?  E.g. in the site news and
to torque-users?  If folks don't know it's there, they probably won't test 
with their local code.

> 5) Do we want to reorganize svn by putting the torque 3 resources into a
>    separate place ?

+1... but we should make sure it's well noted in the site.  This means
that folks with local projects that pull from svn will need to update
their local settings.  When such stuff breaks, it should be easy to find
a notice that the structure has changed.

Maybe there should be some "pre-notices" too.  E.g, a note on the site,
to this list, and to torque-user that the svn structure will change on
a specific date (or date range).

> 6) I'd like to improve the online docs further by dropping the strict 
>    separation between modules in the docs.

+1 - I think this would allow for some needed overview and "rabbit trail"
type organization.  E.g., what to read to understand using torque 
vs what to read for modifying/developing topics. 

I think we sort of have this now, but you have to understand which 
sub-project you need... which you don't until you start learning things. Lol.

DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.

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

View raw message