[fedfs-utils] [PATCH] manpage: make rpmlint happy

[Chuck Lever]

On Sep 12, 2011, at 3:46 PM, Jeff Layton wrote:

> On Mon, 12 Sep 2011 15:38:22 -0400
> Chuck Lever <chuck.lever at oracle.com> wrote:
> 
>> 
>> On Sep 12, 2011, at 12:00 PM, Jeff Layton wrote:
>> 
>>> On Mon, 12 Sep 2011 11:47:06 -0400
>>> Chuck Lever <chuck.lever at oracle.com> wrote:
>>> 
>>>> Before I test and apply it, though, we need to figure out how to deal with updating 0.7 while developing 0.8.  I was thinking of adding a branch for 0.7.x and keeping support fixes there, then putting commits destined for 0.8 on master.  Any thoughts about this?
>>>> 
>>> 
>>> Why bother having so many development streams? I'd just apply this to
>>> the HEAD and plan to see it in 0.8.
>>> 
>>> Let's keep it simple and only add that sort of complexity if we deem it
>>> worthwhile.
>> 
>> I'm sympathetic to arguments towards simplicity.  However:
>> 
>>  o  I anticipate that once we reach 1.0 and later, distributions (especially enterprise distributions) will want upstream to maintain stable versions, alongside newer versions, for potentially a long while.  I'd like to have a running start on that, even if we don't need it immediately.
>> 
>>  o  I'm using a feature-based release system, rather than a train system, for many reasons.  But this means we have to avoid pushing entirely new releases before they are feature complete (or even well-tested) to fix pervasive bugs or security exposures.
>> 
>> 
>> We might get similar benefits by having one separate devel branch, and leave the current stable release on master.  (Assume both approaches would tag full releases to make it easy to pull them).  Would that be easier for the maintainer and distributors?
>> 
> 
> Ok, your call. My suggestion in that case would be to leave master as
> the "HEAD", and do all new development there, and just spawn new
> branches whenever you do a release. So in this case, you'd have a 0.7.0
> branch and the new patch would go to master. At some point (like when
> 0.8.0 ships or you want to branch it off for rc's) you'd create a new
> 0.8.0 branch from master. etc...
> 
> Whenever you add a new patch that's important enough, you'd backport
> it to the earlier branches too. You'll probably also want to come up
> with some sort of policy as to how long older branches will be
> maintained, unless you really like backporting ;)

Yes, that's exactly what I was proposing originally.

I don't think I would name the branches "0.7.0" but rather "0.7" and have 0.7.1, 0.7.2, and so on as tags on that branch.  Just as an example, a branch named "fedfs-utils-0.7.0" would collide with a tag named "fedfs-utils-0.7.0".

And btw 0.6.x is now retired.  That's not a general policy, it's just that no-one is using that release, I'm pretty sure.  :-)

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com