KFW releases off the trunk will become harder as 1.7 features start getting used

[Kevin Koch]

With regard to Danny's concerns, I want to clarify how KfW sources relate to
the trunk and branches.  

New features are added to the trunk.

When a set of features in the trunk is mostly complete, such as before an
alpha release, a release branch is created.  Changes to the release branch
are then only for bug fixes.  A draft description of the process is at
http://k5wiki.kerberos.org/wiki/Release_branches.

KfW releases are tags based on krb5 release branches.  KfW 3.* releases are
tags on the krb 5-1.6 branch.  KfW 4.* releases will be tags on the 1.7
branch.

Bug fixes are made to the trunk.  The release manager (Tom Yu) carefully
"pulls up" bug fixes from the trunk to the 1.6 (or 1.7) branch, making sure
to only include bug fixes and not new features.  So the latest and greatest
KfW code is in the trunk.

Danny's concern about multiple source trees is one of the reasons why the
code is managed as it is, in one tree.

With this explanation and with the later messages establishing that adding
new features to the trunk can be done mostly without conflicting with NIM
development, are there still concerns?

Kevin

-----Original Message-----
From: kfwdev-bounces at MIT.EDU [mailto:kfwdev-bounces at MIT.EDU] On Behalf Of
Danny Mayer
Sent: Saturday, November 17, 2007 11:24 PM
To: Sam Hartman
Cc: kfwdev at mit.edu
Subject: Re: KFW releases off the trunk will become harder as 1.7
featuresstart getting used

Sam Hartman wrote:
> 
> One long-running aspect of our release process is that the trunk is
> allowed to take advantage of features on the trunk.  In particular
> this means things like as we get new implementations of CCAPI, KIM and
> other APIs available, we'll want to start using them.  And we don't
> generally support backward compatibility for this sort of change.
> 
> One consequence of this is that we may start running into cases where
> specific changes to KFW will end up depending on the 1.7 release or
> at least the 1.7 release branch.  I'd expect to get to a point in a
> few months where any significant changes to KFW would depend on 1.7.
> 
> We've been traditionally very reluctant to pull significant features
> for future releases back to old release branches.  I'd expect Tom to
> continue that practice.  We may develop more well defined guidelines
> for when pull-ups are appropriate, but I would expect anything we came
> to consensus on to be relatively conservative in this regard.
> 
> There may be projects that we want to consider and try and avoid
> blocking behind 1.7.  I think that quite soon, we're going to want to
> establish a deadline for any such project to be proposed and for us to
> at least have the community discussion about whether we want to avoid
> blocking the projects behind 1.7.
> 
> Kevin, I'd appreciate it if you could work with Jeff and anyone else
> who has an opinion and decide on a deadline by which projects that
> want to avoid being blocked behind 1.7 must be proposed.
> 
> I think that shorter than two weeks from today would be unrealistic.
> I think that a deadline beyond Jan 15 would probably be too long.
> 
> 
> One specific concern I have is the NIM 2.0 work.  There was a project
> proposal over the summer for the user experience.  However there
> hasn't been any proposals made regarding technical impact or how the
> user experience would be accomplished.
> 
> That's fine, but until such proposals are reviewed, we as a group
> won't be in a position to avoid taking NIM 2.0 design into account and
> avoid making things harder for NIM 2.0.
> 

I'm more than a little puzzled by this. The two major applications that
I've been involved in: BIND 9 and NTP have the Windows sources
integrated with the trunk and there are no branches (except for the
usual delivery of older version bug fixes). Is it really necessary for
KfW to be different from the kerberos source tree? There is some
Windows-specific code but that's the same in BIND9 and NTP.

It becomes a major effort to maintain divergent source trees.

Danny
> 
> 
> Thanks for your consideration
> 
> --Sam
_______________________________________________
kfwdev mailing list
kfwdev at mit.edu
http://mailman.mit.edu/mailman/listinfo/kfwdev