On October 9, 2003 10:54 pm, Dimitrie O. Paun wrote:
On October 9, 2003 09:58 pm, Geoff Thorpe wrote:
look/feel/use, like "wine-cvs". I would have personally thought that attachments make more sense, because separating patches from text can be ambiguous and it's not as easy to send multiple patches (eg. when submitting two alternative patches?)
It is strongly discouraged to send multiple patches. It has been discussed before multiple times, please search the archives. This is
The submission and processing of patches is not something totally alien to me, though the specific history and conclusions reached w.r.t. wine mail lists is. That said, you needn't crusade the inlining argument by dispatching me to the list archives about whether multiple patches are "discouraged" or not. Email, attachments, patches, and mail-lists are tools, not religions - hence any filter, such as that which we are discussing, should be there to help people receive what is easiest for them to use and not to stuff dogma down their throats. If I have three small alternative fixes to the same file, I will send an email explaining the situation with the three patches attached - not even Linus Torvalds would get far in convincing me that this is "Wrong(tm)". The point is, how can we (Shachar in particular) utilise a bit of perl tech in the mail server to make this easier for you, Alexandre, and others who have particular requirements/preferences/etc, whilst tolerating as many different "styles" of submission? This is surely the point, no?
not something new, it has been discussed in other places (like the linux-kernel), multiple times, and every time we reach the same conclusion: the ideal situation is to have the patches inlined (patch takes are of extracting it just fine). The next best thing is attachment as text/plain, but not nearly as desirable as inline patches.
Anyway, I appreciate your point, but I personally maintain (ie. my opinion, for what (little) it's worth) that attachments are the best means by which to attach files to emails - without line wrapping, and with suitable MIME types to allow proper handling (my mailer will pretty-print attachments that look like patches, for example). Also, it will be easier for a mail filter to inline an attached text/plain file than to extract and attach inlined patches. In many mail clients, the email itself is not readily accessible as a raw file for piping through an appropriate cmd-line - on the other hand, the attachments are often neatly listed, extension/mime-type registered *as* patches, and even drag-n-droppable to CVS/diff tools. The primary (valid) objection to this is that "MUAs do it inconsistently so that it is too unreliable", but that is one of the reasons for embellishing the list-server with a filter like what we're suggesting.
The conclusions you refer to about patch submissions in the past have, presumably, centred around the premise that you need to standardise it because WYSIWTG (what you send is what they get). In that case, I agree that you are forced to put rules/standards in place to avoid chaos. But right now we are discussing a filter for the express purpose of being more tolerant in what is accepted, and more helpful/consistent in what is generated. I happen to think this makes more sense than forcing people through a dedicated patch/ticket management system, yet has many of the same advantages of abandoning traditional mail-lists (eg. you have less scope to "get it wrong"). BTW: another example - we could perhaps detect context diffs and, as with emails that don't satisfy any filter rules, prepend some banner text to the email body noting that the patch seems to be of an inappropriate format and should be resubmitted as a unified diff. Alexandre and the rest of us could simply ignore such postings without passing any comment, the submitter will see the bannered post turn up soon enough and can resubmit something better.
preferences. Then again, if the filter takes place prior to mail-list processing maybe just splitting the list into multiple "channels" makes more sense, where you default to one of them but can change it via the preferences/unsubscribe administration. BTW: this is exactly what happens for people wanting daily digests instead of individual postings.
That's an idea, but it means we have to patch mailman which will make future updates harder (unless mailman has provisions for such extensions). Maybe we convince them to integrate such a feature in the next release :)
It would make sense for it to support extensions like that. Just as you prefer inline patches on wine-patches, I'd like to see either inlined or attached patches on wine-cvs mail-outs rather than a URL. OTOH: I fully understand why the commit script's default action is to only send a URL, but as disk space and bandwidth are not (yet) a pressing concern for me I'd find it more convenient to just see the committed patch there. Again, I think the use of filters and value-adds like this is to give people what they want (and tolerate difference in what they send), rather than shackling them with the shared limitations of email, mailcap, and the consequent rules and regulations we use to get by amid the mess.
But if mailman can't do it, there would still be other ways to organise this, only they would be uglier and trickier. Do we actually know yet if someone at winehq will "let this happen"? And likewise, would Alexandre (as the primary target of wine-patches) like to express any thoughts on this? :-)
Cheers, Geoff