Bug#635504: ITP: flashcache -- write back block device cache for Linux
-----BEGIN PGP SIGNED MESSAGE-----
On 20.09.2011 03:54, onlyjob wrote:
> Well, even if this functionality might be nice to have, it is not
> required and it is not in upstream.
So? Have a look to other packages. Most provide convenience wrapper,
patches and additions if upstream's cruft is not usable enough. Many of
those additions ultimately are being pushed to upstream and often merged
for successive releases.
Remember: A Debian package targets a large user base, not your
specialized use case only. Hence it must provide the greatest possible
convenience and flexibility.
> For example cryptsetup package (which is also managing device mapper
> pass-through devices) do not have this functionality.
crypttab(5). Read it.
> This functionality arguably may be considered a separate job, which
> might be packaged separately.
Not in Debian. In Debian we treat all packages as first class citizen,
and especially for new packages we try to introduce only well shaped,
> OK, I'd like to get the better understanding of what's the problem here.
> Am I expected to file a duplicate ITP if I already have a solution?
No, per package only one WNPP bug exists.
You are expected to contact the maintainer or WNPP bug owner to learn
about possibilities to contribute.
> Do we allow competition in Debian,
> or does whoever filed ITP first, get a monopoly over packaging?
Debian allows competition in a sense that several technical solutions
for one problem may coexist with each other. For example, more than one
web server is packaged in Debian.
There is no competition among packagers itself. I do not compete with
you for making a better package than you do. We either do that together,
or the person who came first does.
Even for NMUs (Non Maintainer Uploads) you are not supposed to hijack
packages, but to fix a very specific problem in a minimal invasive way.
Moreover, such NMUs typically are announced and uploaded with 7+ days
delay to let the regular maintainer step in if he wants to.
> At least anyone is free to fix someone else's bugs even though someone
> might be already working on it.
Typically one announces publicly if one is working on a particular bug
of a foreign package. After all a bug fix is something completely
different than hijacking a package. Moreover, no maintainer will reject
patches if they are of good quality. That would be silly.
> Visibility of your progress is questionable since in the ITP had no
> information about location of your effort
> or the progress you've made.
You could have asked, just like you did two days ago. You see, you can
reach me that way.
> I'm not sure if I should care about finding a sponsor - if you have
> one, your work will get a better chance to be included when you
As I said, you will have a hard time finding a sponsor, once (if) he
realizes you try to rule out someone else by your upload. I won't hinder
you to try it - not I could after all.
> Meanwhile my package make sense.
You are free to use it.
You are free to announce it wherever you want.
You are free to advertise it.
I am just pointing out, the way you are trying to introduce your package
to Debian is somewhat impolite and discouraged among members of the
Oh, and by the way: We target unstable/Sid for new packages. That
distribution is not at all intended to be used by users. Our users are
expected to run Debian Stable - currently Squeeze - which will never see
a flashcache package. Neither mine nor yours.
> I'm not sure what's the meaning of hijacking in this context.
> I made all the work by my own independently.
By hijacking I mean you are trying to take over to maintain a certain
package which is under active maintenance by someone else (being
effectively available to end users or not, does not matter here).
> I see no drama if one of us will not be maintainer for flashcache
> package - there are plenty of other opportunities to contribute.
Agreed. Yet I came first with the idea to package flashcache. :>
> What I don't understand is what exactly your offer is.
> You're already free to take whatever you need for your package from
> mine - my understanding is that you don't even need permission for it.
Right. I can, exactly like you are allowed to take my changes for your
package. As I said, that's not my intention though. If I see interest by
someone else to do hard packaging work, why should I reject that
opportunity? There are many packages in Debian which desperately seek
help, why should I reject such an offer?
Obviously a package can be maintained by more than one individual, a
co-maintainer is pretty much what the name suggests: Two persons equally
responsible for a single package. Both of us will get bug reports, both
of us are allowed to commit to our repository, both of us are
responsible to fix bugs and, - if this is what you are worried about -
you are equally credited for your work.
> This is probably because I desperately need working package.
> Would teaming with you would require for me to work on both packages
> until you will be ready to release yours?
For a transitional period probably yes. Especially since I am truly
hoping you are not using Sid on your productive machines.
> Probably yes and I'm not sure if I want it or understand why it is
> worth it.
If you don't see any benefit in working together with someone else for
the same goal, you shouldn't do it then.
> I believe I did little wrong by doing work on the package and I refuse
> to feel guilty about it.
I don't blame you for your package, but I think I made that clear.
> But at this point I think someone else (a Debian Developer) should
> tell us who should merge with who according to our work and not
> according to who logged an ITP first.
I believe, any developer will tell you the same I do. However, feel free
to raise your question to a wider audience, e.g. by asking on
debian-devel or debian-mentors.
> We need to release something now, and I believe I'm a little bit ahead
> of you in that regards (quite accidentally though).
Once again: You can do whatever you want. You can use your own package
as well as mine eventually, but no matter what you do: It won't show up
in a stable release anytime soon.
> Please let me know of any procedures you believe we should agree on.
I don't need to convince you to join a team, if you don't want to.
(stripped some parts of your mail, where I am not in the mood to reply
with kind regards,
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----