On Mon, Apr 07, 2008 at 11:20:10PM +0200, Joerg Jaspert wrote:
> On 11348 March 1977, Christoph Haas wrote:
> > The focus of mentors.debian.net is to host source packages that are
> > supposed to be sponsored. So it's not some weird multiverse non-free
> > binary warez repository or something. That doesn't ensure that some
> > packages being uploaded can't be redistributed of course. But the same
> > might happen with packages uploaded to ftp-master to be checked by the
> > FTP team.
> Thats the reason why NEW packages aren't visible to anyone except
> ftpteam members.
Do you fear legal problems? Those packages are not officially available
or endorsed by Debian. And since we threw away the uploaded binary
packages on mentors.debian.net I haven't heard of anyone downloading
those packages for their personal end-user use. I know that the binary
packages were downloaded happily back then and users complained about
the package quality. That made us think and so binary packages were not
available any more. Fortunately most end-uses are not capable of
building a binary package from a source package.
> >> Are you hardcoded to your solution? I wouldn't have a problem if we go
> >> and merge this into dak.ganneff.de
> > Honestly dak scares me a lot.
> Its pretty simple.
Then it must have changed a lot in the last years. Especially in terms
of documentation. I'm willing to give it another look then.
> dak is simple. Really.
> Also, you wouldnt have to do the setup.
I would have to deal with the setup for sure because it's the backend
for the software we are running on. The repository structure on
mentors.debian.net is accompanied by an SQL database contaning the meta
information for example (although that's of course a matter of concept
and not hewn in stone). Members can remove their own packages and
comment on them for example. This is likely just not the focus of dak.
> Well. I don't think you will get onto a debian.org machine in the near
> (or distant) future. I offer you a way out, but it needs dak.
I understand well that you prefer to join forces instead of re-inventing
the wheel. But the repository handling code at mentors.debian.net is
just a few KB of code. And since the "python-debian" package is around
we can even drop half of that (back then there was no existing code in
Python to parse control files for example). I assume that dak has more
sophisticated features to deal with multiple distributions, different
queues, override files etc. Thinking of mentors.debian.net we have one
distribution, no (or one) queues, no override files but a sophisticated
database and web system. The focus of mentors.debian.net is not
background processing of package uploads like but giving uploaders
control about their packages once they are uploaded. Discussion,
commenting, rating, automated QA checks etc. Implementing a few features
into dak might be a nice idea but it's a totally different beast IMHO.
I don't refuse to get my hands dirty with dak. But the way you put it
sounds like "screw your plans and enhance dak or good bye dot org". Bear
with me but that sounds like it will stay dot net for while. I don't
mind keeping the service running as dot net if it doesn't fit on dot org
> Now, what does mentors do that dak doesnt? It might be interesting to
> get that into dak too.
The sum of what is already implemented and what is intended for the
'debexpo' software is documented at the Summer-of-Code proposal page 
and the wiki page describing the result of the discussion on this list
some time ago . There is REVU and the PPAs and according to the
discussion with many people there are prospects for a "simple" but
comfortable and capable/pluggable software to publish packages on the
web. Be it source and/or binary packages. Be it with or without
automated QA checks. I would agree happily if we had a 90% intersection
in dak and debexpo. But I fail to see that. Both just carry the
firstname.lastname@example.org www.workaround.org JID: email@example.com
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org