I'd like to suggest that this is now a great time to create two separate cvs branches for the rsync product. One, which I'll tentatively call 2_5, would hold the version of the code that has been released to the world as 2.5.6. The other, which I'll tentatively call head, would hold the development activity leading up to the next field release. I'm not bound to these names, but I picked ones that are parallel to the names used in the samba tree, for simplicity and ease of communication. I won't go into a long involved explanation, because I think most people understand the tradeoffs. Briefly, I see the major benefit as giving us the ability to send out important bug fixes or security fixes to users of 2.5.6 without exposing them to experimental or lightly tested development activities. I think splitting the branches will also let us be a little more experimental in the development branch, at least until we get near the next release phase, because we'll always have the field release in which to make crucial bug fixes available quickly. It is a little more work for the maintainers, but I think the benefits far outweigh the costs. We can minimize the extra work by minimizing the changes to the released version. And if we can get agreement to do it, now is the best time, when there has just been a release. Comments? Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
On 28 Jan 2003, "Green, Paul" <Paul.Green@stratus.com> wrote:> I think splitting the branches will also let us be a little more > experimental in the development branch, at least until we get near > the next release phase, because we'll always have the field release > in which to make crucial bug fixes available quickly.I agree that this would be a good approach if and only if there is energy to do lots of development in the head branch. What do you have in mind? -- Martin
Martin Pool [mailto:mbp@samba.org] wrote:> On 28 Jan 2003, "Green, Paul" <Paul.Green@stratus.com> wrote: > > > I think splitting the branches will also let us be a little more > > experimental in the development branch, at least until we get near > > the next release phase, because we'll always have the field release > > in which to make crucial bug fixes available quickly. > > I agree that this would be a good approach if and only if there is > energy to do lots of development in the head branch. What do you have > in mind?(I've seen the replies from JW, Wayne, Craig, and Donovan, and just in those letters I see enough development activity to suggest to me that splitting is a good thing...) I'm working on a fix that will solve the "temp file name is 10 characters longer than the original file name" problem. The trick is coding this in a way that is POSIX-compliant and able to deal with simultaneous use of multiple file systems that might have different max lengths. PG
jw schultz [mailto:jw@pegasys.ws] wrote:> On Wed, Jan 29, 2003 at 03:24:57PM +1100, Martin Pool wrote: > > On 28 Jan 2003, "Green, Paul" <Paul.Green@stratus.com> wrote: > > > > > I think splitting the branches will also let us be a little more > > > experimental in the development branch, at least until we get near > > > the next release phase, because we'll always have the field release > > > in which to make crucial bug fixes available quickly. > > > > I agree that this would be a good approach if and only if there is > > energy to do lots of development in the head branch. What > > do you have in mind? > > And if such development rendered the code sufficiently > unstable that we couldn't safely release a new version for > security patches, if needed.Hold on a minute. One of the major points in favor of splitting the tree is so that we will have a stable version in which we can apply security patches. Do you disagree, or am I completely misunderstanding you here? Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus
jw schultz [mailto:jw@pegasys.ws] wrote: [general discussion of forthcoming patches removed]> All well and good. But the question before this thread is > are the changes big and disruptive enough to make a second > branch for the event of a security or other critical bug.Agreed.> Personally i doubt that such a bug is that likely to emerge > and that if it does we can always create a branch off of > the 2.5.6 tag at that time.Quite true. But I'd like to make the point that I think it is worth making the decision to split now. Having two branches will change attitudes. And I think with as large a community of users as rsync clearly has, it is worth changing attitudes. Having a production branch will remind us that we have a place to put stability or security fixes, and will make it easy to do so. Perhaps too easy; time will tell. I'm concerned that if we wait until we clearly need a production branch, we'll probably have already forgotten to apply some fixes that should have also gone in, and then we'll be busy trying to grab them out of the cvs repository. I think if you look at this from a developer or maintainers point of view, having an extra branch is a pain. A minor pain to be sure, but still a pain. But if you look at it from a user's point of view, it is a very good thing...> Related to this is that we should make an effort to > incorporate just one of these larger changes at a time > please. If we have to increment the protocol version > number by two or three going from 2.5.6 to 2.5.7 that is OK > by me.Agreed. Tho once we start fixing bugs in the new features things will get confusing again.> I am inclined to prioritize the checksum fixes. They are > central to rsync and i'd like them to get a maximum of > testing as early in the new cycle as possible. This is the > one scaling deficiency we have a decent chance of fixing.Agreed, except ... do we have any control over the order in which our volunteers submit their changes? Doubtful... Thanks PG
Madole, Dave BGI SF
2003-Jan-30 12:44 UTC
Proposal that we now create two branches - 2_5 and head
I agree with this. I am in a situation where I don't install rsync myself, I have to depend on sysadmins to do it. They get very nervous and insist on installing it as something like "rsync2_5_5" because they are afraid some other users "legacy" rsync invocation is going to break; you can't blame them for their circumspection. They'll gladly install bug fixes, of course, but I can't say every few months "hey could you install the new rsync" because there's a critical bug fix tied in with a bunch of features any current user is unlikely to use. I'm sure just getting them up to 2.5.6 from 5.5 will be a bit of a pain. If I really NEED a new feature, but frankly between perl and the three hundred or so options that rsync now supports that seems unlikely, then I can petition them to do the upgrade; otherwise, why should they? Dave> -----Original Message----- > From: Green, Paul [mailto:Paul.Green@stratus.com] > Sent: Tuesday, January 28, 2003 8:14 PM > To: Rsync Mailing List (E-mail) > Subject: Proposal that we now create two branches - 2_5 and head > > > I'd like to suggest that this is now a great time to create > two separate cvs > branches for the rsync product. One, which I'll tentatively > call 2_5, would > hold the version of the code that has been released to the > world as 2.5.6. > The other, which I'll tentatively call head, would hold the > development > activity leading up to the next field release. I'm not bound > to these names, > but I picked ones that are parallel to the names used in the > samba tree, for > simplicity and ease of communication. > > I won't go into a long involved explanation, because I think > most people > understand the tradeoffs. Briefly, I see the major benefit > as giving us the > ability to send out important bug fixes or security fixes to > users of 2.5.6 > without exposing them to experimental or lightly tested development > activities. I think splitting the branches will also let us > be a little more > experimental in the development branch, at least until we get > near the next > release phase, because we'll always have the field release in > which to make > crucial bug fixes available quickly. > > It is a little more work for the maintainers, but I think the > benefits far > outweigh the costs. We can minimize the extra work by > minimizing the changes > to the released version. And if we can get agreement to do > it, now is the > best time, when there has just been a release. > > Comments? > > Thanks > PG > -- > Paul Green, Senior Technical Consultant, Stratus Computer, Inc. > Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. > > > -- > To unsubscribe or change options: > http://lists.samba.org/mailman/listinfo/rsync > Before posting, read: > http://www.tuxedo.org/~esr/faqs/smart-questions.html >