'Re: HEAD open for commits'

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

List:       kde-devel
Subject:    Re: HEAD open for commits
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-11-29 8:35:21
[Download RAW message or body]

this depends on whether one is working on new features or bug fixes. some will 
work on new features no matter what while others will work on bug fixes no 
matter what. bug fixes find their way into the stable version, which is why 
we have already had 5 revision releases in the 3.0.x tree. true, there are 
some bugs that are fixed in 3.1 that aren't in 3.0, but that's only sometimes 
because no one cared to backport the fixes. often it's because the fix 
required changes in translatable strings or the UI or required lots of 
refactoring that isn't safe to put into a stable tree. 

those aren't, of course, excuses. just reasons.

and if you look at the number of bug fixes in each of the 3.0.x revision 
releases, i think you will see that a lot of bug fixing and backporting does 
occur in the stable branches. sometimes to the point of introducing new bugs 
=)

> problem.  The current release should be the more important and work on a
> future release should be the less important.

i agree to a large extent, but i also realize that we don't have the 
right/ability to tell people who are voluntary contributors: "you are to only 
work on bug fixes". 

> One model I have seen is simply not to branch the current release for a
> certain period of time with new features being worked on separately to
> be  integrated into the current HEAD at the end of this post release
> development pause.  What I see as the most advantageous part of this is
> the bugs do NOT need to be fixed twice -- that the new features are
> added to the release after a period of bug fixing.

this is largely what happens anyways, just in reverse.

> I would like to see this method made somewhat permanent.  That the
> current release remains HEAD until it is decided that the final minor
> release has been made and only then is it branched off.  Until that time

when would it be decided that the final revison release was made?
and would this really speed up bug fixing in the stable branch, or would 
feature development continue as always in branches instead of HEAD?

i can see (and agree with) the wisdom of holding off branching HEAD and 
opening it for 3.2 features until 3.1.1 is out (6 weeks is the usual time for 
such a thing?) so that the usual slew of bugs reported early on in the life 
cycle of a new stable branch get more attention. holding it any longer than 
that would likely only produce diminishing returns at the expense of active 
development, IMO.

> Whether it is with commercial software or open source software, users do
> not like to hear that the bug has been fixed (or will be fixed) in the
> next major release.  They should not hear that.  Major releases are for
> new features NOT for bug fixes.

no, minor releases are for both bug fixes and feature enhancements. revision  
releases are bug fixes, not features.

(release numbers are major.minor.revision)

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE95ybJ1rcusafx20MRAuBmAKCM7RrbfetjXUYJ/NRp6L9LRwv3PgCfV1av
KKrVKbSRwHpU+GKvnQV7xtU=
=F6Br
-----END PGP SIGNATURE-----

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread] 