Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can reliably change ext3 with ext4 in the GP's comment. It's not an extX problem, it's an BTRFS problem.

If nobody cares that much, maybe deprecate the tool, then?

Also, just because it's Open Source (TM) doesn't mean developers will accept any patch regardless of its quality. Like everything, FOSS is 85% people, 15% code.

> You are as empowered to fix this as anybody else, if it presents a real problem for you.

I have reported many bugs in Open Source software. If I had the time to study code and author a fix, I'd submit the patch itself, which I was able to do, a couple of times.



for me it's a problem of the tool converting in place EXT to BTRFS. Not necessarily a problem of BTRFS.


I tried to say it’s a problem of BTRFS the project. Not BTRFS the file system.


> If nobody cares that much, maybe deprecate the tool, then?

If you think that's the right thing to do, you're as free as anybody else to send documentation patches. I doubt anybody would argue with you here, but who knows :)

> Also, just because it's Open Source (TM) doesn't mean developers will accept any patch regardless of its quality.

Of course not. If you want to make a difference, you have to put in the work. It's worth it IMHO.


> If you think that's the right thing to do, you're as free as anybody else to send documentation patches :)

That won't do anything. Instead I can start a small commotion by sending a small request (to the mailing lists) to deprecate the tool, which I don't want to do. Because I'm busy. :)

Also, I don't like commotions, and prefer civilized discussions.

> Of course not. If you want to make a difference, you have to put in the work. It's worth it IMHO.

Of course. This is what I do. For example, I have a one liner in Debian Installer. I had a big patch in GDM, but after coordinating with the developers, they decided to not merge the fix + new feature, for example.


> For example, I have a one liner in Debian Installer. I had a big patch in GDM, but after coordinating with the developers, they decided to not merge the fix + new feature, for example

Surely you were given some justification as to why they didn't want to merge it? I realize sometimes these things are intractable, but in my experience that's rare... usually things can iterate towards a mutually agreeable solution.


The sad part is they didn’t.

GTK has (or had) a sliding infoline widget, which is used to show notifications. GDM used it for password related prompts. It actually relayed PAM messages to that widget.

We were doing mass installations backed by an LDAP server which had password policies, including expiration enabled.

That widget had a bug, prevented it displaying a new message when it was in the middle of an animation, which effectively ate messages related to LDAP (Your password will expire in X days, etc.).

Also we needed a keyboard selector in that window, which was absent.

I gave heads up to the GDM team, they sent a “go ahead” as a reply. I have written an elaborate patch, which they rejected and wanted a simpler one. I iterated the way they wanted, they said it passes the muster and will be merged.

Further couple of mails never answered. I’m basically ghosted.

But the merge never came, and I moved on.


This sort of thing happens all the time in big orgs which develop a single product internally with a closed source… there isn’t any fix for this part of human nature, apparently.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: