Release management, and stepping it up to 3

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

Release management, and stepping it up to 3

Bertrand Lorentz
Administrator
Hi everyone,

As you probably have noticed, we didn't have a release schedule for
the last 6 months and we didn't have any release since 2.6.0, back in
October. I'm to blame for that, and I'm sorry I haven't communicated
earlier about this.

Normally, now would be the time to put out a 2.8. But I don't think
there's enough enhancements in git master to justify a major release.
One of the reasons is that we have several big transitions ahead of us
(GTK# 3, GStreamer 1.0), and we've been laying the ground work for
those.

With this in mind, I'm proposing the following:
1/ Review all the fixes currently in git master, merge them in the
stable-2.6 branch as appropriate [1], and do a Banshee 2.6.1 bug-fix
release.
2/ Skip version 2.8.
3/ Banshee 3.0 will use GTK# 3 (thus depending on GTK+ 3.x and friends).
4/ Banshee 3.0 should use GStreamer 1.0, through our GStreamerSharp
backend. If not, this will be the objective for 3.2.
5/ Banshee 3.0 will be released "when it's ready", and should reach
for the same level of quality and stability than our previous stable
releases. It will of course be preceded by several development
releases and release candidates.

This means that we will abandon our time-based release schedule, at
least until the 3.0 stable release is out.

One of the reasons why the gtk3 branch hasn't been merged into git
master is that I was never sure we could get to a good-enough quality
before the next scheduled release. Not setting an arbitrary date for
Banshee 3.0 will allow us to work more serenely towards a high quality
release.

More than ever, we will need everybody's help to reach those goals:
coding, reviewing, building, testing, documenting, on Linux, OS X and
Windows.

So, what do you think ?

[1] https://live.gnome.org/Banshee/StableReleasesPolicy

--
Bertrand
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

Gabriel Burt
Sounds good to me!

On Sun, Mar 24, 2013 at 10:25 AM, Bertrand Lorentz <[hidden email]> wrote:
Hi everyone,

As you probably have noticed, we didn't have a release schedule for
the last 6 months and we didn't have any release since 2.6.0, back in
October. I'm to blame for that, and I'm sorry I haven't communicated
earlier about this.

Normally, now would be the time to put out a 2.8. But I don't think
there's enough enhancements in git master to justify a major release.
One of the reasons is that we have several big transitions ahead of us
(GTK# 3, GStreamer 1.0), and we've been laying the ground work for
those.

With this in mind, I'm proposing the following:
1/ Review all the fixes currently in git master, merge them in the
stable-2.6 branch as appropriate [1], and do a Banshee 2.6.1 bug-fix
release.
2/ Skip version 2.8.
3/ Banshee 3.0 will use GTK# 3 (thus depending on GTK+ 3.x and friends).
4/ Banshee 3.0 should use GStreamer 1.0, through our GStreamerSharp
backend. If not, this will be the objective for 3.2.
5/ Banshee 3.0 will be released "when it's ready", and should reach
for the same level of quality and stability than our previous stable
releases. It will of course be preceded by several development
releases and release candidates.

This means that we will abandon our time-based release schedule, at
least until the 3.0 stable release is out.

One of the reasons why the gtk3 branch hasn't been merged into git
master is that I was never sure we could get to a good-enough quality
before the next scheduled release. Not setting an arbitrary date for
Banshee 3.0 will allow us to work more serenely towards a high quality
release.

More than ever, we will need everybody's help to reach those goals:
coding, reviewing, building, testing, documenting, on Linux, OS X and
Windows.

So, what do you think ?

[1] https://live.gnome.org/Banshee/StableReleasesPolicy

--
Bertrand
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)


_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

Alexander Kojevnikov-2
On Sun, Mar 24, 2013 at 8:42 AM, Gabriel Burt <[hidden email]> wrote:
> Sounds good to me!

Seconded!
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

IBBoard
On 24/03/13 19:14, Alexander Kojevnikov wrote:
> On Sun, Mar 24, 2013 at 8:42 AM, Gabriel Burt <[hidden email]> wrote:
>> Sounds good to me!
>
> Seconded!
> _______________________________________________
> banshee-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
>

Banshee doesn't have any glaring omissions at the moment, so as long as
Banshee 3 doesn't take after Gnome 3 too much by removing really useful
options, setting bizarre defaults or making things unnecessarily
annoying* then I think a "wait until it is ready" for a GTK3 version is
the best idea!


  * moving the whole desktop up an inch to view the message tray? Really?
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

Bertrand Lorentz
Administrator
On Sun, Mar 24, 2013 at 8:45 PM, IBBoard <[hidden email]> wrote:
>
> Banshee doesn't have any glaring omissions at the moment, so as long as
> Banshee 3 doesn't take after Gnome 3 too much by removing really useful
> options, setting bizarre defaults or making things unnecessarily annoying*
> then I think a "wait until it is ready" for a GTK3 version is the best idea!

Don't worry, what we've removed until now in the gtk3 branch is just
some old and crufty code. The features should all still be there, but
they might need some fixing... Hence the "there's work to be done" :)

--
Bertrand
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

olivier dufour
Hi,

I found that fantastic!
I have ever work on gtk# binding previously and this news give me some motivation to help on that part...

cheers,

Olivier Dufour


On Sun, Mar 24, 2013 at 10:49 PM, Bertrand Lorentz <[hidden email]> wrote:
On Sun, Mar 24, 2013 at 8:45 PM, IBBoard <[hidden email]> wrote:
>
> Banshee doesn't have any glaring omissions at the moment, so as long as
> Banshee 3 doesn't take after Gnome 3 too much by removing really useful
> options, setting bizarre defaults or making things unnecessarily annoying*
> then I think a "wait until it is ready" for a GTK3 version is the best idea!

Don't worry, what we've removed until now in the gtk3 branch is just
some old and crufty code. The features should all still be there, but
they might need some fixing... Hence the "there's work to be done" :)

--
Bertrand
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)


_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

"Andrés G. Aragoneses"
In reply to this post by Bertrand Lorentz
On 24/03/13 15:25, Bertrand Lorentz wrote:

> Hi everyone,
>
> As you probably have noticed, we didn't have a release schedule for
> the last 6 months and we didn't have any release since 2.6.0, back in
> October. I'm to blame for that, and I'm sorry I haven't communicated
> earlier about this.
>
> Normally, now would be the time to put out a 2.8. But I don't think
> there's enough enhancements in git master to justify a major release.
> One of the reasons is that we have several big transitions ahead of us
> (GTK# 3, GStreamer 1.0), and we've been laying the ground work for
> those.
>
> With this in mind, I'm proposing the following:
> 1/ Review all the fixes currently in git master, merge them in the
> stable-2.6 branch as appropriate [1], and do a Banshee 2.6.1 bug-fix
> release.
> 2/ Skip version 2.8.
> 3/ Banshee 3.0 will use GTK# 3 (thus depending on GTK+ 3.x and friends).
> 4/ Banshee 3.0 should use GStreamer 1.0, through our GStreamerSharp
> backend. If not, this will be the objective for 3.2.
> 5/ Banshee 3.0 will be released "when it's ready", and should reach
> for the same level of quality and stability than our previous stable
> releases. It will of course be preceded by several development
> releases and release candidates.
>
> This means that we will abandon our time-based release schedule, at
> least until the 3.0 stable release is out.
>
> One of the reasons why the gtk3 branch hasn't been merged into git
> master is that I was never sure we could get to a good-enough quality
> before the next scheduled release. Not setting an arbitrary date for
> Banshee 3.0 will allow us to work more serenely towards a high quality
> release.
>
> More than ever, we will need everybody's help to reach those goals:
> coding, reviewing, building, testing, documenting, on Linux, OS X and
> Windows.
>
> So, what do you think ?

Sounds good, I was actually thinking something similar lately.

Before merging gtk3 into master, we could also create a "gtk2" branch
(and label it as 2.8 but without releasing it?), just in case we want to
have a reference to the last working gtk2/gconf-compatible infrastructure?

BTW, regarding 2.6.1, I would like to get on it a fix for a crasher that
happens when using Ubuntu 13.04 beta. The proper fix should maybe really
be in gtk-sharp, but the workaround in Banshee is trivial and I guess
it's much easier to convince the Ubuntu community to include an updated
stable banshee than to rush a gtk-sharp 2.12.x release (which may
contain very little) in 13.04 final. So by saying this I'm suggesting to
not release too late and not release too early either (wait for this
fix!), I'll share more details at the end of the week.

Thanks



_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

Bertrand Lorentz
Administrator
On Wed, Mar 27, 2013 at 4:10 PM, Andres G. Aragoneses <[hidden email]> wrote:
[snip]
> Before merging gtk3 into master, we could also create a "gtk2" branch (and
> label it as 2.8 but without releasing it?), just in case we want to have a
> reference to the last working gtk2/gconf-compatible infrastructure?

Sure, good idea. We'll create a tag right before the merge, and then
we can always go back a create a branch from that point if necessary.

> BTW, regarding 2.6.1, I would like to get on it a fix for a crasher that
> happens when using Ubuntu 13.04 beta. The proper fix should maybe really be
> in gtk-sharp, but the workaround in Banshee is trivial and I guess it's much
> easier to convince the Ubuntu community to include an updated stable banshee
> than to rush a gtk-sharp 2.12.x release (which may contain very little) in
> 13.04 final. So by saying this I'm suggesting to not release too late and
> not release too early either (wait for this fix!), I'll share more details
> at the end of the week.

Sure, I'll wait to hear from you before going ahead with 2.6.1. I
don't think it's going to happen before next week anyway.

--
Bertrand
_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

2.6.1 (was: Re: Release management, and stepping it up to 3)

"Andrés G. Aragoneses"
On 28/03/13 11:20, Bertrand Lorentz wrote:

>> BTW, regarding 2.6.1, I would like to get on it a fix for a crasher that
>> happens when using Ubuntu 13.04 beta. The proper fix should maybe really be
>> in gtk-sharp, but the workaround in Banshee is trivial and I guess it's much
>> easier to convince the Ubuntu community to include an updated stable banshee
>> than to rush a gtk-sharp 2.12.x release (which may contain very little) in
>> 13.04 final. So by saying this I'm suggesting to not release too late and
>> not release too early either (wait for this fix!), I'll share more details
>> at the end of the week.
>
> Sure, I'll wait to hear from you before going ahead with 2.6.1. I
> don't think it's going to happen before next week anyway.

Bertrand, given that you seemed to want more time to review the patch, I
left it in the bug:

https://bugzilla.gnome.org/show_bug.cgi?id=696111

Now, take in account that today I convinced Ryan to give us more time to
fix the problem in the binding, and he committed [1] a workaround in
glib master and the 2.36 branch, which will become 2.36.1 and is what
Ubuntu final will use, he told me. You could still apply the
workaround-patch anyway, just in case.

This problem is even more severe in the case of gtk3 branch, because it
affects more GInterface usage than in the master branch. Fortunately, I
think I've just found also a fix for upstream gtk-sharp, so I proposed a
pull-request:

https://github.com/mono/gtk-sharp/pull/60

Easiest way to test it is run the samples/treemodeldemo.exe in gtk-sharp.

We could do another 2.99.x release of gtk# to get more testing. If we're
happy with it after some time, I guess it would be desirable then to
backport the fix too to the 2.12 branch.

Cheers

[1]
https://git.gnome.org/browse/glib/commit/?h=glib-2-36&id=cf1285a4a473ec0f9b51b298b4ea9c4717cb1243

PS: Don't forget the other workaround for the gconf threading bug (patch
from kalev).

_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
Reply | Threaded
Open this post in threaded view
|

Re: Release management, and stepping it up to 3

David Nielsen
In reply to this post by Bertrand Lorentz
On a related note, I am setting up this years edition of the .NET + GNOME hackfest specifically with the aim of getting all our GNOME .NET applications ported to the GNOME3 platform. So far the response looks overwhelmingly positive and I'd like to invite people to examine their schedules for possible attendance.

This year will be in Vienna which should be a delight for our European developers and being set in early October should allow both the bindings generator and the GTK#3 bindings to mature to the point where we can see massive progress across the board.

A wiki page for the event can be found here:


Hopefully this will help push Banshee all the way to 3.0 while providing good times for all.

Hugs, 
The friendly marketing douche

-- 
David Nielsen
Sent with Sparrow

On Thursday den 28. March 2013 at 08.20, Bertrand Lorentz wrote:

On Wed, Mar 27, 2013 at 4:10 PM, Andres G. Aragoneses <[hidden email]> wrote:
[snip]
Before merging gtk3 into master, we could also create a "gtk2" branch (and
label it as 2.8 but without releasing it?), just in case we want to have a
reference to the last working gtk2/gconf-compatible infrastructure?

Sure, good idea. We'll create a tag right before the merge, and then
we can always go back a create a branch from that point if necessary.

BTW, regarding 2.6.1, I would like to get on it a fix for a crasher that
happens when using Ubuntu 13.04 beta. The proper fix should maybe really be
in gtk-sharp, but the workaround in Banshee is trivial and I guess it's much
easier to convince the Ubuntu community to include an updated stable banshee
than to rush a gtk-sharp 2.12.x release (which may contain very little) in
13.04 final. So by saying this I'm suggesting to not release too late and
not release too early either (wait for this fix!), I'll share more details
at the end of the week.

Sure, I'll wait to hear from you before going ahead with 2.6.1. I
don't think it's going to happen before next week anyway.

--
Bertrand
_______________________________________________
banshee-list mailing list


_______________________________________________
banshee-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)