Re: new maintainer: upload to frozen?
On Wed, Dec 09, 1998 at 01:15:01AM -0800, Chris Waters wrote:
> Stephen J. Carpenter wrote:
> > On Fri, Dec 04, 1998 at 01:04:26AM -0800, Chris Waters wrote:
> > > I've taken over maintaining an already packaged program. Should I
> > > upload to frozen so that I'll be the maintainer-of-record when it
> > > becomes stable? Does the fact that I've found and fixed a very minor
> > > bug have any influence on this?
> > > I know what the developer's reference says, but [...]
> > fixing a minor bug I guess depends on what the bug is of course...and
> > how minor.
> The Debian menu entry points to the wrong location for the binary.
> Minor and easy to fix from my POV, but highly visible from the users'
Ahh definitly. That seems more than a minor bug. Shouldn't require any
new code then, juct to change a path name.
> > I would personally save the minor bug for unstable and if you really
> > feel you need to change the maintainer field...just change that and
> > re-upload with the text in the changelog reflecting that you are the
> > new maintainer and nothing else.
> There something that just seems wrong to me about fixing the version in
> unstable, so that it's more stable than the version that ends up in
> stable. Is it just me?
> Perhaps I'm just not clear on the purpose of a freeze -- what *I* want
> out of it is a version I can point to and say, basically, everything in
> there works AFAICT. Then, if I need a reliable system, I can stick
> stable on it, and if I need a hacker's workstation, I can install frozen
> or unstable. I don't want to play mix-and-match to get reliability.
> If it were me in charge of the freeze, I'd accept any bugfixes that
> clearly *were* bugfixes, and which clearly had *no* danger of
> introducing new bugs (not true of many bugfixes, granted). Which may
> mean I'm unsuitable for the post of release manager. :-)
Ok that sounds fine...however....
How minor of a change will introduce a new bug?
Ok...changing a pathname...shouldn't introduce a bug (esp if the old one is
pointing at nothing).
The whole point of the freeze is no new code unless it is absolutely needed.
It just comes down basically to "You have to draw a line somewhere" or else
it will never get releaced.
Remember there are some 1800+ packages and some 300+ (I think) maintainers
for those packages... How would you expect to thoroughly inspect every upload
tp "make sure there are no new bugs"? What will you do if the upload
is to a program which is entirely in python or TCL and you don't know that
I agree though, if a package makes the system unreliable...then it is time
to fix it. However....the majority of minor bugfixes can wait.
> > Gotta leave em something to goto unstable for ;)
> This is an attitude I confess I deplore.
Well I became a maintainer and started making uploads just after the last
freeze, so I have spent the past number of months telling people
"No really, you want the one in unstable" (much newer version...and
some nice additions).
Though...I meant that more as a joke than anything else :)
> I don't want to force people
> to go to unstable for more stable code! Not unless there's no other
> option. I want to send them to unstable for more *interesting* code!
but..."unstable" does NOT mean "less stable". It means that it changes.
"Stable" just means unchanging (in super-deep freeze).
Like I said... a line has to be drawn somewhere.
/* -- Stephen Carpenter <firstname.lastname@example.org> --- <email@example.com>------------ */
Drug War Fact:
Nearly 80% of people who had property forfeited in the United States
were never charged with a crime themselves. Forfeiture can even occur
when the owner was aquitted of the crime!