Re: Bug reports, patches and other stuff
On Sep 10, Bdale Garbee wrote:
>
> I really don't understand this sentiment. Signing up as a developer is easy.
Hmm... Nowadays it requires either a presence of a Debian developer who
can certify the PGP key, or getting the key certified by an official
agency, or at least finding a way to scan the ID card (although it is
almost useless in terms of prooving real life identity). It is much
more complicated procedure than fixing bugs. (However, it's still a bit
easier than contributing to FSF. :-) )
> There have been times when the person processing new maintainer requests
> introduced a delay due to being too busy on other things, but I've never had
> any trouble helping someone who thinks it's taking too long find the right
> person to ask to get it done. What is the big problem here?
People expect to find Alpha packages on master and not in some other
place exactly the same way as potential developers expect to get
registered at new-maintainer@debian.org and nowhere else. But, anyway,
it's not a big problem, not much bigger than packages appearing on
private ftp sites outside Debian.
(Though, speaking from personal experience and from debian-devel postings
asking whether new-maintainer is alive or not, I doubt that there is a
single developer who got registered just by writing to
new-maintainer@debian.org...) :-(
The big problem is master itself, rejecting uploads that do not contain
proper .orig.tar.gz and .diff.gz files. However, this behaviour is
perfectly correct, as we don't want any discrepancies between the source
and the binary. So, the next thing to blame is the Debian source
package format. If there were at least architecture-specific .diff
files, life would be much easier. They are ugly, they are hacks, but
some packages really need such approach, unless we want to introduce
them as completely new packages, which is not a bloody good solution
either.
The main point about architecture-specific .diff files is that they will
eventually go away. Unfortunately, not so soon as we would like them
to. Technically, there is absolutely no problem to introduce this
enhancement to the source packaging format, it's just not quite
nice-looking and would thus be beaten to death on debian-devel.
>
> I like your technical ideas, I appreciate your work to fix some bugs and get
> an alpha-specific bug tracking mechanism together (though personally, I'd
> rather motivate the maintainers of the primary Debian bug tracking system to
> make whatever changes might be needed to handle architecture-specific bugs in
> a better way),
Sure the bugs which can be fixed by modifying the source package in a
way that does not break its functionality on the other architectures
must be reported straight to the primary maintainers. Together with the
patch. But, before the patch is ready, it is nice to have the bug
registered somewhere. The Alpha port has lots of bugs at the moment,
they have to be recorded in order not to be forgotten and re-discovered
again... Well, if there was a pseudopackage "alpha-port" in the bug
tracking system, it could likely serve this purpose.
>
> I've been tempted several times to just snag the best of everything from the
> various FTP sites and put it all on master. New folks looking to try Debian
> alpha are going to pull the bits from the mirrors like ftp.debian.org, and if
> what they find doesn't work, they're going to go away and run something else.
I completely agree. The problem is that significant part of the Alpha
port is done by people who aren't Debian developers and probably do not
strongly intend to become. They just want to set their systems up and
running. They build and fix packages for themselves. These people also
publish what they've done for others to use. Then it is up to the
Debian Project to accept or reject these contributions. Debian rejects.
That's how things work.
Of course, I would be extremely glad to see all the good stuff on
ftp.debian.org. What I was proposing was just an attempt to do
something real. I can't say "hey, let's upload everything to master".
It won't work. I prefer to do things that work.
> We really must figure out how to always have our best-effort bits in "the
> usual place" if we're going to build a critical mass and succeed.
No doubt. I think the two greatest obstacles are:
- the absence of architecture-dependent diffs;
- the new-maintainer@debian.org address (look for example at a recent
posting to debian-devel from Eloy A. Paris who applied more than a month
ago; my own applications filed on 24 Jan and 2 Sep are unanswered as well).
How to fix them? Well, I have no idea what to do to the new-maintainer
registration procedure. As for the diffs (yes, I know, they should be
incorporated into either the main .diff.gz files or the upstream sources,
but it may be a hell lot of work at the moment; I promise they will
eventually go away and rest in peace), theoretically they are
implementable, although they must be discussed and approved, first in
debian-alpha, then in (oh my God, I can imagine this!) debian-devel.
I won't be able to fight for them in debian-devel. I'm not a developer.
Neither do I want to spend enormous amounts of time on word wars.
That's how I see the solution. I've done what I could have. Everybody
who can either help implementing this solution or propose his/her own is
very welcome.
Finally, I would like to thank Bdale for his criticism, hopefully this
discussion (which turns out to be constructive, unlike most of the
discussions in debian-devel) can lead us to a working Alpha port. Actually
what I expected to be berated for were technical details like kernel
patches, switching to hwclock, etc... Maybe because I often treat
organisational stuff as unimportant. Just something to let the technical
group move on. Heh.
Nikita
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: