On 22 Mar 16:13, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 22 Mar 2016 15:09:23 +, Finucane, Stephen wrote:
>
> > Actually, I stand corrected. Doing the above would require the 'Label'
> > model having a many-to-many relationship with both a 'Project' and a
> > 'Patch'. There doesn't seem
Hello,
On Tue, 22 Mar 2016 15:09:23 +, Finucane, Stephen wrote:
> Actually, I stand corrected. Doing the above would require the 'Label'
> model having a many-to-many relationship with both a 'Project' and a
> 'Patch'. There doesn't seem to be any way to enforce this at the ORM
> level, and
On 03/15/16 17:09, Finucane, Stephen wrote:
On 09 Feb 11:40, Thomas Petazzoni wrote:
[snip]
Right now, in the Buildroot project, we are entering our "debug cycle".
During this cycle, we don't merge any new features or package updates.
But our patchwork is full of such patches. So it would be
On 09 Feb 11:40, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 9 Feb 2016 10:35:12 +, Finucane, Stephen wrote:
>
> > > Well, the tags are per-patch, so I don't really understand this
> > > question. Of course, you could make the tag support an optional
> > > functionality on a per-project
Hello,
On Tue, 9 Feb 2016 10:35:12 +, Finucane, Stephen wrote:
> > Well, the tags are per-patch, so I don't really understand this
> > question. Of course, you could make the tag support an optional
> > functionality on a per-project basis, if that's what you mean.
>
> So my concern is that
On 07 Feb 16:02, Thomas Petazzoni wrote:
> Hello,
>
> I don't remember if I already suggested this feature, or if it has been
> suggested in the past already. If that's the case, then sorry for the
> duplicate.
>
> Over at the Buildroot project, we often handle a fairly long queue of
> patches
Hello,
On Mon, 8 Feb 2016 15:02:36 +, Damien Lespiau wrote:
> Now, I can't stress enough that I still need to iron out some corner
> cases. There also are cases where it's ambiguous what the sender is
> trying to do. Parsing the intention of the submitter is hard, people
> will do the
Hi All,
Btw, is patchwork able to group several patches from one patchset?
I.e. typical git-send-email structure:
[PATCH 00/03] intro
|-[PATCH 01/03] first
|-[PATCH 02/03] second
|-[PATCH 03/03] third
I'm asking here, because it might be related to tagging/classification
topic.
One
On Mon, Feb 08, 2016 at 04:39:15PM +0200, Ruslan Kuprieiev wrote:
> Hi Damien,
>
> That looks great!
> Is it a pure pwclient you are using?
This is a different version of patchwork that I maintain for our own use
(I'm part of the i915 kernel team at Intel). That version is deployed on
Hi Damien,
That looks great!
Is it a pure pwclient you are using?
Thanks,
Ruslan
On 02/08/2016 04:25 PM, Damien Lespiau wrote:
On Mon, Feb 08, 2016 at 03:28:26PM +0200, Ruslan Kuprieiev wrote:
Hi All,
Btw, is patchwork able to group several patches from one patchset?
I.e. typical
On Mon, Feb 08, 2016 at 03:28:26PM +0200, Ruslan Kuprieiev wrote:
> Hi All,
>
> Btw, is patchwork able to group several patches from one patchset?
> I.e. typical git-send-email structure:
> [PATCH 00/03] intro
> |-[PATCH 01/03] first
> |-[PATCH 02/03] second
> |-[PATCH 03/03] third
>
On 02/08/2016 07:46 PM, Damien Lespiau wrote:
On Mon, Feb 08, 2016 at 05:19:37PM +0200, Ruslan Kuprieiev wrote:
It looks fantastic, and it is exactly what I've been looking for for a long
time now.
Why aren't these features merged into base patchwork yet?
I wanted to make some fairly big
On Mon, Feb 08, 2016 at 08:08:58PM +0200, Ruslan Kuprieiev wrote:
> >As mentioned before, Freedesktop's patchwork has a somewhat strong
> >opinion on distribution dependencies. It favours deploying patchwork in
> >an isolated, sateless, WM/container (or at least in a virtualenv) with a
> >tight
On Mon, Feb 08, 2016 at 04:18:53PM +0100, Thomas Petazzoni wrote:
> I think it's not a big deal if patchwork sometimes doesn't recognize a
> new version of a series as being a new version, and leaves it to the
> project admins to mark the old version of the series as superseded
> manually.
>
>
On Mon, Feb 08, 2016 at 05:19:37PM +0200, Ruslan Kuprieiev wrote:
> It looks fantastic, and it is exactly what I've been looking for for a long
> time now.
> Why aren't these features merged into base patchwork yet?
I wanted to make some fairly big design decisions that didn't resonate
well with
Hello,
I don't remember if I already suggested this feature, or if it has been
suggested in the past already. If that's the case, then sorry for the
duplicate.
Over at the Buildroot project, we often handle a fairly long queue of
patches in our patchwork, currently around 350+ patches. One thing
16 matches
Mail list logo
