Re: how many stable branches to have

[Francois-Xavier Le Bail <devel.fx.lebail () orange fr>]

[Sorry for the late response, the message was in the spam box]

On 08/06/2015 11:32, Denis Ovsienko wrote:
> ---- On Wed, 03 Jun 2015 19:12:03 +0100 Francois-Xavier Le Bail<devel.fx.lebail () orange fr> wrote ----
>   > On 26/05/2015 15:33, Michal Sekletar wrote:
>   > > On 05/26/2015 11:46 AM, Francois-Xavier Le Bail wrote:
>   > >> I propose this:
>   > >> We could give an "End of Life" date for each release branches.
>   > >> This mean that after this date, the tcpdump group would not update any
>   > >> more the branch.
>   > >
>   > > Having clearly defined EoL is a good idea. However I think that some
>   > > releases should be picked and supported for longer periods of time.
>   >
>   > In the previous examples, I had given EoL dates allowing to have a
>   > lifetime of support about two years.
>   >
>   > If it is not enough, a version, every two years approximately, could
>   > have a superior lifetime, by example four years.
>   > The first one of theses long-term versions could be the 1.7/4.7 ones.
>   >
>   > What do you think about it?
>
> To keep it working long-term it would help not to promise more commitment upfront than necessary. The terms above are 
> more or less OK for a Linux distribution that has many users with many slow migration processes on one hand and the 
> money/resources those users give back on the other. In such a situation it makes sense to engage, for instance, 20-50 
> engineers per each stable branch and let the show run.
>
> In the scope of tcpdump/libpcap it would be fair to spell a community contract of sorts that would state a baseline 
> level like this:
>
> 1. The latest stable branch is always supported.
> 2. From time to time the developers find it right to start the next stable branch, which supersedes the old one after, 
> for instance, 2 months or 2 releases.
> 3. Anybody who demands free support for an unsupported old stable branch (often to resell it for a price as "their" 
> support, let me note) is welcome to spend their own time on the problem and to contribute the solution.
>
> This would be within the typical expectations from an Open Source software project and the developers would still be 
> free to walk an extra mile when/if they want.

The requirements and the resources for an OS kernel and for our tools 
are indeed not the same.

I agree, your proposal is more realistic than mine.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers