On Wed, 2009-10-07 at 18:05 -0700, David Brownell wrote:
> On Wednesday 07 October 2009, Zach Welch wrote:
[snip]
> OK by me. Note that there are refs to docs at Berlios throughout
> the source tree. So whoever updates the Users' and Developers'
> guide snapshots next, might want to mirror new copies at SourceForge
> and work out how to publish those URLs ... setup a true website
> mirror, for example. (Or switch everything to SourceForge, etc).
Are these being updated by hand or by script presently? It should not
take much to run a cron job that builds the docs and mirrors them, and I
have a server that could do this job for us.
> > Rather than "moving," I see these changes as "growing", such that we
> > seek to prevent total inaccessibility and communication breakdown.
> > Changing to SF.net will simply change the metrics (for the better, or so
> > we have been led to believe), but using both ensures this goal is met
>
> Fair enough; although splitting efforts between two sites isn't the
> easiest approach either.
>
> For now, the SVN --> GIT switch seems to have hit a few key milestones,
> so now we get to wait for the dust to settle.
I agree that the split is not ideal, but it looks we had few options.
Arguably, it was already there, and we're just redistributing weight. :)
In the future, the best solution will be a server for our own domain,
though not without more resources.
[snip]
> > > So talking in terms of an "RC" model, a week after switching to
> > > the GIT repository seems like the a good time to want "RC1"...
> >
> > Again, this aligns with my thoughts on our progress, as that should also
> > give time to finish converting the release process and script from SVN
> > to GIT. It should be far more useful for others after the re-write too.
>
> Right. You'll see I updated small parts of the text, only,
> and left the release.{txt,sh} mostly alone where they were
> discussing SVN procedures.
>
> For GIT, I think the model is just to tag a release, and then
> branch off that tag if we need bugfix releases (0.3.1 etc).
Yes, it should be simpler too. :) Thankfully.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
