[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: revbumps and version sharing
Date: Mon, 23 Nov 2009 14:12:11 +0100
From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
| That is supposed to happen, but sometimes a case slips through.
Yes, exactly, people make mistakes - nothing will ever stop that,
however much we might try, which is why I suggested a procedure
that (at least when implemented correctly) would avoid them - not
making all the problems go away, just some PKGREVISION issues.
| It shouldn't really hurt, the revision is still supposed to be increased
That would mean that when a "case slips through" whoever fixes it
knows that in this case (unlike most, or all, others) they're not supposed to
delete PKGREVISION after a version update.
In the case in question, anyone tracking things without PKG_DEVELOPER set
would have seen gcdmaster move from 1.2.2nb6 to 1.2.3nb6 and then down
to 1.2.3 (well, that's what anyone just observing pkgsrc would have
seen, PKG_DEVELOPER, by chance here, prevented 1.2.3nb6 binary package
being produced, if it was set.)
| There is a supposed to be a list of locations the Makefile.common or
| whatever is included from.
Where is this list supposed to be? I'm not a developer, so there's no
need for me to have access if it is somewhere private, but (at least for
cdrdao), I see nowhere that I can observe where that list exists.
Unless it is somewhere private, once again, I appreciate he difference
between "supposed to" and "someone actually did the work", and I know that
things do go wrong, or get forgotten, or ... and that it is pointless
(especially in a volunteer project) to attempt to attribute blame for
any of that.
| The Developer is supposed to handle that with care.
Good intentions ...
| IMO trying to automate this is just going to hurt in a different
| ways not yet to foreseen.
The only automate part that looks tricky, is with pkgtools/revbump - I
haven't looked at that (I have no need for it myself, obviously) to know
how easy, or hard, that might be to fix.
The rest of it looks to be painless - at the worst, if the .if/.endif
guard gets forgotten, we're no worse off than now (and of course, that
will happen) - where it is used, I can't see a downside right now.
If this was tried, and caused problems that are currently unforseen,
deleting it would be fairly easy to accomplish!
Main Index |
Thread Index |