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

[Danny Mayer]

Kevin Koch wrote:
> 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
> 

My concern is that there is a need for a branch for windows. In both 
BIND and NTP there is just one code release. In each case there are 
parts that are specific to windows but they are a part of the integrated 
whole. There may be good reasons why they have to be kept separate but I 
personally am not aware of the reasons. I'm just bring it up as 
something to consider.

Danny

> -----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
> 
> _______________________________________________
> kfwdev mailing list
> kfwdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kfwdev
>