Dear Graeme Russ,
In message CALButCJAu4r8wdTpYC7XPfhq_uJFbhQpGUeiNnEx-jHJjK1nUg@mail.gmail.com you wrote:
Currently the lack of any reaction whatsoever was identified to be a very discouraging sign for contributors. One thing we could do is to declare a "soft" time-limit (two weeks) that patches need to be looked at. After this time-limit, one could declare "backup-custodians" to push patches to or merge patches into some "-staging" branch. (What to do with that branch then?) For this to work, custodians would need to announce "off-times" which currently is not general consensus.
Declaring a time limit would not help much. The fact that patches receive no response is not a result of disinterest, but usually of lack of time. In this situation the chances that someone monitors the list for time-outs is small, and even if he spots these, there is still no no resource available for processing the patch.
The idea of "backup-custodians" is not new either. I have requested repeatedly that the existing custodians (who have write permission to patchwork and to the u-boot-staging tree) help me with processing the load of "generic" patches that end up on my table. The amount of patches going this way is minimal. In the last 3 months, only Stefan Roese used this tree, and only for a single pull request.
But this is where help would really be efficient: more people are needed to pick up, review, and especially test the load of generic patches. Things like new file system support are independent of specific hardware (which is why this stuff ends up on my table), so everyone can help here. On the other hand, this stuff is usually qurte test-intensive, so I really need more help with that.
I like this idea in principle. In order to work, I think there needs to be two or three 'top-tier' custodians who will arbitrarily assign 'stale' patches to another custodian. And maybe one top-top-tier custodian (Hi Wolfgang ;)) in case the patch goes very stale.
Assinging work does not help if there are no resources to process the assignments. We already have assignments: usually on me. But I cannot handle all this load.
It was agreed that automatic marking of changes as accepted when changes hit mainline would be a good thing. There is some info on our wiki available, although it is not clear who uses them:
http://www.denx.de/wiki/view/U-Boot/Patches#pwclient and http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html
A tool to automatically mark patches as superceded on newer versions was also suggested to be very valuable.
I regularly use this method to update patch status, but the results are not really satisfactory, especially due to the shortcomings (read: bugs) of PW itself.
Also, if one (and only one) maintainer is Cc'd on a patch, it would be nice is it was automatically assigned to them. Same goes for tags in the patch subject - there should be a way to automatically assign a fair number of patches.
This can probablybe done. I think initial assignment of new patches can be done based on X-Patchwork mail headers. We just need tools that generate these - i. e. a wrapper around git-send-email?
During the discussion it showed that many people believe that patches outside the "regular" merge window are handled in-efficiently ending up as large piles in patchwork. It was agreed that rather then being a
I disagree. There is no real difference between patche submitted during or outside a MW. They all end up on the large pile :-(
"accept / don't accept" division, it should be a "accept into mainline / accept into -next branches" split hopefully keeping the flow of incoming patches more uninterrupted. For this to work, every custodian would open his own "-next" branch and start merging patches from the mailing list resulting in patchwork becoming cleaner during "bug fix" phases.
And this is where patchwork fails us - The list of states is extremely limiting
I think we can define new states if needed. But this does not fix any of the issues that make PW such a PITA to use.
Discussing such automatic merges, the need for continous integration became apparant. As mid- to longterm goals we would like to see automatic builds shifting the requirement to "do MAKEALL" from individual posters to (cheap) machine time. One obstacle on this way is the complexity of automatic builds for different architectures, i.e. which toolchain to use and how to use them correctly.
'Bring out your nightly builds!'
I very much like the idea of continuous integration - The number of time that a build is breaking only to be picked up weeks after the offending commit is getting a bit annoying.
I'm not so sure what makes sense here. I have often dreamed of automatic testing (checkpatch + MAKEALL) of all submitted patches. But looking at the current situation, we not only have big problems because many patches have non-standard requirements (they apply only against a specific tree, and require N previous patches to be applied first), but we would probably aut-reject 95+ % of all submissions. I don't know if thi would be encouraging for submitters...
Simon Glass mentioned that he is working on "buildman" which he will present on the mailing list in due time.
Maybe Simon and Marek could put their heads together?
Best regards, Viele Grüße,
Wolfgang Denk