You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2004/03/10 23:17:56 UTC
Justifications for porting to 1.0.x, and meaning of "sandbox" [Re:
svn commit: r8974 - branches/1.0.x]
breser@tigris.org wrote:
> Author: breser
> Date: Wed Mar 10 15:39:53 2004
> New Revision: 8974
>
> Modified:
> branches/1.0.x/STATUS
> Log:
> STATUS: Add 1.0.1 candidates for r8966, r8969 and Issue #1755
>
> Modified: branches/1.0.x/STATUS
> ==============================================================================
> --- branches/1.0.x/STATUS (original)
> +++ branches/1.0.x/STATUS Wed Mar 10 15:39:53 2004
> @@ -81,3 +81,22 @@
> externals in particular cases.
> Votes:
> +1: cmpilato
> +
> + * r8966
> + Use cpio to generate tarballs.
> + Justification: Tarballs built with GNU tar will not extract on platforms
> + without GNU tar due to filename length.
Fine: that describes a reasonably serious problem, so it's quite likely that we will agree to fix it.
> + Votes:
> +
> + * r8969
> + Do not copy doc/book/book/images into sandbox.
> + Justification: We end up with duplicate images dir and the files are
> + already there.
That's a fine description of the bug but not a justification of why this patch should go into the 1.0.x branch. Only important and/or safe bug fixes should be ported into the branch. Perhaps a better justification could be something like, "This wastes a large amount of space in the tarball [or whatever the truth is]" or "This doesn't cause much of a problem but the fix is simple and safe."
By the way, what I understand by the word "sandbox" is a place for playing around and making a mess, knowing that it can all be swept away afterwards, such as a sandpit for children to play in or a box of sand on or in which to do experiments with fire. Thus, in software terms, a temporary directory tree or repository in which to run tests or mess round with unstable software, after which you delete the whole thing. I'm not sure that this agrees with what you call a "sandbox" above.
> + Votes:
> +
> + * Issue #1775
> + Allow reverting a replaced file with no properties.
> + Justification: It's a bug.
Again, is it a bug with significant consequences or a simple and safe fix?
> + Notes: Patch on issue will require the regression test be moved to a
> + different file, because we don't have that file.
> + Votes:
Thanks for taking note of these issues and proposing them. I'm not saying that they don't belong on the branch, just that it isn't yet clear to me whether they do.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Justifications for porting to 1.0.x, and meaning of "sandbox"
[Re: svn commit: r8974 - branches/1.0.x]
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:
> On Wed, Mar 10, 2004 at 11:17:56PM +0000, Julian Foad wrote:
>
>>breser@tigris.org wrote:
>>
>>>+ * r8969
>>>+ Do not copy doc/book/book/images into sandbox.
>>>+ Justification: We end up with duplicate images dir and the files are
>>>+ already there.
>>
>>That's a fine description of the bug but not a justification of why this
[...]
>
> Okay updating to make it clearer.
Thanks.
>>By the way, what I understand by the word "sandbox" is a place for playing
[...]
>
> I'm just using the terminology used in the script. The directory that
> ends up in the tarball is built in .dist_sandbox. Which after the
> tarballs are made is competely removed.
Oh, good - so what I thought it meant is the same as what other people think. That's nice to know.
>>>+ * Issue #1775
>>>+ Allow reverting a replaced file with no properties.
>>>+ Justification: It's a bug.
>>
>>Again, is it a bug with significant consequences or a simple and safe fix?
>
> Results in a somewhat wedged working copy. The fix is straightforward.
> We tested to see if a file existed. But didn't bother to check the
> results of the test. The fix simply looks at the result of the test and
> behaves the same way as we do in other cases. I'll update the STATUS
> file on this too.
Thanks, Ben.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Justifications for porting to 1.0.x, and meaning of "sandbox" [Re: svn commit: r8974 - branches/1.0.x]
Posted by Ben Reser <be...@reser.org>.
On Wed, Mar 10, 2004 at 11:17:56PM +0000, Julian Foad wrote:
> breser@tigris.org wrote:
> >+ Votes:
> >+
> >+ * r8969
> >+ Do not copy doc/book/book/images into sandbox.
> >+ Justification: We end up with duplicate images dir and the files are
> >+ already there.
>
> That's a fine description of the bug but not a justification of why this
> patch should go into the 1.0.x branch. Only important and/or safe bug
> fixes should be ported into the branch. Perhaps a better justification
> could be something like, "This wastes a large amount of space in the
> tarball [or whatever the truth is]" or "This doesn't cause much of a
> problem but the fix is simple and safe."
Okay updating to make it clearer.
> By the way, what I understand by the word "sandbox" is a place for playing
> around and making a mess, knowing that it can all be swept away afterwards,
> such as a sandpit for children to play in or a box of sand on or in which
> to do experiments with fire. Thus, in software terms, a temporary
> directory tree or repository in which to run tests or mess round with
> unstable software, after which you delete the whole thing. I'm not sure
> that this agrees with what you call a "sandbox" above.
I'm just using the terminology used in the script. The directory that
ends up in the tarball is built in .dist_sandbox. Which after the
tarballs are made is competely removed.
> >+ Votes:
> >+
> >+ * Issue #1775
> >+ Allow reverting a replaced file with no properties.
> >+ Justification: It's a bug.
>
> Again, is it a bug with significant consequences or a simple and safe fix?
Results in a somewhat wedged working copy. The fix is straightforward.
We tested to see if a file existed. But didn't bother to check the
results of the test. The fix simply looks at the result of the test and
behaves the same way as we do in other cases. I'll update the STATUS
file on this too.
> Thanks for taking note of these issues and proposing them. I'm not saying
> that they don't belong on the branch, just that it isn't yet clear to me
> whether they do.
Fair enough.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org