Hi Holger, On 26.11.2016 13:29, Holger Levsen wrote: > can you please explain this commit in src:debian-edu git master: > > commit f0bf59f6ed98f3d5de3832f44deb09003e413ab6 > Author: Ole Streicher <[email protected]> > Date: Fri Nov 11 09:51:33 2016 +0100 > > Reformat to be RFC834compliant > > > RFC834 is from 1982 (yes, from 28 years ago) and is about "Who Talks TCP?" so > there must be a typo…
My mistake; I meant RFC822. According to https://blends.debian.org/blends/ch08.html#edittasksfiles the tasks files should be conform to that. There is a bug #840094, which has a lengthy discussion about exactly this problem. The mentioned commit is part of this process. > And btw, I'm also seriously not impressed by this commit needing FIVE > fixup commits, of which the last three were not even done by you. We had a discussion, and this was accompanied with the commits. And please not that some of the commits were not to fix things that were introduced by the change, but also to fix things that were exposed afterwards -- like duplicate "Section". I am also not sure, if you count correctly; at least I count only FOUR commits after the initial one, and the last one just regenerated debian/control, which one would not count as a "fixup commit". Specifically: f0bf59f6 - Make the tasks file conform to the blends documentation 520b6918 - Keep the original formatting to make it simpler to compare Then, Petter argued that the file has to be processed with the broken "jessie" blends-dev file as well, so that we agreed to re-apply the backslashes (even if they are not standards-compliant): 22f64bc2 - Add backslashes everywhere, to use a broken blends-dev This one still fixed all the other problems with duplicated keywords per section. However, I didn't know what to do if there are f.e. two "Section" entries and concatenated them. This had to cleanup afterwards: 699448cd - Minor cleanup after reformatting (by Petter) And now, to make it usable, a re-creation of debian/control 6f92a1a9 - Generated (by Petter) This is the final check to see what was broken. You can just diff debian/control. > And then it's still unclear why. Please explain. Else I'll just this. The tasks were buggy. Duplicated sections, mixed RFC822 and backslash style led to missing dependencies. > (+sorry if I sound too frustrated but all I can see are 5 broken commits > with a broken explaination… thats a bit too much this close to a freeze.) None of these was broken; they are all fully compliant with the blends documentation. And except for the first one (mixing RFCs), I see no brokeness in the description. Sure, it would have been better to squeeze them finally into one commit; however the gits don't allow rewriting history, so we have to live with having the whole process there step-by-step. But what is the problem with that? What concerns the freeze: The bug #840094 was open since six weeks basically without any response, and at the end I fixed it myself, with all the drawback which happen if a strawman edits Perl. I would have it very appreciated if you would have taken part in this process, by discussing how to proceed, and by checking the individual steps. I don't see why this is affected by the freeze at all: if we find a problem in the next months, we can always create an RC bug for that. Missing dependencies within a blend are IMO RC without any doubt. And RC fixes will pass the freeze. And: As you can see from the diff of debian/control, no new problems were introduced, but at least one dependency (firmware-ralink) was fixed. >From that, I really don't understand your frustration. Please Cc: me if you respond to the mailing list since I am not subscribed. Best regards Ole
