Orphaning packages

Since I am expected to spend more than half my packaging time updating the debian/copyright file, I am hereby orphaning nspr, nss, iceape and xulrunner. I am also stopping work on webkit and iceweasel, but they don’t end up in the orphan state since they are comaintained.

Good luck to my fellow developpers. (And sorry, sincerely)

Update: As I do realize writing while being pissed doesn’t help making the motives right, and apparently, some people have seen this as an extortion, let me make things clearer:

I was starting to work on xulrunner 1.9.1 when the discussion about the copyright files came up. It will require a significant amount of time, and while Noah Slater’s opinion alone wouldn’t really have carried me that far, despite me saying so because I got pissed by his words, 2 messages from Jörg Jaspert (the only ones he posted so far in the thread, by the way) did make it clear that my work on xulrunner 1.9.1 was going to be a waste of time, which I already lack to properly handle the bugs in my maintained packages, let alone keeping the copyright file up-to-date.

As I am obviously unable to handle the amount of work required to maintain big packages, as drawing new blood in the mozilla team has always failed so far, I just prefer to stop than to over-overflow. Call it extortion to get people in the mozilla team if you want, I’m fine with the notion.

I’ve been thinking to stop working on big packages for nearly a year already, but never mentionned it but to a few people in a few occasions. I couldn’t resolve myself to do it, though I did reduce the amount of time I spend on these packages (I was overflown, a year ago). I just found an excuse to actually do it.

I must say I feel awkward now, and I still don’t know if I will be able to keep this resolution.

As for the new copyright file format, with full licensing information and copyright holders list, I *did* try, on a significantly smaller piece of software than the mozilla packages, namely on Webkit, which is not really small either but still 6 times less files than xulrunner. I must say I hate to have to list copyright holders and file names with a passion, and the amount of time it takes. It is the main reason why there wasn’t more uploads of WebKit svn snapshots in the archive…

Last but not least, thanks for the nice comments.

2009-03-21 18:54:03+0200

firefox, iceape, webkit, xulrunner

Both comments and pings are currently closed.

16 Responses to “Orphaning packages”

  1. AF Says:

    omg

  2. Michael Says:

    Come on, please don’t let you piss off by some morons. Your work is very appreciated.

  3. Sandro Tosi Says:

    Hi Glandium, I already expressed my feelings publicly on -devel, and I reinforce them here: I understand your feelings now, but you maintain those packages very well, and Debian users/maintainers basis will be heavily affected by your decision.

    Sincerly,
    Sandro

  4. btmorex Says:

    Another victory for the Debian copyright police! (sarcasm)

    I’m pretty sad that you won’t be maintaining those packages anymore. xulrunner is one of the few packages where a bug I logged has actually been investigated and fixed in a timely manner.

    I wonder if Debian will eventually end up as a bunch of wannabe-lawyers after they’ve scared a way anyone who actually does useful work.

  5. Russ Allbery Says:

    Could you please just sit on this for at least the weekend? We haven’t even started talking about this yet, or about what the underlying requirements are. Several of those of us in the discussion at first glance agree with you. We haven’t had a chance to even TRY to work out a mutually-acceptable policy.

    Please, if at all possible, take a deep breath, walk away from it for a while, and see if sanity has reasserted itself before you come back. I realize that some people have been fighting this issue for a while, but this is the first that I’d personally heard of it, and the debian-devel discussion still has a substantial possibility to be constructive.

    If we can’t reach some constructive solution, then that’s the time to make major changes around your time commitments, but I truly don’t believe we’re at that point yet.

  6. Emilio Pozuelo Monfort Says:

    I’m sorry we got to this point.

    Thank you for all the time and effort you have put into these packages in the past

  7. Riku Voipio Says:

    Or you could just stop maintaining the copyright files from the packages. “These files are orphaned, I choose to use my own time elsewhere. If you care about these files, please join mozilla team and adopt these files”.

    Let the noisy copyright-annotation -people do them self the things they feel important to be done…

  8. Anonymous Says:

    Very sorry to hear that you don’t plan to continue working on these packages. You’ve done great work with them.

    I realize that maintaining large complex packages like those from Mozilla does involve a lot of non-technical work like this. If some particular discussion led you to this frustrated result, would you mind pointing at the discussion for the benefit of others?

  9. Karellen Says:

    Bummer.

    I’m not aware of the current kerfuffle, but thanks for all the work you put in over the years, particularly on the Firefox/Iceweasel naming controversy with the assha^H^H^H^H^Hdevelopers at Mozilla.

  10. Ben Finney Says:

    > Since I am expected to spend more than half my packaging time updating the debian/copyright file

    Huh? There is an ongoing *discussion* about what is expected.

    Perhaps you could wait to see what you’re expected to do differently, if anything, before orphaning your packages?

  11. TL Says:

    Yeah, maybe you could just stop maintaining the copyright holder list in the debian/copyright file. Those who feel it’s an important bug should fix it themselves and send patches.

  12. machiner Says:

    Aren’t these significant packages? Won’t we advocates and users of Debian’s fine work be effected by this decision, and any and all new/required issues surrounding it?

    If it’s a compliance issue then adherence should be allowed. What I mean is, you don’t give a job to someone without also furnishing the necessary tools and support to enable the job’s completion. Right?

    Forgive me, I’m coming into this discussion late and from left-field, as one of those advocate end-users. But reading what I have here this morning prompted a bit of concern.

    Thanks,

    machiner

  13. Ben Finney Says:

    > As for the new copyright file format, with full licensing information and copyright holders list

    No. This meme needs to be suppressed with extreme prejudice.

    The proposed machine-readable ‘debian/copyright’ format does *not* mandate “full licensing information and copyright holders list”. It mandates *only* a format to put the information in. Moreover, the proposed format is still a draft and has many acknowledged flaws; it has precisely zero effect on any requirements so far.

    If there is a requirement to include any information in the ‘debian/copyright’ file, it does *not* come from the proposed machine-readable format.

  14. glandium Says:

    Ben, the copyright format draft doesn’t explicitely mandate that, sure, but it doesn’t make it explicit either that the information can be left out. But, reading the draft, you get the impression you can’t leave them out. Only nitpicking about the actual fact that there is no “mandatory” on the fields in question (there is no “optional” either) can make you say it doesn’t mandate.

  15. Anonymous Says:

    For the record: I very much like that Debian mandates copying *license terms* into debian/copyright, making it possible to find them in a uniform place across packages. However, I see precisely zero value in copying any list of authors or copyright holders.

  16. bugsbunny Says:

    license terms makes sense, I think. Or at least a pointer to where the license is within the installed files (if it’s located elsewhere). As far as a list of the copyright holders – if upstream provides such a list then a simple copy/paste, or pointer to a file containing the information should (IMO) be sufficient.

    If upstream chooses not to provide that information then I don’t think a developer should have to spend time tracking it down. I agree with those that say if someone doesn’t like it they can do the work and provide a patch.

    Now to go check out the development list and see what’s actually going on. :)