On Feb 24, 2015, at 11:52, Junio C Hamano wrote:
Kyle J. McKay <mackyle@xxxxxxxxx> writes:
Which brings us back to the subject of this email, is there any
chance
for a v2.1.5 release?
...
It appears that the average support lifespan of a Git release from
initial release date through last released maintenance update is
approximately 2-3 months with the 1.7.6 release being an exception at
a little over 7 months.
That matches my expectation.
A typical cycle lasts for 8-12 weeks, and during that time, topics
that are bugfixes that have graduated to the 'master' branch are
merged to the 'maint' branch with some lag and then the tip of
'maint' gets tagged as a maintenance release from time to time.
Some important but trivial fixes are further merged to older
maitenance tracks like 'maint-2.2', 'maint-2.1', etc.
But these topics downmerged to older maint-* branches have to be
very trivial for an obvious reason: there are only 24 hours a day
and 7 days in a week, and bugs that affect real world use cases are
found by using the software in real world use cases. Usually I use
something a bit ahead of 'next' exactly for this reason---we would
want to catch bugs before topics are merged to 'master'. Although I
sometimes have "let's use 'maint' for my work" day once or twice
every month, I cannot afford to do that for anything older than the
tip of 'maint' myself.
Obviously there would have to actually be some interest in having an
older long-term-support release and some folks willing to exercise
such a thing. Unless we can figure out a way to clone you. ;) ;)
The consequence of the above is this. v2.1.1 may be more stable
than v2.1.0 and v2.1.2 may be more stable than v2.1.1, but later
tagged versions on older maintenance tracks are made by merging
topics only after "ah, these are obvious enough" eyeballing without
real use (at least by me), once newer feature release is made and
there is a newer maintenance track. I would not be surprised if
v2.1.5, if it is made, has hidden interactions between the changes
since v2.1.4 and the older codebase to cause unforeseen bugs.
When I say "the tip of 'master' is meant to be more stable than any
tagged versions", I do mean it.
Some fixes would likely not be back portable (e.g. to fix X you first
need change Y which needs change Z which needs ...), not without
ending up pulling in things that exceed the scope of a "maintenance"
update.
Having said all that, if I were to tag maint-2.1 branch as 2.1.5
today, we would have
6aaf956 is_hfs_dotgit: loosen over-eager match of \u{..47}
that does not exist in 2.1.4. Is that what you want?
I suppose in that it fixes "false positives" it is a regression fix,
but if that's all that showed up in v2.1.5, no, that wouldn't make it
worthwhile.
If a v2.1.5 release is out of the question, would it be possible to
periodically designate certain Git releases as "long term support"
releases?
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.
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.
If the lts releases need to be tagged and published by me, then lts
team can have me pull from the tip of maint-lts they are confident
with and have me sign it and push it out.
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.
If the primary concern you have with the currently maintained
releases is git-svn, perhaps a better way forward for you,
especially if you are willing to maintain your own "release plus
patches",
That was the discussion the admins had that we prefer to avoid rolling
our own, but if there's no other option then we will do that. Some
other Git hosters obviously do not have the same reticence about
rolling their own Git release (as can be seen from the capabilities
returned). There are several fixes not yet in a release that are
needed besides just git-svn, but since the other fixes are all in
master now they'll be out in the next release. But, picking up that
release to get those fixes also exposes us to new code that has not
yet had widespread use and a "maint-lts" would hopefully pick up the
fixes without doing that.
might be to keep a patch that reverts recent git-svn
changes back to v2.1.whatever and deploy the up-to-date release
and that patch on top?
That has occurred to me assuming there's not some dependency issue
there that causes a cascade of reversions.
Nice to have: The CVE-2014-9390 fix, but repo.or.cz does not create
any working trees so it's not mandatory.
Even if you do not have a working tree, people who use you as the
meeting place and push into you and fetch from you do, so I do not
necessarily agree with your assessment.
Having the feature does no good unless it's turned on. :) How
expensive would it be to turn such a feature on in terms of CPU
usage? Running `git fsck` is rather expensive and the name of the
config option suggests it's related, is it also as expensive? When
someone pushes a 2GB pack, what impact does that option have on server
load? All existing repos would have to be checked first. Do we eject
any that fail? What about mirrors? Do we refuse to mirror from a
source that fails the check? As long as it's not too CPU expensive, I
could see turning it on immediately for new push repos and after
checking, existing push and mirror repos that pass. Hopefully all of
them just pass the check. So we cannot just deploy a CVE-2014-9390
fix even if we had it without first doing some work assuming the CPU
load is not an issue. But it would be nice to have so we *could*
proceed in that direction.
-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