Bug#635504: ITP: flashcache -- write back block device cache for Linux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dmitry,
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,
complete packages.
> 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
> finish.
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
Debian community.
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
right now)
- --
with kind regards,
Arno Töll
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/
iQIcBAEBAgAGBQJOeLdHAAoJEMcrUe6dgPNtF5UP/iT44fG2epJimmWKrABVzF/6
XR41kxpSHe/NJcmFHAbDeDM0jZYIbGrKQF1L1w0XQFATkxbvWR8xzOhzPW22140N
iEnmaEIZVz9kjq0L5sUZX65g1R06X0XP20DSixyF07ljc8v/0wJqfQHRwdl1VklS
b9wlITSKsQajDyNnB7Mx5wFvIo2eaMnya1gjuS52jiTqpXh0S3hS6wZcQCiRKQt3
EZzIOpxow4tvBHEQVlulXwEPLyPPlUHHzh9e7N05a+fhhqiJ0W3LR3arw/M2lV5J
mqG4tF5g3LX99T3OKhLOrZ8DepIorKRissUScXwDtzFRygPwbbZylJ5Ls0tylZiX
VZhTwY5Mfbnfep8evoYT8IrycTTOU7T4eVpA0bHqG1weeLexNcXtgOxvGkzdnFOB
nkLjG73P9dil5Mg8tCWLgv12tJRPt+blxLCrWEja/mqrpdG74yskUXJVMUs14S70
wVOdPYtm2Tw3qcIV06xw/vSoGfm8eZalV1hy/sWLFLJ0Kvc3KlYsFX2qiZrzS/fz
ohFt3u7oJoxF148J7CRE5lGzHonf6a+DIm3F8JLI6DGarqZmeBimT5xbnWHjqNny
ltwYyL2T6RfekMjmQe91EIK3ub9e50yuIh9efl57kJ8k1zE2GAH8PZ3AG84dT3Db
dVg1DcZYLdOxkCumtfEF
=Byr3
-----END PGP SIGNATURE-----
Reply to: