> In recent years the role of the 'bug fixes only' series
> has been played by the Known Problems page for each
> 3.14.x release and the associated patches linked
> from that page
But, known problems patches currently reflect only
a limited subset of quick fixes for known issues,
and not all of the other patches available in a
point release?
So, under the proposed approach to point releases, after
installing such patches the net result remains a release
with both the patches and also new features and this
might lead some users to conclude that they are better
off with an un-patched release if the bug isn't (yet)
directly experienced by the EPICS system manager.
> Using a DVCS and publishing lots of branches allows
> us to to avoid having to choose a single direction
> for evolution before the development on each is
> finished; I see that as much more Darwinian (and
> less risky) than the old CVS approach of having
> a single branch for future evolution.
So the primary difference is that there are many
evolutionary branches and no mechanism to start
deciding ahead of time on a single branch that
will become our future. So lots of work can occur
with little confidence (substantial risk) that
any of it will ever be used. Also with a designated
evolution branch users see where we are headed
and can try out one single branch that reflects
that trajectory.
> As Ralph pointed out, your work is not yet
> suitable for merging, and you haven't posted
> a merge proposal for it
That’s definitely true. I'm not proposing a
merge of the new serer at this time.
> I would recommend doing it in a series of
> branches which will be easier to review
I definitely plan to break up the merge into
components. Perhaps like this.
o several independent merges for libCom
o data access
o the server (or both the server
and data access together)
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Thursday, June 24, 2010 3:37 PM
> To: Jeff Hill
> Cc: 'Core-Talk'
> Subject: Re: Merges: 3.14.12 vs 3.15
>
> Hi Jeff,
>
> On Thursday 24 June 2010 15:16:25 Jeff Hill wrote:
> > > If I understand Jeff's position correctly (correct me
> > > if I'm wrong Jeff) he says that minor releases should
> > > only contain bug fixes and no new features.
> >
> > Yep, that’s still my perspective. From my viewpoint we should be
> especially
> > careful to not mix up patches with new features. For two reasons. One,
> we
> > don’t ever want a situation where the user looses confidence about
> > installing patches because they might introduce new bugs. Second, we
> work
> > on a special type of software which people depend on. A selling point
> of
> > EPICS is that we have maintained a certain level of quality in the
> past.
> > Sometime a conservative approach is necessary.
>
> In recent years the role of the 'bug fixes only' series has been played
> by the
> Known Problems page for each 3.14.x release and the associated patches
> linked
> from that page. The branch lp:~epics-core/epics-base/3.14.11+patches
> makes
> the fully-patched 3.14.11 code available for download using Bazaar, but I
> do
> admit this is a fairly recent product. In the days of using CVS I don't
> think
> anyone was willing to maintain such a branch, but it should be easier to
> do
> with Bazaar.
>
> > Maybe the solution is to have three independent release series: maybe
> we
> > should have the stable production release, the near term features
> release,
> > and the evolution release. With that approach we can have an
> independent
> > release series on all three versions simultaneously. With this approach
> it
> > needs to be very clear to everyone involved where we are headed. That
> is,
> > it needs to be very clear that day-to-day support of the production
> release
> > will after some longer period of time go away, the near term release
> will
> > be eventually declared to be the production release, and the evolution
> > release will eventually become the near-term feature release. What do
> you
> > think?
>
> The way I see it, 3.14.11+patches is our stable production release, the
> 3.14
> series is our near-term features release, and the other branches in
> Bazaar
> demonstrate the directions we might go in. Using a DVCS and publishing
> lots
> of branches allows us to to avoid having to choose a single direction for
> evolution before the development on each is finished; I see that as much
> more
> Darwinian (and less risky) than the old CVS approach of having a single
> branch
> for future evolution.
>
> > Lastly, I have to say that its disturbing that my new server with
> server
> > based event filtering isn't even discussed as an option for the list
> for
> > any release. I have been working very hard to get this finished. Yes,
> its
> > new code, but if regression tests are reasonably exhaustive and we are
> > clear about how and where new releases should be used then I don't see
> a
> > problem.
>
> As Ralph pointed out, your work is not yet suitable for merging, and you
> haven't posted a merge proposal for it (he is wrong about the code
> visibility
> though, your changes are on the cvs-trunk branch). The branches I
> discussed
> are all listed at https://code.launchpad.net/epics-base/+activereviews as
> they
> have open reviews. I'm not ignoring your work, but it's up to you to
> bring it
> up for discussion with a merge proposal once it's ready for merging.
> (Note
> that it will have to be re-based onto the 3.14 or a future 3.15 branch
> first
> though, and I would recommend doing it in a series of branches which will
> be
> easier to review.)
>
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harald Welte
- Replies:
- Re: Merges: 3.14.12 vs 3.15 Ralph Lange
- References:
- Merges: 3.14.12 vs 3.15 Andrew Johnson
- RE: Merges: 3.14.12 vs 3.15 Jeff Hill
- Re: Merges: 3.14.12 vs 3.15 Andrew Johnson
- Navigate by Date:
- Prev:
Re: Merges: 3.14.12 vs 3.15 Andrew Johnson
- Next:
Re: Merges: 3.14.12 vs 3.15 Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Merges: 3.14.12 vs 3.15 Andrew Johnson
- Next:
Re: Merges: 3.14.12 vs 3.15 Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|