Re: Automatically closing bugs
I agree with everything Andreas has to say. I am very lucky if I find the
time to read the current policy statements even once a year. I don't have
the time to follow policy, and beary have the time to read Joey's very
fine weekly report.
The problem seems to be that we are all in this boat, and no-one has the
time to follow all the processes going on in Debian so that an up-to-date
list of "recent" changes to the development process can be posted in a
very visible spot on the web page for developers to use to keep track.
Even just a simple outline of the development steps in a package cycle,
with the important recent changes noted clearly in this outline, would go
a long way toward keeping us all on the same page.
I know that the people "in the know" about such things, can submit bug
reports against the offending packages, quoting the pertinant portions of
policy, but this seems like a poor use of the BTS unless there is some
automatic way to submit policy changes throught the BTS that makes sense.
But, 2500 new bug reports for every policy change seems a bit ...
aggressive?
As you can see, I don't really have a solution that is very good, or that
I can provide. I would be very pleased if there were someone in the group
who follows policy, vote, discuss, (any I've forgotten), who could post
decissions arrived at on these lists in a clean way that the rest of us
could gain "tracking" knowledge from and thereby keep our individual
knowledge bases up-to-date. This probably sounds a lot like the weekly
news report that Joey does, but that's not quite what I'm looking for.
This should be a single page synopsys of general package construction that
covers all the steps a developer should take when building a Debian
package, specificly denoting the places where recent policy would require
a new or different activity on the part of the developer.
If I had access to a document like that, which was kept current with
policy, I would only need to go check over that list before doing package
work, and could then make sure that the package I'm working on is done
correctly. When a particular change happens, and I don't understand the
synopsis, there should be clear reference to the policy section or other
documentation so that I can go read that for more information.
I don't know how many other people besides myself and Andreas have this
particular difficulty, but the person who "fixes" this will get resounding
applause from the two of us, at the very least ;-)
Waiting is,
On Thu, 24 Jun 1999, Andreas Tille wrote:
> On Wed, 23 Jun 1999, Dale Scheetz wrote:
>
> > I'm not sure how closely you conformed to the "format" for the "fixes"
> > field. My memory says that it should look like:
> >
> > * Removed foo, fixes: #19243, #18994, #45545
> >
> > You used caps on the f and left out the :, either one of which might be
> > critical...I never followed what the final decission on this format was.
> > You might also need to experiment with "fixed" over "fixes" as the tag.
> I'll try it once more with the xteddy package.
>
> > In any case, let us all know what you finally discover as the "proper" way
> > to do this.
> I'm not very experienced with such kind of things. I relay on the
> choice of experienced developers. But the real flaw is in my opinion
> that the format is not made as public as necessary.
>
> I see the situation as follows:
> * Most developers has a job to deal with and which consumes much time.
> * The debian development is done in the limited spare time to support
> the project which enables more comfort for their work.
> * It's hard to follow the changes in the packaging/development stuff.
> * I personally read the policy and development documentation from the
> state of the end of 1997.
> * I didn't have the time to read it over and over again.
> For instance when I read the documentation the suggested way to
> build a package was `sudo build`. OK, the new development tool
> says itself use `debuild` ... that's easy. Also the tool calls
> lintian automatically but lintian suggests to not to run it as
> root. How to do that when using `sudo debuild`.
> OK, that are changes, good changes and necessary changes!
> I really like them and are happy to use such a high quality
> system.
> * But I think we should have a kind of a hotline where all these
> changes are announced as short an precise as possible.
>
> For instance:
>
> dpkg now can fix bugs automatically. use
> * fixed: #<bug_no1>[, #<bug_no2> ...]
> in changelog
>
> This keeps developers up to date. Or
>
> new packaging method. use
> debuild
> instead of
> build
> and do ??? to get lintian running not as root
>
> So we have to find a way that developers can follow the line of
> the development with a minimum amount of time. I have to admit that
> I can't follow each dicussion in the mailing list about policy and
> so on. But we have to ship really necessary information.
>
> Oh yes, and the information email have to be marked with a certain
> tag to avoid that a developer deletes this mail without reading.
>
> Just my two cents.
>
> Kind regards
>
> Andreas.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: