Re: cme and stylistic changes in team uploads
On 25/12/16 23:51, Afif Elghraoui wrote:
I think it's enough consistency that people are either using dh_make,
debmake, or the debian-med packaging template and just adding to that.
If people were writing these packaging files from scratch, there would
be real consistency issues.
Come on, I am sure most people just copy an existing debianization that
is close enough to the package they intend to work on, despite our best
efforts to advise against doing so.
I don't impose this on anyone--I would not
force people requesting sponsorship to use it, nor would I change it
while making a team upload.
I'd definitely not request the cme style while I'm recommending it to
newcommers for the said reasons. I'm usually doing it in team uploads
since up to now nobody expressed that its not wanted. I'd not use it
for instance on packages where you are Uploader and I know that you do
not like it.
Place yourself as a newcomer for a minute. You were advised to use cme
because whatever changes you make, you are guaranteed a well-formed
d/control or d/copyright, or else the software will scream at you.
You are now happy with your contribution and get it uploaded, only to be
publicly shamed on the team's mailing list for not respecting the main
uploader's custom style.
Now let me ask you this, does this sound like a great packaging
experience to you?
cme introduces some consistency in the formatting that is definitely
welcome.
Its not *only* the formatting its also a defined sequence of fields
which I consider a helpful standard.
It also helps you flag things like non-secure VCS URIs and
out-of-date standards fairly easily.
Its not just flagging it - its fixing it and by doing so it saves
time.
That is what I meant, I should have been more explicit.
It saves valuable time **not** spent on ensuring the consistency of the
Debian files being worked on. Now, if I have to second-check everything
cme does, then the original purpose of the software is defeated.
Flagging is what lintian does.
Yes, lintian is *only* flagging and I need to rebuild the package
after manual work. Cme does things in advance and saves me another
build which is very convenient.
I agree that can be helpful, but to me it's outweighed by the problems I
have with it.
The problem here is you putting comments in d/control to categorize
dependencies. This is highly non-standard. If you really want to do such
thing, then you should be using build profiles [1] which would bring
additional benefits.
[1] https://wiki.debian.org/BuildProfileSpec
Otherwise, your comments in d/control are just plain noise, I am afraid.
While cme also makes those changes for
you, it removes trailing commas from listings (making for noisier diffs)
I admit I was considering a bug report against cme about this but
somehow never took the time. In the past I learned that cme authors are
quite sensible and if you have good reasons are responsive about this.
I understand why they would want to classify this as WONTFIX. Supporting
many exotic formating practices is a pain.
So if this really concerns you I'd try a bug report if I would be in
your shoes.
and misaligns all itemized lists.
I never observed this. Could you please give an example? That could
also be a topic for a bug report.
This is really not a big deal, but I was referring to something like:
Build-Depends: A,
B,
C
...
Depends: D,
E,
versus
Build-Depends:
A,
B,
C
...
Depends:
D,
E
where in the latter case, both lists are aligned. Again, not a very big
deal.
Not a very big deal indeed!
I'm not trying to convince anyone because I'm not really interested in
disputing style; all I'm saying is that if someone wants to make a team
upload, I don't think that making stylistic changes should be part of it.
It depends. If I know that the team member does not like it I agree.
He made himself clear, that is for sure.
However, in the past I touched so many packages of team members who in
the beginning were not aware about cme and its features and who were
happy about the change or team members who somehow stopped caring for
the package in question or left the team at all that the overall style
consistence became a feature of the Debian Med packages which I do not
want to miss today. That's the reason we have even put
... simply call
cme fix dpkg-control
to get a properly formated, sanity checked debian/control file.
in our team policy[1].
I had the same experience, even for contributions outside d-science and
d-med.
Although in the case of someone leaving the team or stopping work on a
package, presumably someone else has joined the uploaders list, in which
case subsequent changes are no longer Team uploads. My suggestion was
only to not change style as part of Team uploads.
That being said, like any other tools, it should not be used blindly and
whoever messed with your comment should have inspected the diff before.
I confirm that messing up comments is a bug (which I also was to lazy to
report - which I always regret if I touch a package with comments in
d/control).
Please consider not using comments in d/control, period. d/control is a
packaging metadata file, not a rules list. There are other tools (build
profiles) or files (README.source or README.Debian) better suited for
this purpose.
You can blame someone for not reading the README files and messing up
the packaging despite the instructions, but not for forgetting to check
your non-standard comments in d/control really.
Is there a reason to apply cme systematically to packages as part of any
upload? Besides my dislike for what it does to the file, it has in one
case moved a Depends line away from the comment that describes it (so
the comment ends up being next to something else).
Definitely a bug.
Ok
IMHO we should consider two things:
1. File bug to not mess up comments
+1
2. File wishlist bug "please provide options for different style"
Or maybe the "fix" command should only fix actual problems and not make
unnecessary rearrangements and spacing changes. Maybe there could be a
command like `cme rewrite` to do what "fix" currently does.
If this might solve your issues about the usage of cme in team uploads
I'd be happy.
With my change to your second point, I think it would.
If not we should probably find a way to ensure not to
mess up individual team members preferences which I would respect if
explicitly expressed in contrast to the recommendations in our policy.
-1. I think that requiring everyone to have to remember everyone else's
quirks will create huge barriers to teamwork over time, with the brunt
of the problems coming to newcomers who have enough to learn aside from
getting inside everyone's head. I'd like to agree with everyone on a
standard procedure.
We should all just "take one for the team" and stop this madness of
imposing one's style over a consistent one.
I take this opportunity to thank Andreas for introducing me to cme back
in the day when I was still a packaging newbie.
Ghis
Reply to: