Bugzilla branch lifecycle proposal

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bugzilla branch lifecycle proposal

Dave Miller
The following proposal was on the agenda for our Project meeting
yesterday, but because it was the only thing on the agenda, and we felt
it warranted a larger audience than those in attendance at the meeting,
we opted to call off the meeting and post it here.

----------------
Proposal (from LpSolit) : Reduce the number of supported branches.
Instead of waiting for {N+3}.0 to be released before N.x reaches EOL, I
propose N.x reaches EOL 4 months after the release of {N+2}.0. Concrete
example: instead of waiting for 6.0 to be released before 4.2 reaches
EOL, I propose 4.2 reaches EOL 4 months after the release of 5.0
(probably means around 5.0.2). Two major reasons for that: 1) when we
are closer from the next major release, having to think about very old
branches is a pain (think about security backports, QA, maintain old
repo alive, release stuff), and 2) data shows that installations still
running old versions of Bugzilla generally do not care about upgrading
(e.g. install 4.0.1 and that's it; never upgrade to 4.0.17, so why
should we bother that long?).
----------------

Since LpSolit hasn't posted it here himself yet I figured I'd get it out
there.  Discuss.

--
Dave Miller http://www.justdave.net/
IT Infrastructure Engineer, Mozilla http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla branch lifecycle proposal

Dave Miller
For the record, I like this plan.  Our release cycles tend to take long
enough these days that it's a Really Long Time™ before a release gets EOLed.

Dave Miller wrote:

> The following proposal was on the agenda for our Project meeting
> yesterday, but because it was the only thing on the agenda, and we felt
> it warranted a larger audience than those in attendance at the meeting,
> we opted to call off the meeting and post it here.
>
> ----------------
> Proposal (from LpSolit) : Reduce the number of supported branches.
> Instead of waiting for {N+3}.0 to be released before N.x reaches EOL, I
> propose N.x reaches EOL 4 months after the release of {N+2}.0. Concrete
> example: instead of waiting for 6.0 to be released before 4.2 reaches
> EOL, I propose 4.2 reaches EOL 4 months after the release of 5.0
> (probably means around 5.0.2). Two major reasons for that: 1) when we
> are closer from the next major release, having to think about very old
> branches is a pain (think about security backports, QA, maintain old
> repo alive, release stuff), and 2) data shows that installations still
> running old versions of Bugzilla generally do not care about upgrading
> (e.g. install 4.0.1 and that's it; never upgrade to 4.0.17, so why
> should we bother that long?).
> ----------------
>
> Since LpSolit hasn't posted it here himself yet I figured I'd get it out
> there.  Discuss.
>

--
Dave Miller http://www.justdave.net/
IT Infrastructure Engineer, Mozilla http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla branch lifecycle proposal

Vlad Dascalu-2
Looks good to me.

I'd encourage thoughts on how to be on par with Firefox, Chrome and Cpanel-like products in terms of self-updates. To get there longterm we need to discuss the strategy now.

On Thursday, April 23, 2015, Dave Miller <[hidden email]> wrote:
For the record, I like this plan.  Our release cycles tend to take long
enough these days that it's a Really Long Time™ before a release gets EOLed.

Dave Miller wrote:
> The following proposal was on the agenda for our Project meeting
> yesterday, but because it was the only thing on the agenda, and we felt
> it warranted a larger audience than those in attendance at the meeting,
> we opted to call off the meeting and post it here.
>
> ----------------
> Proposal (from LpSolit) : Reduce the number of supported branches.
> Instead of waiting for {N+3}.0 to be released before N.x reaches EOL, I
> propose N.x reaches EOL 4 months after the release of {N+2}.0. Concrete
> example: instead of waiting for 6.0 to be released before 4.2 reaches
> EOL, I propose 4.2 reaches EOL 4 months after the release of 5.0
> (probably means around 5.0.2). Two major reasons for that: 1) when we
> are closer from the next major release, having to think about very old
> branches is a pain (think about security backports, QA, maintain old
> repo alive, release stuff), and 2) data shows that installations still
> running old versions of Bugzilla generally do not care about upgrading
> (e.g. install 4.0.1 and that's it; never upgrade to 4.0.17, so why
> should we bother that long?).
> ----------------
>
> Since LpSolit hasn't posted it here himself yet I figured I'd get it out
> there.  Discuss.
>

--
Dave Miller http://www.justdave.net/
IT Infrastructure Engineer, Mozilla http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@...>
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla branch lifecycle proposal

Gervase Markham
In reply to this post by Dave Miller
On 23/04/15 06:20, Dave Miller wrote:
> Since LpSolit hasn't posted it here himself yet I figured I'd get it out
> there.  Discuss.

I'm in support of this.

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla branch lifecycle proposal

Dave Lawrence
In reply to this post by Dave Miller
I also support this. Although I think it might be better to extend to 4 months instead of 6 given how long our release cycles have been historically.

dkl

On Thu, Apr 23, 2015 at 1:20 AM, Dave Miller <[hidden email]> wrote:
The following proposal was on the agenda for our Project meeting
yesterday, but because it was the only thing on the agenda, and we felt
it warranted a larger audience than those in attendance at the meeting,
we opted to call off the meeting and post it here.

----------------
Proposal (from LpSolit) : Reduce the number of supported branches.
Instead of waiting for {N+3}.0 to be released before N.x reaches EOL, I
propose N.x reaches EOL 4 months after the release of {N+2}.0. Concrete
example: instead of waiting for 6.0 to be released before 4.2 reaches
EOL, I propose 4.2 reaches EOL 4 months after the release of 5.0
(probably means around 5.0.2). Two major reasons for that: 1) when we
are closer from the next major release, having to think about very old
branches is a pain (think about security backports, QA, maintain old
repo alive, release stuff), and 2) data shows that installations still
running old versions of Bugzilla generally do not care about upgrading
(e.g. install 4.0.1 and that's it; never upgrade to 4.0.17, so why
should we bother that long?).
----------------

Since LpSolit hasn't posted it here himself yet I figured I'd get it out
there.  Discuss.

--
Dave Miller http://www.justdave.net/
IT Infrastructure Engineer, Mozilla http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dkl@...>



--
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla branch lifecycle proposal

Cédric Corazza
In reply to this post by Dave Miller
> Since LpSolit hasn't posted it here himself yet I figured I'd get it out
> there.  Discuss.

As a localizer, I do agree too: from 4 to 5 branches to maintain (with trunk) is really painful.

Cédric
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>