On Thu, Feb 28, 2008 at 11:57 AM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> On Thu, Feb 28, 2008 at 8:34 PM, David Waite <dwaite_at_gmail.com> wrote:
> > I think its rather obvious that the subversion development model is too
> > rigid.
>
> I'm interested in hearing from you why you think that, especially
> because I see nothing wrong with the model itself. I do see large
> problems with how we implement our release schedule, but our API
> versioning rules don't really require us to do so few releases...
>
>
> > I believe moving to a development tree that is allowed to break
> > compatibility for several 'development' releases would be a good, however it
> > would be important not to move too far in the other direction and lose
> > pragmatism, and become an endless project.
>
>
>
> > Hopefully the delays and difficulties in 1.5 show that when functionality is
> > done, it needs to be given to users ASAP, in a sense making the project more
> > pragmatic :)
>
> I do agree that it's vital to get something out to users, but I'm
> wondering what it is that *you* require most. My question comes from
> the following: If we had released more often in the past 2 years (that
> is 1.4 > 1.5 > 1.6), we just would have released some of the other
> features, but not merge tracking: it simply has been declared 'done'
> only quite recently.
>
> In other words, moving to a more pragmatic model wouldn't have served
> the 'merge tracking' users more than the current model.
>
> Taking that into account, what do *you* hope to win with a different
> model? (Sincere question!)
>
>
> Bye,
>
>
> Erik.
>
>
While more frequent releases wouldn't have gotten merge tracking any sooner,
I am also waiting for the http proxy support, svnserve/SASL
authentication, and sparse directories.
_Any_ one of these would have been enough for me to upgrade from 1.4.
I personally don't see a release that 'only' 25% of the
userbase would upgrade to as a bad thing. The people that care about
the feature(s) will be happy they are available, and those changes get
real-world testing while the others are being developed.
Since these are all rolled up into one big release, tweaks any of the
features will have to wait until the next (maybe way off) release to
get any tweaks. I think that no being able to reduce the depth of a
working copy is a big missing feature - I'm not looking forward to
telling users to delete their working copy and start over. In the
more frequent release model this type of tweak (if it ends up being
important to users in general) can make it into users' hands much
quicker.
Looking forward to 1.5....
Roy
>
> > On Thu, Feb 28, 2008 at 10:02 AM, Justin Erenkrantz <justin_at_erenkrantz.com>
> > wrote:
> > >
> > > On Thu, Feb 28, 2008 at 6:40 AM, C. Michael Pilato <cmpilato_at_collab.net>
> > wrote:
> > > > Maybe it's time to rethink the model. Maybe we should get 1.5 out the
> > door,
> > > > roll 1.6 with tree conflicts detection and Kamesh's merge algorithm
> > > > improvements and whatever other mostly-done things can be finalized and
> > > > delivered in under 6 months, and then seriously take on the challenge
> > of
> > > > Subversion 2.0.
> > >
> > > While I'm behind doing a quick 1.6 follow-on to 1.5 if that's what's
> > > needed, but I shudder at yet another drawn-out release cycle. If we
> > > go down that 2.0 route, I'd want us to quickly churn out 2.x releases
> > > rather then re-entering the never-never-land that 1.5's been in.
> > >
> > > I do disagree with epg and mostly agree with C-Mike though on the
> > > broader issue. A lot of the complaints that epg raised don't warrant
> > > to me that we release 1.5 as a 'tech preview' but instead that we keep
> > > improving what we have. I *hate* *hate* the idea of not doing more
> > > releases more frequently and think we've shot ourselves in the foot
> > > with that. A lot of the complaints that were raised could have been
> > > resolved if we had gotten our code out quicker to test rather then
> > > letting it sit in trunk for years waiting for anyone other than the
> > > original contributors giving feedback to the changes. The best way to
> > > get the code improved is to do releases and get feedback on it. We
> > > have never said that our releases are perfect - hence I think
> > > 'technology preview' is more of the same ultra-conservatism and
> > > paralysis that has struck us lately.
> > >
> > > For the issues that epg raised that I personally contributed to, I'm
> > > happy to fix bugs on 'em, but without any other user, as long as it
> > > works for me, I'm not likely to tweak it. =) -- justin
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> > > For additional commands, e-mail: dev-help_at_subversion.tigris.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-28 21:47:38 CET