Hi! On 2020-06-10T17:15:41+0200, Tobias Burnus <tob...@codesourcery.com> wrote: > On 6/10/20 3:34 PM, Kwok Cheung Yeung wrote: >> This patch updates the previous entry on the website for >> devel/omp/gcc-9 to refer to the new branch instead. This removes >> references to the old branch, as new development should occur on the >> newer branch. > > Can you move the old entry to "Inactive Development Branches" instead?
Right, please look up in the revision history of how we did that same procedure in the past, then do the same thing now, and it'll qualify "as obvious". ;-) >> + Please send patch emails with a short-hand <code>[og10]</code> tag in the >> subject line, and use <code>ChangeLog.omp</code> files.</dd> > > Do we still need ChangeLog.omp or not? Yes, I wanted to raise this question too -- and that's a general concern for any branches that are not handled by the automatic "commit log to 'ChangeLog' files" updating machinery. The automated system runs once a day. I guess it's generally deemed acceptable if the source code state (commits) and the 'ChangeLog' files state is out of sync for one day. There surely must be some mechanism in place to make sure that actual GCC tarball etc. releases do have complete 'ChangeLog' files state. However, if at an arbitrary point in time, a merge is done, for example, from releases/gcc-10 branch into devel/omp/gcc-10 branch, and then a tarball etc. release is done from the latter, that may not have complete 'ChangeLog' files state, if it wasn't complete at the time of the merge. So that's something to take care of when doing such merges -- or at tarball etc. release time, possibly manually running the updating machinery. > I got used to not adding it > on mainline. If it is needed, I probably need to add one for my last > commit. Indeed the other concern is that people will simply forget to update 'ChangeLog.omp' etc. files given that we're no longer doing it for the GCC main branches. Should we stop doing the manual updates on development branches, too, and extent the automated system to go over all branches? (I suppose, per GNU etc. policy, we cannot just have no 'ChangeLog.*' files on development branches, even if no tarball etc. releases are published from them.) Is it sufficient to keep "ChangeLog state" in the commit log (as we're now doing for GCC main branches), and then run the updating machinery on demand, say, before tarball etc. releases are published? Or should we simply live with the inconsistency between GCC main branches (automatic 'ChangeLog' files updates), and development branches (manual 'ChangeLog' files updates)? Anybody got any clever idea? And sorry, if that has been discussed before, I have not yet read up all the relevant emails. Grüße Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
