On Tue, Nov 20, 2012 at 12:04:16PM -0500, Michael Orazi wrote:
----- Original Message -----
> On Tue, Nov 20, 2012 at 05:12:15PM +0100, Giulio Fidente wrote:
> > hi Steven
> >
> > On 11/20/2012 05:04 PM, Steve Linabery wrote:
> > > It's certainly not a 'proper' release, with docs, release
> > > announcement, description of what other components are required
> > > (factory, et al).
> >
> > agreed, I was trying to find out if and how the tags/branches of
> > the
> > components relate to each other (inclunding factory, oz, cli, maybe
> > TIM
> > at some point in the future)
>
> Yes, that aspect is definitely missing from the end of sprint
> release.
>
> We should document at end of sprint (on wiki or elsewhere, even if
> it's not an actual release) what other components' version/release
> info was.
>
> >
> > >> Also, do you see the idea of tagging all the components with the
> > >> same
> > >> tag a valid approach or are there different suggestions?
> > >
> > > What I would like to see on an actual upstream release is:
> > > 1) create maintenance branch and tag on that branch
> > > 2) bump version number on master branch for ongoing development
> >
> > to be honest, I'm not sure what are the best practices for such a
> > complex project where we want to merge the development efforst from
> > different components, but your looks to me a good approach
> >
>
> In my fantasy world, dev-tools takes a tag name (or a URL to a config
> that we post as part of the release) and grabs/installs all the
> right components. We discussed this approach in our last meeting,
> but since then I have mentioned the idea to Crag Wolfe, who seemed
> open to the idea (while acknowledging that there is a lot of work to
> do before dev-tools can do that sort of thing for us).
>
> s|e
>
To refine the fantasy oh so slightly, it is a tag name per repo/project. They can
potentially be distinct and we can't enforce a naming convention across all the repos
(I'm thinking imgfac in particular is really working hard to become more firmly
entrenched upstream and may have their own process/procedure around tagging).
One thing that keeps flitting through my brain but not staying long enough to determine
if it is a good idea or not is that it might be handy to have a 'meta-tag' to
simplify picking the appropriate tags for all the sub-projects and pushing that
information into a dev_tools run.
Yeah, that was what I was trying to get at (sort of) with my 'set of ENV variables in
a config file, hosted on
aeolusproject.org associated with a particular set of release
docs' idea.
IOW, we'd have a canonical doc up there that defined component:tag for all the
components that constitute a working release.
Am I making any sense? :)
s|e
> > devs, any hint on this?
> > --
> > Giulio Fidente
>