[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...



On Thu, Jul 05, 2018 at 02:02:33PM -0500, Doug Goldstein wrote:
> On Thu, Jul 05, 2018 at 06:51:16PM +0000, George Dunlap wrote:
> > > 
> > >> Again, there was a sense that some of the issues we are seeing could be 
> > >> solved if we had better 
> > >> CI capability: in other words, some of the issues we were seeing could 
> > >> be resolved by
> > >> * Better CI capability as suggested in the Release Cadence discussion
> > >> * Improving some of the internal working practices of the security team
> > >> * Before we commit to a change (such as improved batching), we should 
> > >> try them first informally. 
> > >>   E.g. the security team could try and work towards more predictable 
> > >> dates for batches vs. a 
> > >>   concrete process change
> > > 
> > > My feeling on CI is clear in this thread and other threads. But I think
> > > what would help OSSTEST bottlenecks if we do better at separating up
> > > different parts of the testing process into more parallel tasks that
> > > also provide feedback to the contributor faster. I'll obviously never
> > > suggest the GitHub/GitLab PR/MR model to a ML driven project because I
> > > wouldn't survive the hate mail but there is something that those models
> > > do provide.
> > 
> > FWIW we (IanJ, Wei, Roger, Anthony and I) just had a fairly extended 
> > discussion about this in our team meeting today, and everyone basically 
> > agreed that there are some things about the web-based PR model that are 
> > *really* nice:
> > 
> > 1. Effective tracking of submission state — open / assigned to a reviewer / 
> > merged / rejected
> > 2. Automation 
> > 3. Not having to marshal git commits into email, and then marshal them back 
> > into git commits again
> > 
> > On the other hand, the general consensus, from people who had used such 
> > websites “in anger” (as they say here in the UK) was that they really 
> > didn’t like the way that reviews worked.  Email was seen as:
> > 1. Much more convenient for giving feedback and having discussions
> > 2. Easier for people to “listen in” on other people’s reviews
> > 3. More accessible for posterity
> > 
> > In the end we generally agreed that it was an idea worth thinking about 
> > more.  Not sure how the wider community feels, but there are at least a 
> > decent cohort who wouldn’t send you hate mail. :-)
> > 
> >  -George
> 
> I guess my point is "No one think that I'm suggesting the web PR model
> so please don't fire off the email cannons!". But I was say there are
> some nice things about the model like you mentioned. I'm wondering if we
> could somehow implement something to get the best of both worlds if that
> makes sense. That's what I'm hoping to do with GitLab but I haven't had
> the cycles to dive deeply into it.
> 
> --
> Doug

I'll also mention I personally feel less comfortable reviewing things
on the mailing list. I review and read through most patches but I don't
comment on them because I'm not necessarily confident enough to add my
R-b to them. I'm not sure if others feel this way.

--
Doug

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.