On 06/08/2012 12:38 PM, Darrell Anderson wrote:
> A monthly release does not mean a complete overhaul of the mirrors, etc. We would need only resync those packages that change. At three or four bug resolutions that likely would mean only a package or two changes.
> 

I'm all for showing the progress each month. The nice thing about git is that
for those building, a simple pull shows the progress. Since creating the
tarballs from the git tree is a simple script that takes about 3 minutes, there
is no reason not to provide the snapshots. I think that a monthly updates
summary of bugs fixed, milestones reached would serve the project well.

I can't emphasize enough how well Arch Linux does this directly from the git
repository they use. If you haven't done so, then check out the way Arch
integrates its git project into its main page to keep everyone up to date on
what has changed in the distribution. Just take this example:

http://www.archlinux.org

then in the upper right where the search box is for packages, just type in
'cups' or another package you are interested in. It jumps straight to the
package summary with links in the top right for source/changes, etc.. that links
directly to the git repo.

I'm not pushing Arch, but I am pushing how they have done their site, their
publication of updates, and their wiki -- it is the smartest setup I've seen and
I've looked at a lot....

> A monthly stablization release will be much easier to manage after R14 than trying to backport patches for 3.5.13 because much changed between R14 and 3.5.13. After R14 we should be quite stable (ABI/API) and monthly bug patches should be easy to coordinate among packagers.
> 

The cleaner R14 is -- the easier to manage afterwards it will be. I think it is
on the right track and I think you have some good ideas.

> Just ideas and thoughts.
> 
> Darrell


-- 
David C. Rankin, J.D.,P.E.