On Thu, Jan 27, 2011 at 2:15 PM, Hugo Parente Lima <[email protected]> wrote: > On Thursday 27 January 2011 12:42:18 Renato Araujo Oliveira Filho wrote: >> On Thu, Jan 27, 2011 at 11:03 AM, Matti Airas <[email protected]> > wrote: >> > Hi list, >> > >> > Now that we've been in the beta period for quite some time, we've managed >> > to get the Bugzilla backlog in control, and it'd seem that the number of >> > new bug reports is slowly decreasing, I think we should be quite close >> > to the 1.0 release already, but I'd like to hear more opinions about >> > this one (also from the core dev team guys, since we haven't discussed >> > this internally recently). >> > >> > What do you think? Is PySide getting stable enough for the 1.0 label? If >> > not, what's still missing? I don't think we can realistically aim for a >> > perfect 1.0 release, but it should at least be good enough that any >> > developers attracted by the "1.0 promise" shouldn't have their fingers >> > burned by a premature release. >> >> In my opinion we can wait for more 2 betas (beta5, beta6) then if any >> critical bug appear, >> we can consider stable to a rc and then the 1.0. > > In my opinion after beta5 we could wait and see if any crash bug appear, if > not is because we are ready to a RC then a final release. > > At the moment we have just two P2 bugs registered on our bugzilla and both are > bugs about compilation errors probably caused by some missconfigured > environment, the P3 bugs (we have 17) are normal bugs that can be fixed during > the 1.0 lifetime and P4 bugs are just enhancements that would be nice to have. > so IMO the numbers says that we are pretty stable for a beta release and is > time to go forward. > >> > When would be the right time to make the release? We'll still have beta5 >> > late next week, but two weeks after that, would we be already all set for >> > a release candidate? IMO, the release candidate should be really a >> > candidate for the final release - we make changes between the rc and >> > final only if there are uncaught regressions in the rc. > > Only critical bugs should be fixed between the RC and the final release, any > other bugs should go to another branch for the 1.0.1 or 1.1.0 release to avoid > regressions at the maximum. > >> > How about the release cadence after 1.0? I hope that by doing the release >> > candidates, we can avoid any brown paperbag followup releases, and we >> > could cool down a bit. The two-week release cadence I've insisted upon >> > has been taxing for both the core dev team (especially for the guys >> > doing integration to Fremantle, Harmattan, and MeeGo), but also for our >> > valued community packagers. I still like the predictability of the >> > time-based release cycle, but maybe monthly releases would be sufficient >> > at first? >> >> If the 1.0 was stable enough we can extend the developer time between >> the releases >> and I think a release every 2 or 3 months will be nice. > > 2 or 3 months is a huge time gap IMO, we aren't a distro! :-P, I think one > release per month is a good cadence for packagers, devels and people that > report a bug and want to see the fix packaged. >
In my opinion one release at each 2 sprints is a great overhead, mainly if you are working on bug fixes and new features, because this release will be only the bug fixes, and some new features if they does not break the API (In my opinion the most of the new features will break the API/ABI). >> Other pointer to consider is how will proceed with the developer process, >> if we will keep working on bug fix, or we can think out the box and >> start implement really new >> things like my dream of implement some introspection like "PyGObject". > > Matti, I think the 1.0 lifetime will be long enough, anyway we need to keep on > bug fixing, probably the bug reports will slow down a bit giving us more time > to think about improvements to PySide, so I think we can keep fixing bugs and > creating experimental parallel projects/branches like the Renato idea of doing > a more introspective binding, work on reduce the bindings memory footprint and > size, work on the so requested QtCreator integration, etc. > >> If implement new things is allowed we will need work in 2 branchs, >> because we need keep 1.x with bug fix, >> and the new 2.x, and this demand some extra effort. > > Before thinking in a 2.x release we need to think what improvements we want > and work on them. If it's possible to put them on 1.0 good, otherwise start > the preparation for the development of a 2.0 release, anyway IMO a 2.0 release > should wait at least one year after the 1.0. I do not have hope to have a vesrion 2.0 before at least one year, but like I told every API/ABI break will be moved to the 2.x branch, then wee need keep working on 2 branch. My introspection is a example of API/ABI break, if I work on that this only will be available on version 2.x. > >> >> Ok this is all > > -- > Hugo Parente Lima > INdT - Instituto Nokia de Tecnologia > -- Renato Araujo Oliveira Filho Instituto Nokia de Tecnologia - INdT Mobile: +55 (81) 8704-2144 _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
