You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2009/08/18 19:55:59 UTC

[Solr Wiki] Trivial Update of "HowToRelease" by YonikSeeley

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The following page has been changed by YonikSeeley:
http://wiki.apache.org/solr/HowToRelease

The comment on the change is:
emphasise that things don't have to be done this way

------------------------------------------------------------------------------
+ This page is to help a Solr committer create a new release (you need committer rights for some of the steps to create an official release).  It does not reflect official release policy - many of the items may be optional, or may be modified as necessary.
- ''This page is prepared for Solr committers. You need committer rights 
- to create a new  Solr release.''
  
  [[TableOfContents]]
  
@@ -23, +22 @@

   * Are bug fixes found because of improved test coverage
   * Are new tests and bug fixes for new bugs encountered by manually testing
  
- = Steps For Release Engineer =
+ = Steps For Release Engineer (and others helping) =
  
  == Before building release ==
   1. Check that Solr works on the latest versions of Jetty, Tomcat, and Resin.

Re: Fwd: [Solr Wiki] Trivial Update of "HowToRelease" by YonikSeeley

Posted by Chris Hostetter <ho...@fucit.org>.
: > + This page is to help a Solr committer create a new release (you need
: > committer rights for some of the steps to create an official release).  It
: > does not reflect official release policy - many of the items may be
: > optional, or may be modified as necessary.
: > - ''This page is prepared for Solr committers. You need committer rights
: > - to create a new  Solr release.''
: 
: I really don't think this is a good idea.  What gets released and how it gets
: released should not be up to the RM.  We as a community have agreed to support
: the artifacts we produce.  One individual should not then get to undermine
: that b/c they don't have a particular use for some particular artifact or
: release step.

This feels like a disagreement of semantics...

the community helps shape the release guidelines via the wiki, but 
strictly speaking yonik is correct: it's not formal policy (the PMC didn't 
vote on it).  The RM can follow those guidelines as tightly/loosely as 
they choose to make an RC but they have to put it to a vote of the PMC 
before it is truely a release -- If the PMC feels community concencus was 
not followed closely enough by the RM, the release won't get the votes it 
needs.


-Hoss


Fwd: [Solr Wiki] Trivial Update of "HowToRelease" by YonikSeeley

Posted by Grant Ingersoll <gs...@apache.org>.

Begin forwarded message:

> From: Apache Wiki <wi...@apache.org>
> Date: August 18, 2009 1:55:59 PM EDT
> To: solr-commits@lucene.apache.org
> Subject: [Solr Wiki] Trivial Update of "HowToRelease" by YonikSeeley
> Reply-To: solr-dev@lucene.apache.org
>
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Solr Wiki"  
> for change notification.
>
> The following page has been changed by YonikSeeley:
> http://wiki.apache.org/solr/HowToRelease
>
> The comment on the change is:
> emphasise that things don't have to be done this way
>
> ------------------------------------------------------------------------------
> + This page is to help a Solr committer create a new release (you  
> need committer rights for some of the steps to create an official  
> release).  It does not reflect official release policy - many of the  
> items may be optional, or may be modified as necessary.
> - ''This page is prepared for Solr committers. You need committer  
> rights
> - to create a new  Solr release.''

I really don't think this is a good idea.  What gets released and how  
it gets released should not be up to the RM.  We as a community have  
agreed to support the artifacts we produce.  One individual should not  
then get to undermine that b/c they don't have a particular use for  
some particular artifact or release step.