----- Mail original -----
De: "Kaartic Sivaraam" >
> Heads up, I'm gonna play the devil's advocate a little, here.
Be my guest, you're not alone.
On Sat, 2017-10-21 at 15:56 +0200, nicolas.mailhot@xxxxxxxxxxx wrote:
> No that is not up to the hash function. First because hashes are too
> long to be manipulated by humans, and second no hash will ever
> capture human intent. You need an explicit human action to mark "I
> want others to use this particular state of my project because I am
> confident it is solid".
>
> I would say you're just limiting your thoughts. There's no strict rule
> saying hash functions should be "incomprehensible" to humans or that
> different hashes should be "uncomparable". No one's going to stop
> someone from creating a hypothetical hash function that's totally
> ordered (!) unless you violate the basis of a "hash". (surprise,
> there's already attempts at it,
I'm not terribly interested in future tech incompatible with existing git projects, or with the multiple levels of release numbers projects seem to like.
Besides, even assuming a perfect magical hash, it is not going to replace the human act of choosing a project state others can consolidate on. You can search and replace numbers with magic ordered hash in my original message if you like, the rest does not change.
>> Except, the releasing happens outside git, it's still fairly manual.
> You seem to be more frustrated by "manual" work.
Git users are frustrated with manual work. They've been "spoilt" by a wonderful tool, and want all software engineering actions to be automated as much as possible, including releases. They don't want to setup custom project specific helpers around Git, they don't want to deal with the project specific custom helpers others may have invented for generic actions, they want built-in commands or nothing.
Just take any random sampling of actual Git projects on Github and you'll see masses of people not doing releases or referencing other projects by random commit hash ("random" in the sense there's no coordination on what hash to choose, it may work or not, once it works locally the commit hash reference sediments in the project build env because it is too dangerous to change, there is no cooperation to focus on particular commits to make sure they are solid, and that's a basic project need, as evidenced by the "RHEL" "stable kernel" "Firefox ESR" "Ubuntu LTS" initiatives).
>> All I'm proposing is to integrate the basic functions in git to
>> simplify the life of those projects and help smaller projects that
>> want completely intergrated git workflows.
> Wait, aren't you just trying to make git more than a "version control
> system"? I don't think it's encouraged a lot here given that there have
> patches that have not been accepted because they might make git
> opinionated and the result "doesn't quite fit into the broad picture of
> a version control system"
No I'm not trying to make git more than a "version control system". That's why I don't propose including dependency handling or build rules. However, git needs to hand project state to other tools, every other tool but CI works on discrete states (releases), you need a robust process to identify those states or the handover becomes a pain point. It is starting to failing when devs do not want to identify project states by anything except git objects (a is happening now) and those objects are not adapted to deployment and system-wide softwate management.
Just look at
https://grafeas.io/docs/concepts/what-is-grafeas/overview.html
(brand new Google project)
It is all about 'component identifiers' ie release ids. Most of those components now live in Git. Why does Google need half a dozen different ways to identify software sourced from git? Because Git does not provide good release tracking capabilities. Yet a lot of developers of those projects will insist the only correct id is a Git commit hash (conspicuously missing from Google's examples, because commit hashes are a terrible release identifier).
It is a huge problem when all the actors gravitating around a software project start disagreeing on basic stuff such as how to identify a project state. It is a huge problem when you start maintaining complex rosetta stone infrastructures just because the software layer that should define conventions, refuses to do it, and upper layers are forced to make choices that end up different. There is no inherent advantage to driving left or right. There is a huge advantage when everyone drives the same side.
>> Yes and it is so fun to herd hundreds of management tools with
>> different conventions and quirks. About as much fun as managing
>> dozens of scm before most projects settled on git. All commonalities
>> need to migrate in the common git layer to simplify management and
>> release id is the first of those.
> It's better to have a "good" (generic) release management tool that
> does what you ask (probably with some help from git) than try to turn
> Git into one (which is not possible without making Git opinionated,
> more on that later).
Be my guest, try to define the "some help from git", you'll end up with very similar requirements to mine. For most because you can't do less to be useful, for others because they are trivial to add once the rest is done and it would be woefully inefficient not to do them at the same time.
> I guess there should already be one that meets
> your expectation and you probably just have to discover it.
Funny, it seems the scores of Git projects I have used those past months are in the same situation. Maybe that's because there's no sense in building a standalone tool? Tracking project states is the whole point of Git, you can overlay other tracking systems over the SCM, the end result is inconvenient in the absence of SCM cooperation. That's why so many people are starting to use git commit hashes in places they've never been designed for and are not adapted too. They are fed up with translating between the scm and the overlays.
> Further, if there's no "generic" release management tool in existence,
> I suspect that because there's no such thing a "generic release
> management strategy"
There may be no such thing as a generic release management strategy. There are such things as generic release management steps, which is the only part I propose to automate. Linux package management relies on those commonalities, and they have decades of successful deployment of all kinds of projects by very different authors with very different opinions that sort of prove those commonalities exist.
> and it always depends on context (or) create one
> on your own in the spirit of letting "git" handle just "version
> control" and letting your "genereic" tool handle your concerns. Who
> knows, if you have developed a good enough "generic" tool it might be
> used widely for "release management" just as a lot of projects starting
> using Git for "version control". (I still suspect that there should be
> one that already exists)
Again the problem is not the technical bits, they are rather trivial, the problem is scm integration which can't be solved outside git itself.
>> > git tags ?
>>
>> Too loosely defined to be relied on by project-agnostic tools. That's
>> what most tools won't ever try to use those. Anything you will define
>> around tags as they stand is unlikely to work on the project of
>> someone else
> They are loosely defined because you can't define them "tightly" and if
> you try to it would make Git opinionated !?
That makes them useless for tooling. Any automation will require removing ambiguities humans relish. Keep tags for humans, add release ids for tools. Making Git unambiguous is not the same thing as giving Git opinions (except when the opinion is "don't use release ids cools can't process").
>> > > 5. a command, such as "git release", allow a human with control of the repo to set an explicit release version to a commit.
>> >
>> > This sounds fairly specific to an environment that you are in, maybe
>> > write git-release for your environment and then open source it. The
>> > world will love it (assuming they have the same environment and
>> > needs).
>>
>> If you take the time to look at it it is not specific, it is generic.
>>
>I would say that you might haven't looked broadly enough.
> 1) If it's generic, why isn't there any "generic" release management
> tool?
Why didn't git exist from day one? Is git not generic?
> 2) if it's possible to create a "generic" release management tool and
> it just doesn't exist yet, why not try to create instead of trying to
> integrate release management into Git ?
Because the whole point of Git is to track project states and a release is just a particular state (that happens to be useful for users of a project, not its own devs, which is why it was not included in git from day one. That didn't stop Linus from doing releases manually).
>> You need to identify software during
>> its whole lifecycle, and the id needs to start in the scm, because
>> that's where the lifecycle starts.
> It might not for everyone!
Please present actual facts, that can be discussed.
Regards,
--
Nicolas Mailhot
