Hello, > There's more than one reason for that... > And mostly the reasons for "bursts" is not enough time > to test/compile/build everywhere.
that's the point. Since there is no time to do testing of release version, it would be better to put fix into head and force people to try out the head version to see if problem is fixed there or not. also some problems were introduced as 'code clean ups' into release version, only fixes should be allowed there in general. the maintainer of release head should be very conservative to accept a code clean up, which has ''no effect'' to living code except it makes it to look less ugly. the maintainer of release branch would have a right to refuse patch, on the other hand he would be responsible for seamless release. > That's wrong. Everyone who's part of the project on sourceforge as a > developer, including you, is able to commit to the CVS repository on > sourceforge. Currently the only other person who has is from NetBSD > (Martti.) I know. The reason I'm not commiting into project is I'm afraid of I could break something. Therefore I'm trying to set up some rules such as where bugfix should go first and so on just to minimize impact to users. > Before making such rules, you need to understand that there are exceptions. > > For example, the HISTORY file and others with the version number are updated > for every release. This requires a committed change in CVS. It is silly to > have a bugid for that. So (2) needs to be waived for release engineering. I know. Pavel has the same objection. I'm trying to focus on the code part. It's definitely good point. the anything else than code should be handled differently. Talking about the HISTORY file it should be prepared by RELASE maintainer, or even generated from CVS messages, providing each commit in code has its BugID. > > (3) every change must appear in HEAD first, no excuse. > > I disagree. Sometimes a change is only relevant to a release branch. I agree, we can think of some more exceptions i.e. bugs with security impact. We can think of exceptions once we will have some sort of framework and some roles assigned. > There are three factors that influence when I do releases at present: > 1) release cycles of BSDs we should probably ignore a release cycle of BSDs, and let those people to judge, which release version they want to get into their release. or another option is to get them involved and ask them for help with maintanance of release branch and focus on play in HEAD. > 2) the nature of bugs that have been fixed but are not in a release we can use priorities in bugtracker, let's say bug with priority lass than five won't never make it into release branch... > 3) time I know what are you talking about... > On the topic of patching and developing IPFilter, I'd like to propose that > we set up a web page, say ipfilter.sourceforge.net/changes or something > else and upload diff files converted to html that have proposed changes > to review for non-trivial fixes. how about to commit it into a HEAD? with BugID in comments, everything can be discussed in BTS, diffs can be seen in webcvs on sourceforge. in case of a real huge fix separate branch can be created. how does that sound ? regards sasha ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ipfilter-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ipfilter-devel
