[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] Re: Bug 1655 crmd stucks in S_TERMINATE when
From:       Max Hofer <max.hofer () apus ! co ! at>
Date:       2007-07-24 12:56:01
Message-ID: 200707241456.01442.max.hofer () apus ! co ! at
[Download RAW message or body]

On Tuesday 24 July 2007, Alan Robertson wrote:
> Max Hofer wrote:
> > On Monday 23 July 2007, Alan Robertson wrote:
> >> Keisuke MORI wrote:
> >>> Hi,
> >>>
> >>> I filed a bug on the subject and cc-ing to the ML and Alan
> >>> just in case if this might affect to the upcoming release.
> >>> http://old.linux-foundation.org/developer_bugzilla/show_bug.cgi?id=1655
> >>>
> >>> As I wroted on the bugzilla, we found this during our regression test.
> >>> We suffered this problem on 2.0.8 first and then it seemed to be solved
> >>> with the dev version, so we really have been longing and waiting
> >>> for the fix is in the official release.
> >>>
> >>> Is there any chance to fix this bug very soon?
> >>
> >> Hi,
> >>
> >> If I delay the release by one week, I'll have to delay it by probably
> >> about 3 weeks.  But, if the fix is in 'dev', it's probably in 'test' -
> >> unless it went in during the last week.
> >>
> >> I think a better approach would be to go ahead and put out the release,
> >> and then put out another release in 4-6 weeks or so.
> >>
> >> Everyone agrees a different release methodology is needed.  I have some
> >> suggestions for how to improve things, but I need to think about them
> >> some more.  I'll put out my proposal later this week.   Hopefully in a
> >> week or two of discussion, we can agree on some improvements.
> >> Surprisingly, I think most people are likely to agree with the most
> >> important of my suggestions.
> >>
> >> In 3-4 weeks we can grab everything in 'dev' and put it into 'test'
> >> again, and then people can start testing the 2.1.2 release.
> >>
> >> For those who wonder, yes I do plan on snapshotting and building the
> >> 2.1.0 release - primarily for historical purposes.
> >
> > I hope I'm not too impatient ;-)
> >
> > What about "bugfix-only-releases"? (we already had this discussion)
> >
> > But I think a lot of users do "not want" (they have to stick to one
> > version and avoid upgradring for a long time) new releases but bug fix
> > releases with bugs classifiied as "severe" (remember the memory leaks
> > 2.0.8 had).
> >
> > If 2.1.2 is going to be a snapshot of dev in 4 weeks I guess by my
> > definition 2.1.1.1 would be a bug-fix release.
> >
> > I know, it needs effort. Specially if dev is growing away from the
> > current 2.1.1.
> >
> > But I think it is affordable for at least 2 or 3 releases (assuming there
> > are about 4 release/year). And maybe we find a enough persons who would
> > like to make a kind of maintainer for one release.
>
> The process of putting out a release will never happen instantaneously.
>  And, if it's done right, there is always the risk that bug fixes
> currently available won't make it in.  This risk will never go away, as
> far as I can see.
I know - if not there would never be a release. 

What i meant is following scenarios:

a) bug report from customer/user of an old release (which aparently can only 
be of a previous release, lets say 2.1.1)
- a developer gets the 2.1.1 trunk and tries to reproduce the bug, finds and 
fixes, and tests it
- bugfix is merged into the dev tree (which hopefully is not that painful)

b) bug found in dev by a developer
- chances are big that the bug was already in the old release (except it was 
created as side effect from the new code)
- classification of bug: cirtical, normal, minor
- someone has to decide if the bugfix is mereged into previous releases:
  - how complex is it?
  - which releases?
  - how complicate is it to verify the bugfix doesn't break anything?

At the end someone has to decide when a bugfix release is going out (which can 
be completly independet from a new release, i.e. snapshot of dev) based on:
+ number and classfication of fixed bugs found by process a) and b)

Well, I'm sure you know what I mean (most developers know how it theortically 
should work ;-)  )

> However, as the bug rate slows, this possibility gets smaller and
> smaller.  This is only a problem when the rate of finding and fixing new
> bugs is high.
Bugs will never go down as long new functionality goes in. And as far as I can 
see the HA project still has some nice features which will go into dev.

> If it makes anyone feel better, I will make a proposal on how we should
> proceed for releases.  I want to make the first draft sort-of
> reasonable, so it will take a few days or maybe a week or two to get out.
This would be fine. Thanks

kind regards 
max
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
[prev in list] [next in list] [prev in thread] [next in thread]