Re: flashcache - call for resolution / seeking for a mentor
(Note: I didn't have a look at either package; I merely read the
preceding discussion in the bug log)
>From what I've read so far, my impression is that this is not a
technical issue, but more a social / team-work... misunderstanding,
perhaps.
So read my comments below, with these things in mind.
onlyjob <onlyjob@member.fsf.org> writes:
> So perhaps like many people before me I picked a software which I need
> as a matter of urgency and packaged it for Debian
> only to find unhappy maintainer who was doing similar work but
> (arguably) didn't yet made as much progress.
This is called duplication of effort, and while the ITP might not have
been kept up to date, progress was being made. How much, I will not
judge, as I'm not qualified to do so.
Nevertheless, when one wants to package something, the first thing to
do, in order to make it smooth and useful, is to see if there's anyone
working on it already, and if so, how far they've got.
This way, you don't have to start from scratch, and you're not stepping
on anyone's toes, either. If all goes well, and most often it does, one
can speed up the packaging process by joining the effort, instead of
starting a competing one.
> My bad, I should have find him and coordinate the effort but as a
> newcomer I'm lacking some understanding of how things suppose to be
> done
> and hence I missed the chance to reduce our efforts.
That happens at times, indeed. But not to worry! It's never too late to
join forces, and get the best of both efforts (preferably without the
bugs of either :P).
> At this point my package is ready for review and as I'm been told, I'm
> neither suppose to close someone else's ITP nor submit a duplicate
> one.
That is mostly correct. If there's someone already working on a package,
it's generally not recommended to "hijack" and invalidate his efforts.
The best practice is to strive for merging both works. Arno offered you
the opportunity to do so, and I believe that's the best path to follow,
regardless of what the technical state of each of your packages are.
He started the work, he filed the ITP, it's pretty much his package at
this time. And as you wouldn't want to upload a package managed by
someone else, because it happens to have a bug or shortcoming that
bothers you, the same treatment should be applied to ITPs aswell.
> No doubts in the end there should be only one package left.
Indeed.
> It is indeed possible that something can be merged between those two packages.
> (As a matter of fact, maintainer who first logged an ITP already
> integrated some pieces of my work into his unfinished package)
That's the way forward: merge the good parts from both efforts.
> By the maintainer of the unfinished package (Arno Töll) I have been
> told that my only option is to merge with him but not the other way.
Does it really matter? In the end, the result should be the same either
way: a package with the best parts of both.
The question, I believe, is more about why Arno should be doing the
merge, and not you. And the reason for that is simple: he started first.
That you might have gotten further on your own, doesn't change the fact,
that Arno was and still is working on packaging flashcache, and as such,
one's not supposed to hijack his package.
> However there are a few reasons why I don't like the idea of merging
> with unfinished package at the moment:
>
> * Because I'm using the software I packaged, I will have to
> maintain a working package until a suitable alternative will be
> available in Debian.
That's unfortunate, but if you start working with Arno, helping him in
the merging effort instead of complaining and arguing against it, it
will go much faster.
And in the future, when you wish to contribute, you look for previous,
ongoing efforts first, and try to join in, instead of going on your own,
then it will be even easier and faster.
> * Because it might be feasible to merge the other way and having
> my package a primary one. (In this case there might be less work to
> do)
Since Arno is the owner of the ITP, and by common practice, the
maintainer, it's his decision.
> * Because I'm using fossil http://fossil-scm.org/ (git may be an
> overkill just for several files) and merging to git will require a
> substantial effort for me.
The other way around would require similar efforts. Arno is willing to
merge from you, and already merged a few things from your packaging that
his missed, as far as I remember the bug log.
For this reason, I support his decision to merge your packaging into
his, and not the other way around: because he proved this works, and can
bring the packaging effort forward.
> * Because it seems wrong to made a decision about who should
> merge with who merely by the ITP announcement date and not by the
> technical examination.
By that reasoning, it's not acceptable to start a competing packaging
effort, when one is already in progress, because at the time you
started, you had nothing, and Arno had visible progress.
So if we follow down this path, by your own logic, starting your
packaging was a mistake, a technical mistake, which should not have been
made. You should therefore be open and willing to merge with Arno, who,
at the beginning, had a technically more progressed effort than you did.
> And hence here are my questions:
> * Is it true that whoever happen to create an ITP first gets the
> monopoly for packaging?
Yes and no. Whoever filed the ITP, as long as he's actively working on
it, he's the de-facto maintainer of the package.
However, Arno offered you co-maintainership, and to merge both packages
into one. I do not see any monopolitic tendencies here.
> * What if he is not doing the best job?
Then you can help him do a better job. The keyword here is "help", not
"override".
> * Can we call for a resolution based on technical examination
> rather than on who submitted an ITP first?
The technical resolution, that would be best for Debian is what Arno
offered you a couple of days ago: merge the good parts from both.
> * Would it be reasonable to reject the work purely because
> another ITP is already there?
No. And noone rejects your work. Arno offered to merge in selected parts
from yours, that you both agree on. That's not a rejection, that's how
it should be done, that's the preferred way in free software: when you
find a bug, you submit a fix, and it gets merged. You do not fork the
program and try to push it down the maintainer's throat.
> * If ITP always have priority, aren't we sending a wrong message
> for ambitious maintainers who might be tempted to create ITP early in
> order
> to secure the rights for packaging, disregarding of how close
> they are to providing a usable package?
No. Team-work exists, others can help in the packaging, and you were
offered co-maintainership. There's no wrong message there. It's all very
positive from where I'm standing.
> There must be a similar situations in the past so it will be nice to
> know about resolution.
>From the few similar cases I observed in the past, people who did
independent packaging usually ended up merging their efforts, one way or
the other.
> It would also be nice to have a quick unbiased comparison between mine
> and Arno's work.
I'll see if I can do that (unless, of course, someone comes along
meanwhile and does it better than I would).
Do note that I'll ruthlessly pick both packages to tiny bits and
critique them hard. Nothing personal, I'm just a grumpy old guy who
likes to do that. >;]
> (I don't have any understanding of co-maintainer's rights and duties
> yet.)
A co-maintainer is someone who maintains a package together with
others. Same rights, same responsibilities, same duties.
Having a co-maintainer, someone to maintain a package with is great, and
very, very useful. For any non-trivial package (and I believe flashcache
falls into that category), team maintainance should be the default.
--
|8]
Reply to: