[VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

Hiram Chirino
In accordance with the incubator release procedure (see below) the
Apache ActiveMQ community has voted on and approved the 4.0.2 release
binary.  The last time  release candidate was  up for vote, it was
rejected due to issues with licence headers.  Those have now been
resolved.

We would now like to request the permission of the Incubator PMC to
perform the release.

Release notes:
http://incubator.apache.org/activemq/activemq-402-release.html

Vote thread:
http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200609.mbox/%3caf2843cd0609260630i2dc3ad27x363460bbb5fdb42b@...%3e

Vote result:
The VOTE has passed with 7 ppmc +1's and no -1s.

+1 Hiram Chirino
+1 James Strachan
+1 Rob Davies
+1 Guillaume Nodet
+1 Brian McCallister
+1 Alan D. Cabrera
+1 Aaron Mulder


Release tarball:
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC4/maven1/incubator-activemq/distributions/

Releases section of the Incubation Policy:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Here's my non binding +1

--
Regards,
Hiram

Blog: http://hiramchirino.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

James.Strachan
+1 from me.

On 10/2/06, Hiram Chirino <[hidden email]> wrote:

> In accordance with the incubator release procedure (see below) the
> Apache ActiveMQ community has voted on and approved the 4.0.2 release
> binary.  The last time  release candidate was  up for vote, it was
> rejected due to issues with licence headers.  Those have now been
> resolved.
>
> We would now like to request the permission of the Incubator PMC to
> perform the release.
>
> Release notes:
> http://incubator.apache.org/activemq/activemq-402-release.html
>
> Vote thread:
> http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200609.mbox/%3caf2843cd0609260630i2dc3ad27x363460bbb5fdb42b@...%3e
>
> Vote result:
> The VOTE has passed with 7 ppmc +1's and no -1s.
>
> +1 Hiram Chirino
> +1 James Strachan
> +1 Rob Davies
> +1 Guillaume Nodet
> +1 Brian McCallister
> +1 Alan D. Cabrera
> +1 Aaron Mulder
>
>
> Release tarball:
> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC4/maven1/incubator-activemq/distributions/
>
> Releases section of the Incubation Policy:
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> Here's my non binding +1
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

Hiram Chirino
In reply to this post by Hiram Chirino
Hi ActiveMQ Project Mentors...

If you get a chance, could you please checkout the release and cast a
vote.  Thanks!

On 10/2/06, Hiram Chirino <[hidden email]> wrote:

> In accordance with the incubator release procedure (see below) the
> Apache ActiveMQ community has voted on and approved the 4.0.2 release
> binary.  The last time  release candidate was  up for vote, it was
> rejected due to issues with licence headers.  Those have now been
> resolved.
>
> We would now like to request the permission of the Incubator PMC to
> perform the release.
>
> Release notes:
> http://incubator.apache.org/activemq/activemq-402-release.html
>
> Vote thread:
> http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200609.mbox/%3caf2843cd0609260630i2dc3ad27x363460bbb5fdb42b@...%3e
>
> Vote result:
> The VOTE has passed with 7 ppmc +1's and no -1s.
>
> +1 Hiram Chirino
> +1 James Strachan
> +1 Rob Davies
> +1 Guillaume Nodet
> +1 Brian McCallister
> +1 Alan D. Cabrera
> +1 Aaron Mulder
>
>
> Release tarball:
> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC4/maven1/incubator-activemq/distributions/
>
> Releases section of the Incubation Policy:
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> Here's my non binding +1
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>


--
Regards,
Hiram

Blog: http://hiramchirino.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

brianm
In reply to this post by James.Strachan
+1 (again :-)

-Brian

On Oct 2, 2006, at 7:50 AM, James Strachan wrote:

> +1 from me.
>
> On 10/2/06, Hiram Chirino <[hidden email]> wrote:
>> In accordance with the incubator release procedure (see below) the
>> Apache ActiveMQ community has voted on and approved the 4.0.2 release
>> binary.  The last time  release candidate was  up for vote, it was
>> rejected due to issues with licence headers.  Those have now been
>> resolved.
>>
>> We would now like to request the permission of the Incubator PMC to
>> perform the release.
>>
>> Release notes:
>> http://incubator.apache.org/activemq/activemq-402-release.html
>>
>> Vote thread:
>> http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 
>> 200609.mbox/%
>> [hidden email]%3e
>>
>> Vote result:
>> The VOTE has passed with 7 ppmc +1's and no -1s.
>>
>> +1 Hiram Chirino
>> +1 James Strachan
>> +1 Rob Davies
>> +1 Guillaume Nodet
>> +1 Brian McCallister
>> +1 Alan D. Cabrera
>> +1 Aaron Mulder
>>
>>
>> Release tarball:
>> http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC4/ 
>> maven1/incubator-activemq/distributions/
>>
>> Releases section of the Incubation Policy:
>> http://incubator.apache.org/incubation/ 
>> Incubation_Policy.html#Releases
>>
>> Here's my non binding +1
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

robert burrell donkin-2
In reply to this post by Hiram Chirino
On 10/2/06, Hiram Chirino <[hidden email]> wrote:
> In accordance with the incubator release procedure (see below) the
> Apache ActiveMQ community has voted on and approved the 4.0.2 release
> binary.  The last time  release candidate was  up for vote, it was
> rejected due to issues with licence headers.  Those have now been
> resolved.
>
> We would now like to request the permission of the Incubator PMC to
> perform the release.

apologies for missing this one earlier :-/

RAT run:

i'm happy that most of the files without headers don't require them
(too small to have copyright)

there are a number of java script files with missing license headers:

http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web/src/main/resources/org/apache/activemq/web/_amq.js
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web/src/main/resources/org/apache/activemq/web/amq.js

http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/common.js
worries me since it doesn't look like it was created at apache and i
cannot see a license header.
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/styles/style.css
is similar.

http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/mochi/MochiKit.js
looks to be MIT but isn't mention in the LICENSE file nor does it have
a header.

a number of files in
http://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0.2/systest/jmscts/resources/
 seem to lack headers but i'm wondering whether they are generated
since i can't seem to find them in the trunk. can you clear up this
mystery.

http://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0.2/systest/jmscts/src/java/org/exolab/jmscts/activemq/ActiveMQProvider.java
requries an entry in the NOTICE file. the license should probably also
be included in the LICENSE (see below).

incubator-activemq-4.0.2.jar contains the LICENSE and the disclaimer
but is missing a NOTICE. this is needed if
incubator-activemq-4.0.2.jar is to be distributed from a repository.

notes:

http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web/src/main/resources/org/apache/activemq/web/behaviour.js
is BSD licensed (which is fine) but probably wants a mention at the
bottom of the LICENSE file. for example, see
http://incubator.apache.org/guides/examples/LICENSE. same goes for
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web/src/main/resources/org/apache/activemq/web/prototype.js,
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/css.js.
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/plotkit/Base.js
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/plotkit/Canvas.js
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/plotkit/Layout.js
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/plotkit/SweetCanvas.js
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/plotkit/SweetSVG.js
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/plotkit/iecanvas.htc
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-demo/src/main/webapp/js/scriptaculous.js
and http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-web-console/src/main/webapp/js/standardista-table-sorting.js


the source distributions unpacks to the same directory as the binary.
this is inconvenient for users. it's better to unpack the source to
incubator-activemq-4.0.2-src.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

Roy T. Fielding
On Oct 9, 2006, at 2:59 PM, robert burrell donkin wrote:
> the source distributions unpacks to the same directory as the binary.
> this is inconvenient for users. it's better to unpack the source to
> incubator-activemq-4.0.2-src.

I disagree with that.  Usually, a source distribution should be the
entire distribution tree before an ant/make/maven, and the binary
distribution should overlay on top of that into new subdirs
of the main tree.  Some of the duplicate files get replaced that way,
but it is better for the user to have one tree.

I don't think there is a generally accepted Apache way of separating
these things, since the really important part is the source tree.
I think it is important to make it clear that the binaries are just
a convenience layer and not a separate distribution (even if they are
distributed separately).

....Roy


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ

robert burrell donkin-2
On 10/10/06, Roy T. Fielding <[hidden email]> wrote:

> On Oct 9, 2006, at 2:59 PM, robert burrell donkin wrote:
> > the source distributions unpacks to the same directory as the binary.
> > this is inconvenient for users. it's better to unpack the source to
> > incubator-activemq-4.0.2-src.
>
> I disagree with that.  Usually, a source distribution should be the
> entire distribution tree before an ant/make/maven, and the binary
> distribution should overlay on top of that into new subdirs
> of the main tree.  Some of the duplicate files get replaced that way,
> but it is better for the user to have one tree.

providing that the unpacking application doesn't decide to trash the
entire directory (which is thankfully less common these days). an
overlay would work well provided that the binary distribution is
reasonable congruent in structure with the source. not very useful if
they differ too radically in structure.

> I don't think there is a generally accepted Apache way of separating
> these things,

true

i've never heard anyone defend this position before. unless you plan
to patch it (add the content anywhere: the documents a mess but it'll
be easy enough to pull together once the content's written) i'll add
something about this alternative strategy into the draft release
managment document.

separate source is the jakarta style of releases and is what a lot of
users expect it for that reason. the advantage for developers is that
they can unpack a source release next to their current checkout. (not
sure that's as important now with subversion.) users tend to use the
binary (which often contains the source now) but is structured for
easy use rather than easy development.

> since the really important part is the source tree.

i've been surprised by the number of proposals which are binary only

> I think it is important to make it clear that the binaries are just
> a convenience layer and not a separate distribution (even if they are
> distributed separately).

finding clear and appropriate langauge is tough. i don't like calling
them binary and source releases. i prefer to talk about a single
release with different types of distribution (source and binaries) for
the reason that they are the same release distributed separately.

any better suggestions?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Release Requirements

Noel J. Bergman
In reply to this post by Roy T. Fielding
Roy T. Fielding wrote:

> > robert burrell donkin wrote:
> > the source distributions unpacks to the same directory as the binary.
> > this is inconvenient for users. it's better to unpack the source to
> > incubator-activemq-4.0.2-src.

> I disagree with that.

> I don't think there is a generally accepted Apache way of separating
> these things, since the really important part is the source tree.
> I think it is important to make it clear that the binaries are just
> a convenience layer and not a separate distribution (even if they are
> distributed separately).

Can we agree that regardless of which style one might prefer the packaging,
there are multiple valid approaches, and that this level of difference
should not be a release criteria for the Incubator?

The Mentors can and should engage the community on best practices.  When the
Incubator PMC is presented with a release to approve, we ought to focus on
actual requirements, such as:

        Licensing
        Notification
        Signing (if we choose to enforce this)
     ...

And what those actual requirements are should be documented so that the
projects aren't surprised when submitting their request.  If we decide to
add requirements, we should agree to add them to the release requirements
document.

Agreed?

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

Yoav Shapira-2
Hi,

On 10/12/06, Noel J. Bergman <[hidden email]> wrote:
> Can we agree that regardless of which style one might prefer the packaging,
> there are multiple valid approaches, and that this level of difference
> should not be a release criteria for the Incubator?

Yes, agreed, +1.  This is a technical decision to be made by the
project team in the best interest of their users, not by the Incubator
PMC.

Yoav

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

Endre Stølsvik-3
Yoav Shapira wrote:

> Hi,
>
> On 10/12/06, Noel J. Bergman <[hidden email]> wrote:
>> Can we agree that regardless of which style one might prefer the
>> packaging,
>> there are multiple valid approaches, and that this level of difference
>> should not be a release criteria for the Incubator?
>
> Yes, agreed, +1.  This is a technical decision to be made by the
> project team in the best interest of their users, not by the Incubator
> PMC.
>

My two (probably rather worthless) cents:

I find it slightly annoying that even different bin-balls within commons
have different layouts when you unpack them. In particular when there
are dependencies - you will actually have to check out each and every
thing you download, and in some instances also download the src package,
and some packages even don't have a "root dir", thus unpacking directly
in current dir (that is however more or less unified now, isn't it?)

In particular "libraries" would benefit a lot if there was a common way
that they were packaged. For example that the binary distribution had a
<packagename>-ide.jar (or whatever you'd want to call them), having the
source-files for easy integration into your ide, and maybe that the
javadoc was at a predefined place. What about version-naming of the
jars? Versioning of the root-dir?
   Check out CPAN - that's structure for you!

Regards,
Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Release Requirements

Noel J. Bergman
Endre Stølsvik wrote:

> My two (probably rather worthless) cents:

Not at all worthless.  What you posted is perfectly valid feedback, and
should be considered by projects.  But does it rise to the standard of
needing to be enforced?

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

Endre Stølsvik-3
Noel J. Bergman wrote:
> Endre Stølsvik wrote:
>
>> My two (probably rather worthless) cents:
>
> Not at all worthless.  What you posted is perfectly valid feedback, and
> should be considered by projects.  But does it rise to the standard of
> needing to be enforced?

In my opinion, yes.

This is because if not, every project might insist that "their packaging
is better", or just not think about it, and thus not follow the defacto
standard, if there is such a thing.

Why are there such differences now, then?

This is, if one would go for such an approach, a top-level decision that
shouldn't be up to the projects to decide - you're "apache compliant"
only if you follow this packaging. And it really isn't a big enforcement
either, it's just that it should be crammed in from the get-go, so that
the projects do think about it, and started out in line with the rest.

Note that I do not in any way suggest that the entire layout of the
system, nor the build system (!!) or similar should be enforced, just
the end-packaging for the "bins" (which really is what (most) people
download - they want "the working stuff", the open source aspect is in
this regard just a potential tailorability and important safety (and
hopefully quality) sign).

Regards,
Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

jboynes
In reply to this post by Noel J. Bergman
On Oct 12, 2006, at 8:13 AM, Noel J. Bergman wrote:

>
> The Mentors can and should engage the community on best practices.  
> When the
> Incubator PMC is presented with a release to approve, we ought to  
> focus on
> actual requirements, such as:
>
> Licensing
> Notification
> Signing (if we choose to enforce this)
>      ...

I would say that the IPMC should focus on the process the podling  
used to prepare the release. Oversight from the Mentors or other IPMC  
members on the PPMC should mean that by time the release is presented  
to the IPMC the requirements already have been met. This not only  
ensures that the release content meets the ASF requirements but also  
that the PPMC members know what is involved.

The IPMC still needs to review the actual release but to some degree  
they should be able to rely on the votes from the Mentors. Ideally  
the Mentors would be able to vote based on their review at the PPMC  
stage.

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

Eelco Hillenius
In reply to this post by Endre Stølsvik-3
On 10/12/06, Endre Stølsvik <[hidden email]> wrote:

> Noel J. Bergman wrote:
> > Endre Stølsvik wrote:
> >
> >> My two (probably rather worthless) cents:
> >
> > Not at all worthless.  What you posted is perfectly valid feedback, and
> > should be considered by projects.  But does it rise to the standard of
> > needing to be enforced?
>
> In my opinion, yes.
>
> This is because if not, every project might insist that "their packaging
> is better", or just not think about it, and thus not follow the defacto
> standard, if there is such a thing.
>
> Why are there such differences now, then?
>
> This is, if one would go for such an approach, a top-level decision that
> shouldn't be up to the projects to decide - you're "apache compliant"
> only if you follow this packaging. And it really isn't a big enforcement
> either, it's just that it should be crammed in from the get-go, so that
> the projects do think about it, and started out in line with the rest.
>
> Note that I do not in any way suggest that the entire layout of the
> system, nor the build system (!!) or similar should be enforced, just
> the end-packaging for the "bins" (which really is what (most) people
> download - they want "the working stuff", the open source aspect is in
> this regard just a potential tailorability and important safety (and
> hopefully quality) sign).

Imo ASF has enough written and unwritten rules. Following discussions
on this forum since a few weeks feels like making the transition from
a small young company to a large old one, where procedures and
politics are more prevalent than a more practical 'can do' spirit.
Sorry, no offense intended. I just think that 'enforcing' anything
other than the bare necessities is a bad idea. Whether it is the
binary packaging, whether to have discussions on IRC or distributing
incubator releases via a maven repo. Forcing rules rather then
encouraging best practices is counter is hard to achieve and only
irritating for those who still don't agree even if they gave it a
serious thought. A more positive approach - documenting, discussing
and automated support like maven does provide with it's standard
layout and distros - works much better imho.

My lousy 2c :)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

robert burrell donkin-2
In reply to this post by Noel J. Bergman
On 10/12/06, Noel J. Bergman <[hidden email]> wrote:

> Roy T. Fielding wrote:
>
> > > robert burrell donkin wrote:
> > > the source distributions unpacks to the same directory as the binary.
> > > this is inconvenient for users. it's better to unpack the source to
> > > incubator-activemq-4.0.2-src.
>
> > I disagree with that.
>
> > I don't think there is a generally accepted Apache way of separating
> > these things, since the really important part is the source tree.
> > I think it is important to make it clear that the binaries are just
> > a convenience layer and not a separate distribution (even if they are
> > distributed separately).
>
> Can we agree that regardless of which style one might prefer the packaging,
> there are multiple valid approaches, and that this level of difference
> should not be a release criteria for the Incubator?

the only critieria we have is three +1's

> The Mentors can and should engage the community on best practices.  When the
> Incubator PMC is presented with a release to approve, we ought to focus on
> actual requirements, such as:
>
>         Licensing
>         Notification
>         Signing (if we choose to enforce this)
>      ...

the reason i didn't +1 wasn't anything to do with the unpacking but
the fact that there are a lot of files without license headers and so
of dubious original.

> And what those actual requirements are should be documented so that the
> projects aren't surprised when submitting their request.  If we decide to
> add requirements, we should agree to add them to the release requirements
> document.

we don't have a requirements document. we don't have a requirements
process. it's a simple vote.

when i review a release, i post additional feedback after critical
issues in a section called notes. the comment about source directory
was in that section. perhaps i'll change the format so that it's a
little more obvious that these are comments intended as feedback.
unfotunately, all the context was cut so it's not clear to people
jumping onto the thread.

i've never heard anyone defend intentionally unpacking into the same
directory before. i was genuinely interested that people do this for a
reason. this happens quite often by mistake so i try to pick it up as
feedback.

> Agreed?

nope :-)

i'm not willing to +1 a release that i'm not personally happy with.

the only reasons why my refusal to +1 a release makes any difference
is that too few PMCers review releases. if PMCers feel strongly about
this issue then they should devote the hour or so that each release
takes to review.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

robert burrell donkin-2
In reply to this post by Noel J. Bergman
On 10/12/06, Noel J. Bergman <[hidden email]> wrote:
> Endre Stølsvik wrote:
>
> > My two (probably rather worthless) cents:
>
> Not at all worthless.  What you posted is perfectly valid feedback, and
> should be considered by projects.  But does it rise to the standard of
> needing to be enforced?

IMO the time a PMCer -1's a release for unpacking to the wrong
directory is the time to start worrying about enforcement

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

robert burrell donkin-2
In reply to this post by Endre Stølsvik-3
On 10/12/06, Endre Stølsvik <[hidden email]> wrote:

> Yoav Shapira wrote:
> > Hi,
> >
> > On 10/12/06, Noel J. Bergman <[hidden email]> wrote:
> >> Can we agree that regardless of which style one might prefer the
> >> packaging,
> >> there are multiple valid approaches, and that this level of difference
> >> should not be a release criteria for the Incubator?
> >
> > Yes, agreed, +1.  This is a technical decision to be made by the
> > project team in the best interest of their users, not by the Incubator
> > PMC.
> >
>
> My two (probably rather worthless) cents:
>
> I find it slightly annoying that even different bin-balls within commons
> have different layouts when you unpack them. In particular when there
> are dependencies - you will actually have to check out each and every
> thing you download, and in some instances also download the src package,
> and some packages even don't have a "root dir", thus unpacking directly
> in current dir (that is however more or less unified now, isn't it?)

yeh - i've heard these kinds criticisms a lot from users over the
years (and been on the receiving end of too many)

> In particular "libraries" would benefit a lot if there was a common way
> that they were packaged. For example that the binary distribution had a
> <packagename>-ide.jar (or whatever you'd want to call them), having the
> source-files for easy integration into your ide, and maybe that the
> javadoc was at a predefined place. What about version-naming of the
> jars? Versioning of the root-dir?

i'm not in favour of enforcing standardization but i do think that a
menu of best practices from which a podling can choose is good. i also
think that a project which has no particularly strong opinions on
conventions such as versioning, naming and layout then should consider
adopting a pattern used widely elsewhere. hopefully the documentation
will capture this one day. until then, i'll continue to offer what
feedback i can whilst i'm reviewing a release.

>    Check out CPAN - that's structure for you!

:-)

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

Endre Stølsvik
In reply to this post by Eelco Hillenius
Eelco Hillenius wrote:

> On 10/12/06, Endre Stølsvik <[hidden email]> wrote:
>> Noel J. Bergman wrote:
>> > Endre Stølsvik wrote:
>> >
>> >> My two (probably rather worthless) cents:
>> >
>> > Not at all worthless.  What you posted is perfectly valid feedback,
>> and
>> > should be considered by projects.  But does it rise to the standard of
>> > needing to be enforced?
>>
>> In my opinion, yes.
>>
>> This is because if not, every project might insist that "their packaging
>> is better", or just not think about it, and thus not follow the defacto
>> standard, if there is such a thing.
>>
>> Why are there such differences now, then?
>>
>> This is, if one would go for such an approach, a top-level decision that
>> shouldn't be up to the projects to decide - you're "apache compliant"
>> only if you follow this packaging. And it really isn't a big enforcement
>> either, it's just that it should be crammed in from the get-go, so that
>> the projects do think about it, and started out in line with the rest.
>>
>> Note that I do not in any way suggest that the entire layout of the
>> system, nor the build system (!!) or similar should be enforced, just
>> the end-packaging for the "bins" (which really is what (most) people
>> download - they want "the working stuff", the open source aspect is in
>> this regard just a potential tailorability and important safety (and
>> hopefully quality) sign).
>
> Imo ASF has enough written and unwritten rules. Following discussions
> on this forum since a few weeks feels like making the transition from
> a small young company to a large old one, where procedures and
> politics are more prevalent than a more practical 'can do' spirit.
It's also often the difference between an dotcom upstart company that
probably won't make it, and a tried and tested, experienced company that
generates cash. Or whatever.
> Sorry, no offense intended. I just think that 'enforcing' anything
> other than the bare necessities is a bad idea. Whether it is the
> binary packaging, whether to have discussions on IRC or distributing
> incubator releases via a maven repo.
(This is beside the point, but what's the point in coming to Apache in
the first place?)

Things such as putting your jar here, and naming it in this way, with
versioning, and having the src-jar in the same dir, with the same name,
and some bla bla bla.. These aren't very limiting rules that will tie
you up in months agonizing to comply by. They are really just "know how"
from the good old company that knows, after years and years of doing
this stuff, what works and what doesn't. And downloading 5 tarballs that
all unpack differently just doesn't work for a company as reputable as
Apache!

This is stretching the dot-com vs. good'ol company analogy a little far.
But yes, I guess we do disagree: I get your analogy, and I still think
it would be right to enforce these simple things!

> Forcing rules rather then
> encouraging best practices is counter is hard to achieve and only
> irritating for those who still don't agree even if they gave it a
> serious thought.
Best practices could work too, if it was "this is REALLY the way to do
it". Is there any such document? (If yes, then just make it a
requirement, and you're there!)
> A more positive approach - documenting, discussing
> and automated support like maven does provide with it's standard
> layout and distros - works much better imho.
Automating is just the thing I want, e.g. when downloading a bunch of
stupid dependencies that I don't care for at all, it's just that the
damn thing doesn't work without them. But automation requires a little
work upfront - that's the whole point. And the work here, is actually to
put them deliverances in those right holes, so that an automatic
process, or my idling brain, can do the thing without any further thoughts.

Regards,
Endre

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release Requirements

Eelco Hillenius
> > Imo ASF has enough written and unwritten rules. Following discussions
> > on this forum since a few weeks feels like making the transition from
> > a small young company to a large old one, where procedures and
> > politics are more prevalent than a more practical 'can do' spirit.
> It's also often the difference between an dotcom upstart company that
> probably won't make it, and a tried and tested, experienced company that
> generates cash. Or whatever.

Yeah, we probably have a different view of the world. In my personal
experience, large companies typically perform really poor on IT
projects. They survived the .COM companies because IT wasn't their
core business, or they had enough of a buffer. But hey, that's just my
limited view of the world :)

> > Sorry, no offense intended. I just think that 'enforcing' anything
> > other than the bare necessities is a bad idea. Whether it is the
> > binary packaging, whether to have discussions on IRC or distributing
> > incubator releases via a maven repo.
> (This is beside the point, but what's the point in coming to Apache in
> the first place?)

Having a consistent packaging wouldn't be my number one reason. There
are many reasons why Apache is interesting to join, like being part of
a community where people care about building great software and
believe in open source software.

> Automating is just the thing I want, e.g. when downloading a bunch of
> stupid dependencies that I don't care for at all, it's just that the
> damn thing doesn't work without them. But automation requires a little
> work upfront - that's the whole point. And the work here, is actually to
> put them deliverances in those right holes, so that an automatic
> process, or my idling brain, can do the thing without any further thoughts.

Cool with me :) I was just triggered by the 'enforcing' bit, which I
believe should only be used in the context of legal issues and things
of which you can objectively state that if rules are not followed,
it'll be bad for ASF.

Regards,

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Release Requirements

Martijn Dashorst
In reply to this post by Endre Stølsvik
Endre,

I think you are missing the community part of ASF. ASF is not a
company, nor a big old business. It is a community with a variety of
projects, and as such a variety of packaging demands and wishes.

I like the idea of a (pretty) low bar entry to Apache where the only
criteria are the ones currently stated in the incubator graduation
requirements.

Adding release particulars to these requirements is in my opinion too
restrictive and too cumbersome for any project.

We can't go and enforce all projects to release their artifacts on
ibiblio in the maven repository. This would be very strange indeed for
httpd or xmlc. We can't enforce that all projects have to supply an
ant file for their build infrastructure, again this doesn't make sense
in a C, perl, or python project. We can't enforce one type of
code/project documentation standard: enforcement of txt, doxia,
forrest, docbook, latex, tex, odf, sxw, doc, rtf, etc.
Any project may choose what kind of documentation it creates, in what
format it is released and maintained. We could argue that the format
should be an open format, this being an open source community, but
again I think this is something the community of the project should
decide as they are their primary users.

The only requirements ASF should enforce on projects is that they
comply with the basic principles of the ASF in a legal and community
sense. Anything else should be handled by the community/project
itself, including how to compose a release.

Martijn

On 10/12/06, Endre Stølsvik <[hidden email]> wrote:

> Eelco Hillenius wrote:
> > On 10/12/06, Endre Stølsvik <[hidden email]> wrote:
> >> Noel J. Bergman wrote:
> >> > Endre Stølsvik wrote:
> >> >
> >> >> My two (probably rather worthless) cents:
> >> >
> >> > Not at all worthless.  What you posted is perfectly valid feedback,
> >> and
> >> > should be considered by projects.  But does it rise to the standard of
> >> > needing to be enforced?
> >>
> >> In my opinion, yes.
> >>
> >> This is because if not, every project might insist that "their packaging
> >> is better", or just not think about it, and thus not follow the defacto
> >> standard, if there is such a thing.
> >>
> >> Why are there such differences now, then?
> >>
> >> This is, if one would go for such an approach, a top-level decision that
> >> shouldn't be up to the projects to decide - you're "apache compliant"
> >> only if you follow this packaging. And it really isn't a big enforcement
> >> either, it's just that it should be crammed in from the get-go, so that
> >> the projects do think about it, and started out in line with the rest.
> >>
> >> Note that I do not in any way suggest that the entire layout of the
> >> system, nor the build system (!!) or similar should be enforced, just
> >> the end-packaging for the "bins" (which really is what (most) people
> >> download - they want "the working stuff", the open source aspect is in
> >> this regard just a potential tailorability and important safety (and
> >> hopefully quality) sign).
> >
> > Imo ASF has enough written and unwritten rules. Following discussions
> > on this forum since a few weeks feels like making the transition from
> > a small young company to a large old one, where procedures and
> > politics are more prevalent than a more practical 'can do' spirit.
> It's also often the difference between an dotcom upstart company that
> probably won't make it, and a tried and tested, experienced company that
> generates cash. Or whatever.
> > Sorry, no offense intended. I just think that 'enforcing' anything
> > other than the bare necessities is a bad idea. Whether it is the
> > binary packaging, whether to have discussions on IRC or distributing
> > incubator releases via a maven repo.
> (This is beside the point, but what's the point in coming to Apache in
> the first place?)
>
> Things such as putting your jar here, and naming it in this way, with
> versioning, and having the src-jar in the same dir, with the same name,
> and some bla bla bla.. These aren't very limiting rules that will tie
> you up in months agonizing to comply by. They are really just "know how"
> from the good old company that knows, after years and years of doing
> this stuff, what works and what doesn't. And downloading 5 tarballs that
> all unpack differently just doesn't work for a company as reputable as
> Apache!
>
> This is stretching the dot-com vs. good'ol company analogy a little far.
> But yes, I guess we do disagree: I get your analogy, and I still think
> it would be right to enforce these simple things!
>
> > Forcing rules rather then
> > encouraging best practices is counter is hard to achieve and only
> > irritating for those who still don't agree even if they gave it a
> > serious thought.
> Best practices could work too, if it was "this is REALLY the way to do
> it". Is there any such document? (If yes, then just make it a
> requirement, and you're there!)
> > A more positive approach - documenting, discussing
> > and automated support like maven does provide with it's standard
> > layout and distros - works much better imho.
> Automating is just the thing I want, e.g. when downloading a bunch of
> stupid dependencies that I don't care for at all, it's just that the
> damn thing doesn't work without them. But automation requires a little
> work upfront - that's the whole point. And the work here, is actually to
> put them deliverances in those right holes, so that an automatic
> process, or my idling brain, can do the thing without any further thoughts.
>
> Regards,
> Endre
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12