In general, we need to make some small but hard changes to our development
process to improve overall quality of Gecko and Firefox. I don't think
there is any silver bullet and we will probably try things that aren't
universally +1'ed.
We want devs to have autonomy to do what they think is right and this means
not being too prescriptive (e.g., fix bug 123, 456, xyz. Go reduce the
number of orange tests.). However, organizationally we need to improve our
over all backlogs, fix the papercuts, reduce test failures, improve
developer productivity, build better tooling etc. We need to set aside
time to sharpen our axe.
My suggest was to take the n-th milestone was a strawman. I think in terms
of scheduling, setting aside every n-th milestone as a quality release
helps planning a bunch. When we tell customers (the web, the firefox team,
firefoxos) that feature X will be delivered by Aug, we can build in time to
sharpen our axe.
Another suggest from blassey was to make the last two weeks of the cycle
focused on the above issues. This is pretty slick as it is a forcing
function again devs crash landing features before an uplift (Not that we'd
ever do that!)
Doug
On Tue, Dec 22, 2015 at 11:58 AM Jason Duell <jdu...@mozilla.com> wrote:
> On Tue, Dec 22, 2015 at 11:38 AM,
>
> Ben Kelly <bke...@mozilla.com> wrote:
>
>>
>> I'd rather see us do:
>>
>> 1) Raise the visibility of oranges. Post the most frequent intermittents
>> without an owner to dev-platform every N days.
>> 2) Make its someone's job to find owners for top oranges. I believe
>> RyanVM
>> used to do that, but not sure if its still happening now that he has
>> changed roles.
>>
>> Ben
>>
>>
> I'm with bkelly on this one. Maybe with some additional initial messaging
> ("War on Orange raised in priority!") too. I don't think we want to pivot
> all work in platform for this.
>
> Jason
>
>
>
>>
>> >
>> > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley <mcon...@mozilla.com>
>> wrote:
>> >
>> > > I would support scheduled time[1] to do maintenance[2] and help
>> improve
>> > our
>> > > developer tooling and documentation. I'm less sure how to integrate
>> such
>> > a
>> > > thing in practice.
>> > >
>> > > [1]: A day, a week, heck maybe even a release cycle
>> > > [2]: Where maintenance is fixing oranges, closing out papercuts,
>> > > refactoring, etc.
>> > >
>> > > On 21 December 2015 at 17:35, <jmath...@mozilla.com> wrote:
>> > >
>> > > > On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta
>> > wrote:
>> > > > > So, I propose that we create an orangefactor threshold above which
>> > the
>> > > > > tree should just be closed until people start fixing intermittent
>> > > > > oranges. Thoughts?
>> > > > >
>> > > > > kats
>> > > >
>> > > > How about regularly scheduled test fix days where everyone drops
>> what
>> > > they
>> > > > are doing and spends a day fixing tests? mc could be closed to
>> > everything
>> > > > except critical work and test fixes. Managers would be able to opt
>> > > > individuals out of this as needed but generally everyone would be
>> > > expected
>> > > > to take part.
>> > > >
>> > > > Jim
>> > > > _______________________________________________
>> > > > dev-platform mailing list
>> > > > dev-platform@lists.mozilla.org
>> > > > https://lists.mozilla.org/listinfo/dev-platform
>> > > >
>> > > _______________________________________________
>> > > dev-platform mailing list
>> > > dev-platform@lists.mozilla.org
>> > > https://lists.mozilla.org/listinfo/dev-platform
>> > >
>> > _______________________________________________
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> _______________________________________________
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
