[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Getting Bug 1256 fixed

From: Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
Date: 2005-11-23 10:24:51 CET

Hi,

Would anyone be able / willing to upgrade the branch to be against the
latest stable trunk. This would probably help the developers to
incorporate it as then the changes will be against a more recent code
base, and would help all of the current users to update their subversion
servers.

Thanks,

Graeme

-----Original Message-----
From: Mark Phippard [mailto:markp@softlanding.com]
Sent: 22 November 2005 19:37
To: Gale, David
Cc: Thompson, Graeme (AELE); Garrett Rooney; users@subversion.tigris.org
Subject: RE: Re: Getting Bug 1256 fixed

"Gale, David" <David.Gale@Hypertherm.com> wrote on 11/22/2005 02:28:09
PM:

> Garrett Rooney wrote:
> > On 11/22/05, Thompson, Graeme (AELE)
> > <Graeme.Thompson@smiths-aerospace.com> wrote:
> >>
> >> What would you suggest would be the best way to get this issue
fixed?
> >>
> >> A working path has existed for months, but it has not been
> >> incorporated into the main trunk. It shouldn't be a massive effort
> >> to get this done.
> >
> > Convincing the developers that the feature is worth having. This
> > means that it's useful, and that the patch is good, and that it
> > doesn't make the code or UI overly complex and unmaintainable.
> >
> > Note that these are exactly the same steps that every single change
> > to Subversion has to go through, this is no different. If nobody is

> > willing to shepherd the change through until it can be committed,
> > then it simply won't be, that's how open source works.
>
> So, other than pestering the dev list (which would be bad), or getting

> added to the dev team (which isn't something everyone can do), what
> should people do? If you look back through this thread, you'll see my

> analysis of the votes in the Subversion Issue Tracker, and the
> comments that voting doesn't really seem to affect the dev team's
> decisions. How else can we go about "convincing the developers that
> the feature is worth having...useful...good", etc.?
>
> I frankly don't know.
>
> Voting for Issues makes the most sense, but if the dev team is
> unwilling to pay attention to the desires of the community as
> explicitly expressed by that voting, what is the community supposed to
do?

I am not one of the devs. Please keep that in mind.

As I have understood this issue from past messages, the problem is that
the Devs have been looking for a design proposal. Right now there is a
patch and there are some emails that explain what it does etc.. But
what they would really like to see is a design proposal for the feature
that can be discussed and agreed upon. Once that is done, then the
patch can begin to be reviewed and modified such that it corresponds to
the design document.

If you want to do something, forget that this patch exists and try to
instead begin the process of designing the feature. If the feature is
agreed upon and well-designed then there might be more developer
interest in tackling it.

Mark

________________________________________________________________________
_____
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs.
________________________________________________________________________
_____

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 23 10:30:57 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.