* xfsprogs process question
@ 2020-03-12 14:13 Christoph Hellwig
2020-03-12 15:46 ` Eric Sandeen
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2020-03-12 14:13 UTC (permalink / raw)
To: sandeen; +Cc: linux-xfs
Hi Eric and others,
I've recently tried to port my attr cleanups to xfsprogs, but noticed
that a lot of patches from others are missing before I could apply
my ptches. Any chance we could try to have a real xfsprogs for-next
branch that everyone can submit their ports to in a timely fashion?
Without that I'm not sure how to handle the porting in a distributed
way.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfsprogs process question
2020-03-12 14:13 xfsprogs process question Christoph Hellwig
@ 2020-03-12 15:46 ` Eric Sandeen
2020-03-12 16:17 ` Allison Collins
2020-03-13 6:54 ` Christoph Hellwig
0 siblings, 2 replies; 6+ messages in thread
From: Eric Sandeen @ 2020-03-12 15:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-xfs
On 3/12/20 9:13 AM, Christoph Hellwig wrote:
> Hi Eric and others,
>
> I've recently tried to port my attr cleanups to xfsprogs, but noticed
> that a lot of patches from others are missing before I could apply
> my ptches. Any chance we could try to have a real xfsprogs for-next
> branch that everyone can submit their ports to in a timely fashion?
> Without that I'm not sure how to handle the porting in a distributed
> way.
I guess the problem is that libxfs/ is behind, right. I have indeed
always been late with that but it's mostly only affected me so far.
Would it help to open a libxfs-sync-$VERSION branch as soon as the kernel
starts on a new version?
I've never quite understood what the common expectation for a "for-next"
branch behavior is, though I recognize that my use of it right now is a bit
unconventional.
-Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfsprogs process question
2020-03-12 15:46 ` Eric Sandeen
@ 2020-03-12 16:17 ` Allison Collins
2020-03-12 16:32 ` Eric Sandeen
2020-03-13 6:54 ` Christoph Hellwig
1 sibling, 1 reply; 6+ messages in thread
From: Allison Collins @ 2020-03-12 16:17 UTC (permalink / raw)
To: Eric Sandeen, Christoph Hellwig; +Cc: linux-xfs
On 3/12/20 8:46 AM, Eric Sandeen wrote:
> On 3/12/20 9:13 AM, Christoph Hellwig wrote:
>> Hi Eric and others,
>>
>> I've recently tried to port my attr cleanups to xfsprogs, but noticed
>> that a lot of patches from others are missing before I could apply
>> my ptches. Any chance we could try to have a real xfsprogs for-next
>> branch that everyone can submit their ports to in a timely fashion?
>> Without that I'm not sure how to handle the porting in a distributed
>> way.
>
> I guess the problem is that libxfs/ is behind, right. I have indeed
> always been late with that but it's mostly only affected me so far.
>
> Would it help to open a libxfs-sync-$VERSION branch as soon as the kernel
> starts on a new version?
>
> I've never quite understood what the common expectation for a "for-next"
> branch behavior is, though I recognize that my use of it right now is a bit
> unconventional.
>
> -Eric
I've run across this a few times working on the delayed attr series too.
Sometimes I'll just have to go through the kernel side patches and find
the missing pieces and port them myself just to get things to seat
correctly. Eventually the xfsprogs side catches up, but it would seem
to me that if we all did this it would help to catch up the user space
side and keep it maintained. I've often wondered how one person manages
to keep up with that! :-)
Allison
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfsprogs process question
2020-03-12 16:17 ` Allison Collins
@ 2020-03-12 16:32 ` Eric Sandeen
2020-03-12 17:33 ` Allison Collins
0 siblings, 1 reply; 6+ messages in thread
From: Eric Sandeen @ 2020-03-12 16:32 UTC (permalink / raw)
To: Allison Collins, Eric Sandeen, Christoph Hellwig; +Cc: linux-xfs
On 3/12/20 11:17 AM, Allison Collins wrote:
> I've often wondered how one person manages to keep up with that! :-)
It seems that the answer is "badly" ;)
(TBH Darrick is a huge help here, in the long run.)
-Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfsprogs process question
2020-03-12 16:32 ` Eric Sandeen
@ 2020-03-12 17:33 ` Allison Collins
0 siblings, 0 replies; 6+ messages in thread
From: Allison Collins @ 2020-03-12 17:33 UTC (permalink / raw)
To: Eric Sandeen, Eric Sandeen, Christoph Hellwig; +Cc: linux-xfs
On 3/12/20 9:32 AM, Eric Sandeen wrote:
> On 3/12/20 11:17 AM, Allison Collins wrote:
>> I've often wondered how one person manages to keep up with that! :-)
>
> It seems that the answer is "badly" ;)
>
> (TBH Darrick is a huge help here, in the long run.)
>
> -Eric
>
:-) Wouldnt it make it easier though if people pushed a corresponding
"xfsprogs: set name" that's already been applied/compiled and
(hopefully) tested? That way when the user space side needs updating,
patches can just be applied without one person having to work through
all the ports? And then people could sort of cherry pick what they need
off the list while the user space side is still between cycles. I
realize this would generate a lot more traffic on the mailing list, but
it seems like a reasonable way that people could help address this
bottle neck.
I think I must have redone the userspace side of the delayed attr series
over a dozen times, and there's a few patches that are not perfect
mirrors of their kernel space counter parts. Because some changes
affect code not present in the kernel space side, now all that needs
updating too for the set as a whole to really work. It kinda seems like
submitting just the kernel space side is still only half the set. Not
sure how many other people run into that, but I suspect I'm likely not
the first?
Allison
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfsprogs process question
2020-03-12 15:46 ` Eric Sandeen
2020-03-12 16:17 ` Allison Collins
@ 2020-03-13 6:54 ` Christoph Hellwig
1 sibling, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2020-03-13 6:54 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Christoph Hellwig, linux-xfs
On Thu, Mar 12, 2020 at 10:46:47AM -0500, Eric Sandeen wrote:
> Would it help to open a libxfs-sync-$VERSION branch as soon as the kernel
> starts on a new version?
Yes. I'd just call it for-next, but the name is the least of our
problems :)
> I've never quite understood what the common expectation for a "for-next"
> branch behavior is, though I recognize that my use of it right now is a bit
> unconventional.
Іt really is just a kernel convention due to linux-next. And I'd just
name the xfsprogs branch to match. But as said above, the name isn't
really what matters.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-13 6:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-12 14:13 xfsprogs process question Christoph Hellwig
2020-03-12 15:46 ` Eric Sandeen
2020-03-12 16:17 ` Allison Collins
2020-03-12 16:32 ` Eric Sandeen
2020-03-12 17:33 ` Allison Collins
2020-03-13 6:54 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox