On Tue, Jul 12, 2016 at 10:14 PM, FRIGN wrote:
> On Tue, 12 Jul 2016 17:42:37 -0800
> Britton Kerin wrote:
>
> Hey Britton,
>
>> Below is a list of what I intend to do about the remaining (obvious)
>> defects in the dwm patches.
>> The last line of each paragraph is what I have in mind, please object
>> now so I don't waste my time, thx.
>
> I welcome that you take your time to discuss this here. There's nothing
> worse than losing motivation because you do things that are inherently
> not what is expected. It happened to me too.
>
>> checking dwm, attachabove, dwm-git-20120406-attachabove.diff
>> prog dwm patch attachabove diff dwm-git-20120406-attachabove.diff
>> doesn't match any allowed pattern
>> don't know what commit to try to patch
>> Strategy: do nothing because it's ancient
>>
>> [...]
>
> Okay, this probably is the wrong way to go. I will give you a quick
> guide on what would be the best approach in this context because I'm
> so glad you want to spend time on the wiki and fix this old mess. :)
>
> Alright, so ask yourself, for a patch to be useful, which conditions
> does it need to satisfy?
> To answer this question, reflect that users either run stable versions
> or on git, the bleeding edge. Thus, for a patch to be useful, it needs
> to be provided both for stable tags and for the latest git HEAD.
I'm using the non-working patches I wanted. So they may be useful
even if out of date or targeting an old version. It's usually not hard
to update them, but the results do need to be tested (see below).
> I took my time and reworked two pages to fit the "consistent" style
> already seen in the st-section. Please always refer to the st-section
> for style matters, as it is the only consistent patch section on the
> website.
> The pages are
> http://dwm.suckless.org/patches/alpha
> http://dwm.suckless.org/patches/alwaysfullscreen
Ok, I'll try to follow these.
> Especially the author-sections are very inconsistent on the other pages
> and there are many spelling mistakes. We also do not want information
> on size or date of the patches written behind the link.
>
> But as you can see, the reworked patch pages do not offer patches for
> stable versions, which is a problem as especially many Arch users run
> dwm as stable and still want to apply patches to it.
> So how do we solve this?
>
> Let's first make out 3 categories of patches
>
> (1) patches only supplying stable versions
> -> work forward and create patches for each stable tag
>following and the git HEAD respectively
>If it's too much work, always resort to just creating
>a stable patch for the latest version and a git HEAD patch
>
> (2) patches only supplying git versions
> -> create a patch for the _last_ stable version of dwm
>and update the git patch to HEAD
>
> (3) patches only supplying non-identifiable patches
> -> just test out and try to create patches for the latest
>release and git HEAD.
>
> Okay, now, to give a few examples:
>
> A page satisfying (1) is [1]. What you would do there is first try
> to apply the patch to version 5.8.2, as I actually hit more than
> a few cases of mislabeled patches.
> Next, you "forward-port" the patch. This means, you go forward
> to tags 5.9, 6.0, 6.1 and create patches for each version.
> It might look a bit redundant, but you have to forward-port anyway,
> so there's no reason not to provide those patches.
While fixing dwmfifo (which didn't apply cleanly) I broke it in a subtle
way by leaving in a bit of code and it cost some pain. This experience
plus general paranoia makes me doubt that trying to fix other people's
patches is a sustainable strategy. Yes, many of them are dead simple
but it's still possible to screw up, so you have to test everything (at
least I would have to).
I guess it depends how stable dwm itself is. If it's done and no changes
are planned it might be reasonable to gradually port all the patches.
> If you however stumble upon a very ancient patch, feel free to just
> port to the latest version 6.1.
> As a next step, you create a git patch with the agreed upon naming
> scheme:
> dwm-current_desktop-2016-07-30-shorthash.diff
>
> A page satisfying (2) is [2]. Here you have to check out how old
> the patch is and forward-port it. First go to tag 6.1, create a
> stable patch, then make it apply to git HEAD.
>
> A page satisfying (3) is [3]. Here as well, assess the situation
> and create patches for 6.1 and git HEAD.
>
> #
>
> Now, as a final word: I know this is a ton of work. We cannot
> fix the dwm patch section by just renaming patches to a new
True. It's part of plan including emailing the authors. I don't
think renaming or emailing will hurt so I'm going to go ahead
with that, together with page cleanup.
> scheme. We have to do major cleanup and it will require a
> big amount of work.
>
> However, once done,
