Opened 10 years ago
Closed 10 years ago
#44777 closed update (fixed)
p5-xml-twig @3.39 update to 3.48 (+add p5.18, p5.20, +formating)
Reported by: | nortcele | Owned by: | frank.mcpherson@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch | Cc: | ryandesign (Ryan Carsten Schmidt) |
Port: | p5-xml-twig |
Description
Patch to update p5-xml-twig from 3.39 to 3.48.
Also added p5.18 and p5.20 branches.
Also updated formating to conform to other modules.
Attachments (3)
Change History (13)
Changed 10 years ago by nortcele
Attachment: | p5-xml-twig-3.48.diff added |
---|
comment:1 Changed 10 years ago by dbevans (David B. Evans)
Cc: | frank.mcpherson@… removed |
---|---|
Keywords: | haspatch added; perl5 removed |
Owner: | changed from macports-tickets@… to frank.mcpherson@… |
Version: | 2.3.1 |
comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 follow-up: 4 Changed 10 years ago by nortcele
What is the correct way to do that?
A ticket with two (or more) patches: a first patch for fonctional changes and then a second patch to apply after the first one for cosmetic changes or a ticket for each patch?
Should I update this ticket with new patches?
comment:4 follow-up: 5 Changed 10 years ago by larryv (Lawrence Velázquez)
Replying to Joel.Brogniart@…:
What is the correct way to do that?
A ticket with two (or more) patches: a first patch for fonctional changes and then a second patch to apply after the first one for cosmetic changes or a ticket for each patch?
Two patches in one ticket is fine. Please generate them such that the functional patch is applied last; this keeps svn blame
useful.
Should I update this ticket with new patches?
Yes, please.
comment:5 follow-up: 8 Changed 10 years ago by nortcele
Replying to larryv@…:
Two patches in one ticket is fine. Please generate them such that the functional patch is applied last; this keeps
svn blame
useful.
Is there a rule for Portfile file names in such a case. For one patch, I use Portfile.orig and Portfile to calculate the diff. But with chained patches do I use the same names again or could I use something like Portfile.orig, Portfile.1, …, Portfile?
comment:6 Changed 10 years ago by nortcele
One more question. Adding 5.18 and 5.20 to perl branches should be done in the "cosmetic" patch or in the fonctional one?
comment:7 Changed 10 years ago by nortcele
Here are the two new patches that replace the first (p5-xml-twig-3.48.diff).
The first patch (p5-xml-twig-3.48-1.diff) update the formating of the portfile and add p5.18 and p5.20 perl branches.
The second patch (p5-xml-twig-3.48-2.diff) update p5-xml-twig from 3.39 to 3.48.
comment:8 Changed 10 years ago by larryv (Lawrence Velázquez)
Replying to Joel.Brogniart@…:
Is there a rule for Portfile file names in such a case. For one patch, I use Portfile.orig and Portfile to calculate the diff. But with chained patches do I use the same names again or could I use something like Portfile.orig, Portfile.1, …, Portfile?
Don’t worry too much about it; just make sure they apply. It’s trivial for the committer to use patch FILENAME
instead of patch -p
.
Replying to Joel.Brogniart@…:
One more question. Adding 5.18 and 5.20 to perl branches should be done in the "cosmetic" patch or in the fonctional one?
The whole point of the cosmetic patch is that it only changes the way the Portfile looks, not the way the Portfile works. Adding subports clearly changes how the Portfile works, so it is a functional change that should go in the functional patch.
Changed 10 years ago by nortcele
Attachment: | p5-xml-twig-3.48-1.diff added |
---|
Patch to correct portfile presentation
Changed 10 years ago by nortcele
Attachment: | p5-xml-twig-3.48-2.diff added |
---|
Patch to update p5-xml-twig from 3.39 to 3.48 + add 5.18 and 5.20 perl branches.
comment:9 Changed 10 years ago by nortcele
Patches p5-xml-twig-3.48-1.diff and p5-xml-twig-3.48-2.diff updated according to last remark.
comment:10 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Ideally functional changes should be made separately from whitespace changes. When a diff makes whitespace changes to an entire portfile, it's difficult to identify what functional changes are also being made; this impedes code review and increases the likelihood that errors will be overlooked.