"Kyle J. McKay" <mackyle@xxxxxxxxx> writes: >> I can designate ;-), but I do not think I'd be the right person to >> maintain or long-term-support it. Are you volunteering to oversee >> the "LTS team"? > > I could not promise a team of more than one member. And that would > not be full-time 24/7 either. Heh. Making noises to find like-minded people would be the first step to build a viable team, and hopefully you are already doing a good job here ;-) >> It would involve: >> >> - Monitor "git log --first-parent maint-lts..master" and find >> the tip of topic branches that need to be down-merged; >> >> - Down-merge such topics to maint-lts; this might involve >> cherry-picking instead of merge, as the bugfix topics may >> originally be done on the codebase newer than maint-lts; > > I've been cherry-picking fixes for a while now onto older releases. I > don't suppose down-merging would be that much more difficult with a > fallback to cherry-picking. > >> - Use the tip of the maint-lts branch in everyday work. >> >> The last item is the most important of the above, because I do not >> have time for that. I can help with the first two to some degree, >> though. > > That's pretty much all I use at this point -- a slightly older release > with cherry-picked fixes. While it did cause me to find the problem > with the first version of the loose alternates fix, having only one > person use such a release doesn't provide that much coverage. That is why I used the word "team". > It occurs to me that if the "maint-lts" updates were limited to crash > fixes, regressions and security issues then often the pre-built man > pages and docs from the release it's based on could be used as-is with > the exception of the new release notes which might save some time. Cutting release tarballs including the pre-formatting docs might consume a lot of machine time, but it does not cost me time at all. I have Makefile for that ;-) Judging which fixes that have proven themselves to be safe and sound (by being in 'next', 'master' and hopefully 'maint' for some time) are worthy enough of down-merging to the LTS track is something I'd want to farm out to the LTS team. I am already doing the "safe and sound" part by deciding which topics to merge to 'maint' among the topics that have gone through 'pu' to 'next' to 'master' branches, but not all that are worthy enough to be merged to 'maint' may be important enough to bother downmerging and updating LTS track with, and picking which ones matter to the LTS users is what the folks who are interested in the LTS can help. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html