You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Leo Simons <ma...@leosimons.com> on 2007/12/18 13:25:19 UTC
freedom to do sane release management (was: Approve release Apache UIMA...)
On Dec 16, 2007, at 5:24 AM, William A. Rowe, Jr. wrote:
> Marshall Schor wrote:
>> We've put the LICENSE, NOTICES, and DISCLAIMERs into the top
>> directory
>> of the source (and binary) distribution(s), but didn't realize
>> this also
>> needs to be in the top level of the SVN tag, because we didn't
>> know that
>> was considered part of the "distribution".
This should be fine. SVN tags are *not* distributions.
>> Can you please confirm this is the case? In which case, we'll of
>> course
>> comply.
Nope, that can't really be confirmed. Apologies for any confusion.
> Your distribution must correspond to subversion
And for the record, I'm also against making this a rule in the
future. I can think of many good reasons why there is some disconnect.
> otherwise it's very hard to track (...)
I can think of many good ways to track exactly what goes into a
distribution and how, that do not require satisfying this rule.
I think you are confusing requirements with a particular approach to
satisfying those requirements.
We should not dictate every detail of how projects do release
management or build engineering. The best way to do those things
depends on the project. (And nobody likes being dictated how to do
things, either.)
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management
Posted by Thilo Goetz <tw...@gmx.de>.
Luciano Resende wrote:
> I guess, from the Incubator release management guide, the requirement
> is that the release can be built from a tag, in a later point in
> time...
>
> "All releases should be built from a tag. It is occasionally necessary
> to rebuild releases many years later. Tagging is cheap and easy when
> using subversion. So, every release and candidate should be tagged."
>
> [1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-source
>
Which is an eminently sensible requirement, and I'm
not debating it. I also agree that the build process
should be automated and must be repeatable.
The question is if the process how the release is
"built from a tag" may be more complicated than a simple
tarring up of the svn extract. I think the notion of
"build" here is what we usually understand by a software
build, an automated, repeatable process. So in the case
of UIMA, we copy a handful of files from their usual nether
svn regions to the top level directory (to comply with
release layout policy for the most part), and then tar
the whole. So under a reasonable interpretation of that
paragraph, we do comply with it.
--Thilo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Dec 18, 2007 2:55 PM, Leo Simons <ma...@leosimons.com> wrote:
> On Dec 18, 2007, at 3:24 PM, Luciano Resende wrote:
> > I guess, from the Incubator release management guide, the requirement
> > is that the release can be built from a tag, in a later point in
> > time...
>
> While that's a good (and standard) practice, it's not quite a
> requirement. There can be good reasons to build from a branch. Due to
> how subversion works, tagging is more a convention than it is a
> necessity.
the release management guide is *very* much a draft and should be
considered alpha quality at best
i put it up in that state in the hope that projects looking to pull
together their own strategy would have a starting point and
> > "All releases should be built from a tag. It is occasionally necessary
> > to rebuild releases many years later. Tagging is cheap and easy when
> > using subversion. So, every release and candidate should be tagged."
> >
> > [1] http://incubator.apache.org/guides/releasemanagement.html#best-
> > practice-source
>
> Yup. Note it also says
>
> This is a first draft intended to allow public review. (...)
> This document is descriptive, not normative. It aims to guide
>
> podlings through the process of release management. (...)
>
> It contains advice on best practice (...)
the draft is just a brain dump and lacks proper structure
> the policy document which has the *requirements* is at
>
> http://incubator.apache.org/incubation/
> Incubation_Policy.html#Releases
>
> and it's not nearly as demanding.
policy is policy but the guides are not-normative
> If you're going to ask me whether you should always tag and release
> from a tag, I will answer "yes, that'd be good". But if you don't tag
> and ask me to vote on a release, I might still vote +1 :-)
+1 :-)
those who have the energy to review and vote set the criteria by which
releases are judged. at best, the guide was intended to help projects
struggling to understand the release culture.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache
UIMA...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Leo Simons wrote:
> On Dec 18, 2007, at 11:50 PM, William A. Rowe, Jr. wrote:
>
>> The bottom line of release management in the ASF.
>>
>> > All artifacts should be generated from the tagged SVN <
>
> That just isn't the bottom line. It's only the bottom line in some
> projects.
>
> The point is that, on the whole, there are many many ways to do really
> good and really dilligent release management, including doing very good
> tracking of everything in version control, yet still do a lot of things
> very differently.
I don't think we disagree all that much, although my point of placing
the LICENSE, COPYRIGHT, NOTICE out front no matter how an individual
chooses to obtain ASF source code still stands :)
Reproduceable as things stood at that time is certainly good enough for
me, and you offer lots of illustrations. Not reproducible (by forgetting
to tag externals, for example) is usually a bad idea.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Dec 19, 2007 5:43 PM, Leo Simons <ma...@leosimons.com> wrote:
<snip>
> The second point is that there's a frequent tendency among incubator
> PMC members (and, err, most other human beings) to take their own
> opinions and experience about what constitutes reasonable practice
> and turn that into policy, taking away key elements such as self-
> governance in the process. This is just the one example. Do everyone
> a favor, work a little harder, and find the *real* thing we need to
> see ensured, independently of your own habits or preferences.
this is why i've been trying to increase guidance and reduce policy. i
think that writing up opinions into guidance is useful. ideally it
should provide a starting point for communities to develop their own
process. in my own mind, i'd like a release guide which any podling
can mine to create their own, personal release guide. it's tough to
start from nothing and a waste of effort to learn the hard way. better
to read, think then choose. (perhaps a guide guide is needed to
explain that guides are not policy but just a starting point for
podlings to develop their own best practices...)
on that note: leo any objections to me mining your post for the
release documentation...?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Posted by Leo Simons <ma...@leosimons.com>.
On Dec 18, 2007, at 11:50 PM, William A. Rowe, Jr. wrote:
> Noel J. Bergman wrote:
>> I disagree. I agree with the statement that "All releases should
>> be built
>> from a tag." Worst case, you should make the tag by copying from
>> the right
>> version.
That'd be a different rule; it's a tiny bit less broken a rule. Bill
initially said "Your distribution must correspond to subversion",
specifically objecting to a scenario where the distribution was in
fact generated from a subversion tag, but a bit differently structured.
It's still a bad rule, because you're taking a (questionable) version
control convention and making a rule out of it. The rules you're
looking for are something like
All source code in a source distribution should arrive in that
source
distribution using a repeatable procedure with an acceptable
source
control system providing the master source, and both the
repeatable
procedure and source control itself must be auditable.
SVN is an acceptable source control system.
Creating a straighforward tarball directly from an svn export is
acceptable as a repeatable release-building procedure, though the
expectation is that this is automated using a script.
> The bottom line of release management in the ASF.
>
> > All artifacts should be generated from the tagged SVN <
That just isn't the bottom line. It's only the bottom line in some
projects.
It isn't ASF-wide policy, and if it were policy, it would not be a
good policy, and would also not be enforceable. Just a few use cases
that invalidate such a potential rule:
built from tag, plus svn:externals
* I have many subprojects that need the same license files. I put the
license files in a central place, and then use svn:externals to
pull
in the files during checkout, and they get copied during the
tarball
build
built from tag, plus svn metadata
* I generate my ChangeLog from `svn log --xml`, which is done by a
the
same script that produces the tarball. The ChangeLog itself never
makes it into SVN as its derivative of svn data itself.
built from tag, plus non-tag svn metadata
* I generate my ChangeLog directly from my branch because
'--stop-on-copy' will do the right thing
built from tag, plus additional files from other information system
* I fetch documentation directly from our wiki installation for
inclusion
into every source distribution. I don't want to put the 40
megabytes of
documentation into SVN.
documentation distribution
* my project is a CMS. We eat our own dogfood and maintain all our
documentation inside an instance of our own CMS. I fetch
documentation
directly from that CMS and generate a documentation distribution
out of
it, thus showcasing how great my CMS is every time I do a release.
my project does not use tags
* I understand how subversion works internally, think that the
trunk/branches/tags structure is a silly convention which does
not make
sense to use for my project because we have historically been
supportive of the development mode used for distributed VC, so
we have
a lot of branches and a lot of semi-independent tips
my project doesn't like unresolveable URLs
* I fetch the LICENSE at build-time from
http://www.apache.org/licenses/LICENSE-2.0
(yes, of course I program defensively and ensure a 200 return
code and
check the content of the file is roughly what I expected)
You can obviously argue against any particular one of these and
invent "what ifs" that, unless addressed, make it a bad idea to do
things that way. They're just examples.
The point is that, on the whole, there are many many ways to do
really good and really dilligent release management, including doing
very good tracking of everything in version control, yet still do a
lot of things very differently.
The second point is that there's a frequent tendency among incubator
PMC members (and, err, most other human beings) to take their own
opinions and experience about what constitutes reasonable practice
and turn that into policy, taking away key elements such as self-
governance in the process. This is just the one example. Do everyone
a favor, work a little harder, and find the *real* thing we need to
see ensured, independently of your own habits or preferences.
The third point is that making sweeping statements about what must
and must not happen probably does not help anyone, not when you do it
off-the-cuff, without having some reference to any documentation or e-
mail thread or whatever to back up the statement. And especially note
when you swept a little too far.
ciao!
/LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache
UIMA...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Noel J. Bergman wrote:
>
> I disagree. I agree with the statement that "All releases should be built
> from a tag." Worst case, you should make the tag by copying from the right
> version.
The bottom line of release management in the ASF.
> All artifacts should be generated from the tagged SVN <
So whatever you put together in a package should come from the tag, and
as Noel points out, if you've 'goofed', it's not hard to tag after the
fact based on the svn rev you used in the first place.
The deeper question, is LICENSE/NOTICE ever an artifact? No, those
LICENSE/NOTICE files must always be present in the source code tree.
Our code, no matter if it's checked out of svn, grabbed from a snapshot
or from a full release must always carry the correct copyright, license
and notice.
Consider some different files, README or CHANGES. Perhaps your project's
build schema wants to assemble those from multiple files, some .xml sources
etc. at packaging time. As long as these artifacts are generated from the
contents of the tagged source code tree, that's never a problem.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: freedom to do sane release management (was: Approve release Apache UIMA...)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
I disagree. I agree with the statement that "All releases should be built
from a tag." Worst case, you should make the tag by copying from the right
version.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Posted by Leo Simons <ma...@leosimons.com>.
On Dec 18, 2007, at 3:24 PM, Luciano Resende wrote:
> I guess, from the Incubator release management guide, the requirement
> is that the release can be built from a tag, in a later point in
> time...
While that's a good (and standard) practice, it's not quite a
requirement. There can be good reasons to build from a branch. Due to
how subversion works, tagging is more a convention than it is a
necessity.
> "All releases should be built from a tag. It is occasionally necessary
> to rebuild releases many years later. Tagging is cheap and easy when
> using subversion. So, every release and candidate should be tagged."
>
> [1] http://incubator.apache.org/guides/releasemanagement.html#best-
> practice-source
Yup. Note it also says
This is a first draft intended to allow public review. (...)
This document is descriptive, not normative. It aims to guide
podlings through the process of release management. (...)
It contains advice on best practice (...)
the policy document which has the *requirements* is at
http://incubator.apache.org/incubation/
Incubation_Policy.html#Releases
and it's not nearly as demanding.
If you're going to ask me whether you should always tag and release
from a tag, I will answer "yes, that'd be good". But if you don't tag
and ask me to vote on a release, I might still vote +1 :-)
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Posted by Luciano Resende <lu...@gmail.com>.
I guess, from the Incubator release management guide, the requirement
is that the release can be built from a tag, in a later point in
time...
"All releases should be built from a tag. It is occasionally necessary
to rebuild releases many years later. Tagging is cheap and easy when
using subversion. So, every release and candidate should be tagged."
[1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-source
On Dec 18, 2007 4:25 AM, Leo Simons <ma...@leosimons.com> wrote:
> On Dec 16, 2007, at 5:24 AM, William A. Rowe, Jr. wrote:
> > Marshall Schor wrote:
> >> We've put the LICENSE, NOTICES, and DISCLAIMERs into the top
> >> directory
> >> of the source (and binary) distribution(s), but didn't realize
> >> this also
> >> needs to be in the top level of the SVN tag, because we didn't
> >> know that
> >> was considered part of the "distribution".
>
> This should be fine. SVN tags are *not* distributions.
>
> >> Can you please confirm this is the case? In which case, we'll of
> >> course
> >> comply.
>
> Nope, that can't really be confirmed. Apologies for any confusion.
>
> > Your distribution must correspond to subversion
>
> And for the record, I'm also against making this a rule in the
> future. I can think of many good reasons why there is some disconnect.
>
> > otherwise it's very hard to track (...)
>
> I can think of many good ways to track exactly what goes into a
> distribution and how, that do not require satisfying this rule.
>
> I think you are confusing requirements with a particular approach to
> satisfying those requirements.
>
> We should not dictate every detail of how projects do release
> management or build engineering. The best way to do those things
> depends on the project. (And nobody likes being dictated how to do
> things, either.)
>
> cheers!
>
> - Leo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org