Re: [dev] which versions are dwm patches intended to apply to cleanly?

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Thu, 16 Jun 2016 17:41:17 +0200

Hi,
> Admittedly, I don't immediately see the date in there.
You will as soon as you have seen another one.

> Also, always
> think about how you can enforce this properly. Most people don't even
> know how to get a short hash.
Too bad for “most people”, they'll have to learn (that “getting” a
short hash is just getting the first chars of it).
We could have an explanation page for that too.

> > Also condensing the date to skip the century is a good idea in the
> > year 2016. Still 84 years to come without a century problem of patch
> > file names.
>
> This makes it harder to spot as a date.
I agree, I'd be for keeping the whole year, unless we really need to
cut down two characters.

> > I would even go that far to skip the date completely. It doesn't
> > really tell you much. If someone bothers of the age of a patch, then
> > you can always check git with the hash.
>
> We already had this discussion, Anselm, and we concluded back then
> that the date is a great heuristic. The git hash first forces you to
> have the repo at hand. When you go check the patches, the first thing
> you have to think about is: Is this patch still quite recent?
> The recency is always with respect to the project at hand, however,
> this decision can only be made by the user and depends on the nature
> of the commits.
> Additionally, if you have a list of patches
> st-externalpipe-ea87104.patch
> st-externalpipe-fbd023a.patch
> st-externalpipe-fe0239e.patch
> you don't see which one is the newest one.
But there shouldn't be that many in the first place.
The correct way would be to have a patch for release versions, and one
for last git version, the rest is maintenance.
Though having the date in the filename wouldn't hurt and indeed is
handy to quickly see a patch age.

> As a last point of thought: The shorthash gives no info at all. It
> could either be a broken patch against HEAD or not, however, pasting
> the hash in the name somehow claims more than it does, and gives less
> information to 99% of people.
The shorthash gives the information on which commit it was made against.
It could be broken against HEAD or not, but you wouldn't have a patch
named st-externalpipe-BROKEN.patch anyway.
Also it helps to lookup which changes (commits) have been made since
the patch has been produced for maintenance.
Received on Thu Jun 16 2016 - 17:41:17 CEST