On Thu, Mar 28, 2013 at 03:37:15PM +0000, Abhinandan Prateek wrote: > > > On 28/03/13 7:59 PM, "Chip Childers" <[email protected]> wrote: > > >On Thu, Mar 28, 2013 at 02:19:06PM +0000, Abhinandan Prateek wrote: > >> On 28-Mar-2013, at 7:20 PM, "Chip Childers" <[email protected]> > >>wrote: > >> > >> > On Thu, Mar 28, 2013 at 01:44:30PM +0000, Abhinandan Prateek wrote: > >> >> I think both the branches are important, yes 4.1 is close to release > >>and > >> >> people assigned issues should give priority to 4.1. > >> >> There are also many people trying to test there features in master > >>and > >> >> unstable master is resulting in wasted cycles. > >> >> > >> >> Having said that I guess people having issues assigned in both the > >> >> branches should focus on 4.1 issues first before moving to 4.2 bugs. > >> > > >> > Yes, and it seems to me that discussions around prioritization of bugs > >> > in master should be threaded by *feature* primarily (excepting general > >> > blockers that *break* the build/tests). > >> > > >> Sure, will prioritise the master bugs only if they block some feature > >>development or in general break the build/test. > > > >Sorry, I think you may be missing the point I'm trying to make. I'm > >suggesting > >that communication around features is probably best done with the feature > >itself > >being the subject of the thread. If someone is building feature X, and > >someone else has volunteered to test feature X, then they should be > >coordinating with each other on feature X. > > > >The reason that a release cycle changes this communication to "release > >level" focus, is that there is a specific schedule that we're trying to > >work towards as a community. > > > >Does that distinction make sense? > > Yes, I understand that we are trying to get the current releases out and > the focus should not be diluted. > > For any follow up on current features or bugs the communication should be > around features and not around the release as it is still not there in the > release cycle. > > My intention is to help out people who cannot test the feature due to > existing issues on master if any.
Good intention! > Again I will be taking it slow on master (only focusing on issues that > matter at this point in release cycle) so that appropriate focus is there > on current releases. > > Does this sound good or I am still missing something. > It does. Thanks for hearing me out.
