+1 Michal echoes my thoughts
On Wed, Sep 4, 2013 at 1:31 AM, Michal Mocny mmo...@chromium.org wrote:
Volunteer maps well to hows its been done implicitly. If you cannot take a
given week, find a sensible replacement.
Rotation among willing folks makes some sense in terms of passing down of
I brought up this idea before (http://markmail.org/thread/75fv4ru7rd4vwrrb),
it was well received I think, but never made its way to our CuttingReleases
page. I'd like to move forward with formally introducing this concept on
our wiki page.
Component Lead:
- For each release, each repo has a
Volunteer maps well to hows its been done implicitly. If you cannot take a
given week, find a sensible replacement.
Rotation among willing folks makes some sense in terms of passing down of
knowledge.
-Michal
On Tue, Sep 3, 2013 at 12:51 PM, Andrew Grieve agri...@chromium.org wrote:
I
the role a little more would help.
Do all the components leads (as listed in Jira) want to be release
masters for their components? If not, James Jong and I could
probably
own
the release master role for a component each, in case any one is
looking to unload
to be release
masters for their components? If not, James Jong and I could
probably
own
the release master role for a component each, in case any one is
looking to unload that.
--
Carlos Santana
csantan...@gmail.com
wrote:
Think we already have this as per the issue tracker concept of
'leads'
but I do agree formalizing the role a little more would help.
Do all the components leads (as listed in Jira) want to be release
masters for their components? If not, James Jong and I could probably
own
Think we already have this as per the issue tracker concept of 'leads'
but I do agree formalizing the role a little more would help. I'd
really love it if we got back to shipping to a date and not to any set
of features, only finished work was being merged back to master, so
cutting a release is a
Great! Yes, I think it works well to have the parent bug should be assigned
to the release master.
I don't think anyone's been trying to base releases on features (aside from
3.0). Our releases have been slow due to the time it takes to test, and the
time it takes to go through all of the release
wrote:
Think we already have this as per the issue tracker concept of 'leads'
but I do agree formalizing the role a little more would help.
Do all the components leads (as listed in Jira) want to be release
masters for their components? If not, James Jong and I could probably own
the release
On Jun 18, 2013, at 5:07 AM, Brian LeRoux b...@brian.io wrote:
Think we already have this as per the issue tracker concept of 'leads'
but I do agree formalizing the role a little more would help.
Do all the components leads (as listed in Jira) want to be release masters for
their components
(as listed in Jira) want to be release
masters for their components? If not, James Jong and I could probably own
the release master role for a component each, in case any one is
looking to unload that.
:
On Jun 18, 2013, at 5:07 AM, Brian LeRoux b...@brian.io wrote:
Think we already have this as per the issue tracker concept of 'leads'
but I do agree formalizing the role a little more would help.
Do all the components leads (as listed in Jira) want to be release
masters
, Brian LeRoux b...@brian.io wrote:
Think we already have this as per the issue tracker concept of 'leads'
but I do agree formalizing the role a little more would help.
Do all the components leads (as listed in Jira) want to be release
masters for their components? If not, James Jong and I
) want to be release
masters for their components? If not, James Jong and I could probably
own
the release master role for a component each, in case any one is
looking to unload that.
14 matches
Mail list logo
