[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Roadmap / tracking for Project Atomic top level
- From: Jason Brooks <jbrooks redhat com>
- To: jzb redhat com
- Cc: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] Roadmap / tracking for Project Atomic top level
- Date: Thu, 4 Dec 2014 16:53:49 -0500 (EST)
----- 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]