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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Danny Mayer > Sent: Saturday, November 17, 2007 11:24 PM > To: Sam Hartman > Cc: [email protected] > 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 > [email protected] > http://mailman.mit.edu/mailman/listinfo/kfwdev > > _______________________________________________ > kfwdev mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/kfwdev > _______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
