On Feb 24, 2015, at 21:13, Junio C Hamano wrote:
"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 ;-)
Doesn't seem to be catching much interest though. Maybe they're all
just watching silently peering through the blinds waiting to see how
it turns out. ;)
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.
If I were to keep a maint-lts up-to-date somewhere (with suitable down-
merges matching the manner in which you maintain your tree) that you
could pull from and potentially make releases from. I would not want
to pick up anything that hadn't already made it into master or maint
and I don't think any actual release based off maint-lts should have
any fix that has not already appeared in another non-maint-lts
release. So any given maint-lts release date would be expected to lag
behind the corresponding master/maint release date that contained the
same fixes (except possibly for a coordinated security fix release).
That said, there's no reason I couldn't also keep a pu-lts up-to-date
somewhere external to your tree that interested parties could grab
that would include fixes making their way into maint/master that I
believe would be candidates for inclusion in maint-lts once they
graduated.
I would like to better understand how the various heads are
maintained. I've read MaintNotes and I've got the concepts, but I'm
still a little fuzzy on some details. It looks to me like all topics
still only in pu after master has been updated are then rebased onto
the new master and then pu is rebuilt. MaintNotes doesn't get into
the rebasing details. None of the graphic log viewers I've tried are
much help -- too many lines running around although the graphiclog on
repo.or.cz helps a bit as it shows --first-parent links as a bolder
line, but still after the first page that's not much help either.
I vaguely recall you may have explained some of this in more detail in
the context of explaining how you used the scripts in todo to put
everything together when someone asked a question about it on the
list. But I can't seem to find that message anymore. :(
I think I mostly understand how master, next and pu are maintained.
But MaintNotes says "Whenever a feature release is made, 'maint'
branch is forked off from 'master' at that point." What happens to
the previous maint at that time? Is it just renamed to maint-X.X?
Also, how do you handle a down merge to maint when you have this:
* (master)
* merge topic foo
|\
| * topic foo
|/
* c
* b
* a
* (tag: vX.X.X, maint)
*
And you want to down merge topic foo into maint (where foo is a topic
that didn't even first enter pu until some time after the vX.X.X
release). Won't doing 'checkout maint', 'merge ":/^topic foo"' pull
in commits a, b and c as well? I can think of several things to do
here, but how do you normally handle this situation?
-Kyle
--
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