On 27 Jun 2016, at 7:52, Paul Jakma wrote:
On Sat, 25 Jun 2016, Martin Winter wrote:
My bad. I thought that only patches which are in a working stage
should be selected for proposed branch (the “proposed” would be
for code review, functionality etc).
Maybe my bad for not pre-sorting those onto some 'pushback' branch
then.
I’m partially a bit frustrated on the guesswork on automatically
testing series of patches - which is the reason why I’m pushing to
try the github pull request model for this. Patchwork has no concept
of series of the patches.
I thought it did? It seems to get the '[Patch X/Y]' in the right order
in the web-UI at least, even when they go through the list in another
order and get non-consecutive PW IDs. Though, the non-consec IDs will
make scripting annoying.
It does partially. But the series have no common subject or reference to
match the series. I can only guess that there aren’t
2 overlapping series from the same contributor.
At the time of updates (when people only send a v2 for a specific patch)
it gets even worse as I have a hard time to
go back to find the original series and to guess if I should rerun
immediately or wait for another v2 part from the same
series.
At this time, I look at subject, msg-id and sender and try to
re-assemble the series. But this fails whenever someone resubmits
just a single replacement v2 patch or doesn’t use “git
send-email”. So the larger the patch, the more likely my automated
system fails to detect them.
Ouch. We need another way.
I'm really leaning towards Bugzilla now. There are at least two
different sets of git tools. The one I've tried is good enough. It
would give one ID for patch-trains, with the ability for a contributor
to manage and update revisions of the attached patches. Etc. It
doesn't try take over.
The instance we have needs upgrading though. The other downside is
that, iirc, git bz doesn't quite work with HTTP proxies - though that
seems to be some issue with the underlying library somehow. However,
there's a lot of projects using it to some degree AFAICT - fate
sharing is nice.
My hope is still Pull Requests on Github. I can’t say how well it
works, but I’m eager to give it some tries.
Personally I prefer someway a 2-path version: the current version (works
fine for one-off patches and for contributors
which are not regulars) and a some pull-requests for more complex ones.
Maybe your proposed branch could be a pull request as well?
(Discussion could be still linked back to list, potentially with some
proxy to forward it. There is no requirement
for discussion to be on Github)
Would allow to redo the pull request multiple times without cluttering
the official git history.
Doesn’t matter if it’s part of a series or not - it should get
you directly to the test run(s) for
that specific patch.
Cool
Would love to mark pass/fail on patchwork each pass automatically, but
not sure if/how this could be done.
- Martin Winter
Aha, will look.
Would be good to remind everyone that it IS (or should be) a
requirement for
acceptance that it passes “make check” at the time of a patch
submission.
Ah, yes. +1
regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Pure drivel tends to drive ordinary drivel off the TV screen.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev