Re: Proposal for collaborative maintenance of packages
> (...)
> I wasn't addressing your point specifically. Instead, I'm raising
> another one. The whole Debian system is a serious pain and an
> impediment to cooperation. Ubuntu is not much better.
>
> I should not have to be a DD to commit to
> the archive -- ANYONE should be able to commit perhaps with
> some minimal registration requirements.
>
> This is how Wikipedia works and why it is successful. With minimal
> fuss I have contributed some comments and a couple of changes.
>
> Yet with Debian I spent 6 YEARS developing some software,
> it took me a month to figure out how to build the Debian
> packaging .. I found a DD who is willing to not only act
> as maintainer but actually joined the upstream project --
> but he is very busy and there is a huge delay in upstream
> changes propagating into Debian. There is no way I can
> even think about fixing any bugs because of this. The package
> is in Unstable and it is already two versions out of date.
> I use Ubuntu .. by the time I can actually try it out on my
> own system it will be so out of date I won't even remember
> how that version works ;(
There is no serious pain in how Debian and Ubuntu are handling their
packages, IMHO. The wikipedia style of colaboration just don't work when
you need to prepare a package from scratch (as you address below).
That's good, you cited a real world problem above with the deb packages
of your software. If the package for your software is outdated you
("upstream") or any user, should file a bug (severity: wishlist) against
the package through our "bug tracking system" requesting for its update.
The current maintainer simple don't have enough time to update it ? If
it's important to the users to upgrade to that new version, they will
(and they usually do) add more requests on that bug report. You
("upstream") can request that the package maintainer ask for help in
Debian, we call them "co-maintainers" (developers too) and the ultimate
solution is create a group into alioth.debian.org to share the workload.
Yes, non-DDs can participate in alioth.d.o projects. If the users just
don't care about your software and the maintainer has no time to update,
it will end with what we call a "release critical" bug and it will not
be into our next release, being removed from the archives right after.
Maybe what we really need is better documentation about the best
practices between you (as upstream) and the project itself. Did you know
about alioth and all that ?
> (...)
>
> BUT .. the entry level is way too high. ANYONE should be able
> to commit to an entry level repository. Then it should be
> submitted by ANYONE for inspection by an automated process.
> If it passes that it goes to the next level, where a DD has
> to sign it to promote it to the next level: a panel should
> meet regularly to do this, and any package passed over
> more than three times in a row needs a published explanation
> as to why the automated processes wasn't adequate -- its a
> sign of a failure in the process NOT in the package.
What about debian-mentors, debian sponsors, and MOTU reviewers ?
> What I'm saying is the process is far too plagued by
> administrative requirements at the entry level for the
> people who actually develop the *software* to contribute --
> even if they'd like to. And it is vastly too much of
> an "old boys network" to join the team.
I disagree, mainly because i started reading the oficial documentation
at www.debian.org/doc/ when i was 16 years old. I think you don't want
to learn how to prepare deb packages taking care about all the QA
issues, with that in mind i believe that the best approach is what we
are doing right now and that i explained above. It is just the way we
publish, and the content of all the related information that could be wrong.
> Ubuntu did try to address this but it is still a joke:
> they're crying for MOTU's but when you have a look at the
> crap you have to go through to maintain a Universe package
> you're interested in you can see why there aren't enough.
I don't believe that they're raising the bar in terms of package quality.
> (...)
>
> So please don't talk about mailing patches. That's a joke.
> It works for fixing three line bugs -- it has no hope of
> ever supporting systematic changes. The only way for that
> to be possible is to work directly on the repository --
> one needs to commit regularly, and have others review changes,
> and the feedback cycle needs to be as tight as possible --
> especially when people are all around the world working at
> different times and have limited opportunities to get
> online together.
You really missed my point there, since it isn't the focus of your
previous message i prefer to move along here.
> BTW: I know of dozens of pieces of fine software that SHOULD
> be in Debian. Many were developed by academics who don't have
> the time or energy to go thru the pain required to get their
> stuff into Debian. Ville Laurikari's regex package is an example:
> it is a Posix compliant package which is generally superior
> to others: he's one of the leaders in the field, it was his
> PhD topic. In other cases .. people have actually developed
> Debian and Ubuntu packages .. but never contributed them
> because they're UPSTREAM developers with an interest in their
> own software, they're willing to support Debian and probably
> desire Debian's support for their package .. but the impediments
> to contributing to the archive are just too great to bother.
Have you heard about WNPP (www.debian.org/devel/wnpp) ? Do they filed
bugs requesting package preparation ? We can't keep high quality and let
anyone with a good piece of software but no caring about Debian
packages, package your stuff and upload it. By the way, we are doing
that as you requested above - not directly to the Debian archive itself
but for people review before.
> (...)
> EG: My comp is on the net sometimes and sitting here idle.
> I'd be happy if Debian used it occasionally to build binaries.
> Where is the web page telling me how to advise Debian autobuilder
> how to access my comp??
What about the security of this procedure ? It is in fact a good idea
but not easy to implement as it sounds.
Reply to: