On Tue, 2014-09-02 at 11:17 -0400, Felipe Sateler wrote: > On Tue, Sep 2, 2014 at 5:20 AM, Tanu Kaskinen > <tanu.kaskinen at linux.intel.com> wrote: > > On Wed, 2014-08-27 at 18:49 -0400, Felipe Sateler wrote: > >> Hi all, > >> > >> The debian release team plans to freeze the next debian release on the > >> 5th of November[1]. So I think it is good to plan ahead to see if we > >> might be able to carry pulseaudio 6 in Jessie or will we have to stick > >> with version 5. > >> > >> There is a 6.0 release bug[2] in the tracker, but it currently is only > >> tracking 7 bugs, and I suspect the more important blockers for PA 6 > >> will be new features, which are not tracked in bugzilla. So I > >> currently have no idea if the next PA release is relatively close or > >> still very far away. If the next release is close, then we (debian) > >> may need to start preparing for it. > >> > >> So the question for debian is: When is a reasonable ballpark estimate > >> for a PA 6 release? I certainly don't expect a date to be known yet. > >> But if you expect PA to be released Real Soon Now, there may be a > >> possibility of including PA 6 in Jessie. If the release is probably > >> next year then we will have to stick with version 5. > > > > The only thing that isn't listed in the 6.0 blockers list in the > > bugzilla is the oFono patch set. My plan (which has not been agreed with > > anyone else, so it's subject to discussion) has been to get that patch > > set merged, fix the blocker bugs and then make the first release > > candidate. From the first release candidate it has usually taken at > > least a month before the final release happens. I expect the release to > > happen this year, but I'm not 100% sure about that > > I will coordinate will the debian release team if it would be > acceptable to land the rc just before the freeze, and then upload the > final release after the freeze. But for that the release team is > probably going to ask me what is the pulseaudio (upstream) policy on > patch acceptance after the rc: Only bug fixes? Bug fixes + small > improvements? Anything that looks good? > > A quick glance at the git log suggests bug fixes + translation/doc > updates, but a confirmation would be great. "Bug fixes + translation/doc updates" sounds pretty accurate. Everything else should go to a separate branch that is merged to master after the final release. -- Tanu