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

Re: [atomic-devel] Roadmap / tracking for Project Atomic top level




----- Original Message -----
> From: "Joe Brockmeier" <jzb redhat com>
> To: atomic-devel projectatomic io
> Sent: Thursday, December 4, 2014 1:16:01 PM
> Subject: Re: [atomic-devel] Roadmap / tracking for Project Atomic top level
> 
> On 12/04/2014 10:27 AM, Matt Micene wrote:
> > Based on a quick IRC conversation with Colin, I've been thinking about a
> > quick way to get some level of tracking for "project" level items vs
> > "component" level items.  E.g., adding a new package to Atomic vs thread
> > safe OstreeSysroot for rpm-ostree.
> > 
> > Since we're tracking the component source and web site in Github, I'm
> > proposing a way to use that system for milestones, proposals, architecture
> > changes, etc.  It's probably not the best way, but it's something we can
> > get done quickly.
> 
> What would be the best way, do you think? How hard will it be to
> transition if we start using this method and go to something else later?
> 
> Quick and good enough is fine with me, as long as it doesn't leave a lot
> on the table or make scaling the project overly difficult as we grow.
> 
> > Create a top level 'governance' repo in the Project Atomic top level.  This
> > project would be the source for things like the Atomic Host Definition,
> > reference package list, test plans, etc.
> 
> +1

+1 We do need something like this.

> 
> > Using labels, we can use the Issue tracking for this repo for proposals,
> > non-component specific tasks (e.g., vagrant boxes), discussions, etc.
> > Labels can identify the intent of the issue (enhancement, comment,
> > architecture) and the domain (networking, orchestration, container
> > engine).  Accepted proposals could turn into new issues on component repos.
> > 
> > With issues, we can capture milestones and tasks, and get a rough idea of
> > what makes up Project Atomic 0.5, 0.6 without being tied to a specific
> > Fedora release.
> > 
> > A few issues I see from the start.  There's no direct tie between issues in
> > all the repos, but we could use issues to track issues, bad duplication and
> > I'd like a better way.  We also have two spots for discussion in that case,
> > atomic-devel and github issues, tracking commentary could become
> > problematic.
> 
> Can we send github issues to atomic-devel, I wonder, the way we send
> Trac discussions to cloud lists fedoraproject org?
> 
> Separately, I think it's time we start considering more formal
> governance. My bias is towards something like an Apache Project
> Management Committee (PMC) where the general trend is towards consensus
> and people can be added as they show involvement without a specific
> number of board members or whatnot. Perhaps I should flesh that out a
> bit more and send a separate note.

+1

> 
> Best,
> 
> jzb
> --
> Joe Brockmeier | Principal Cloud & Storage Analyst
> jzb redhat com | http://community.redhat.com/
> Twitter: @jzb  | http://dissociatedpress.net/
> 
> 


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