<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* Simon Huggins <<a href="mailto:huggie@earth.li">huggie@earth.li</a>>, [2005-12-20 17:41 +0000]:
<br>> On Tue, Dec 20, 2005 at 02:44:31PM +0200, Jani Monoses wrote:<br>> > This may not be practical because of the time a package needs to be<br>> > tested before being considered ready for upload, but we should still
<br>> > strive for upload 'early and often' IMHO, for avoiding bottlenecks and<br>> > the introduction of unrelated changes in a revision which<br>> > theoretically make bug hunting harder.<br>><br>
> I find this argument specious - it's all in SVN so if we want to we can<br>> work out exactly what caused the introduction of a bug.</blockquote><div><br>I have just written define:specious in google. Hmm :)<br>
</div>We may be able to work out the bug eventually using svn, but if a user says X.Y-1 worked<br>X.Y-2 did not then the chances to see the bug increase as the delta between 1 and 2 is smaller.<br>In the other case you may have to start posting diffs (parts of the changes between 1 and 2)
<br>to the user and work it out in a probably longer time interval.<br><br>I do not know how much load the debian buildd-s are under, so I cannot call your argument specious :)<br>But it seems to be the bad tradeoff - precious developer and user time traded against automatic machine resources.
<br><br>Maybe some set of rules should be worked out:<br>upload if there's a new revision and at least week has passed or something like that. That would make the buildd be subjected to no more than number of xfce packages per week. Plus other urgent stuff.
<br>As for reviever time I agree that is more of an issue but some changes (like the recent lintian fixes ) are no-brainers and require no extra testing.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yep, I agree. Moreover, an 'upload early and often' strategy requires<br>efforts and a lot of spare time, with the bad side effect that the more<br>you upload, the more you may introduce new bugs (not to mention<br>buildds resources and so on).
</blockquote><div><br>How do you introduce more bugs the more you upload? You mean the chances of SNAFU increase?<br>that is valid but I suppose you do not mean bugs in the package or the code?<br>The more you upload the more it gets tested, some packages are pending upload for months in svn.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > In the cases when an upload is not made in time and another commiter
<br>> > has changes to the package I think the layout of the changelog would<br>> > be better if it was a stricter format, so instead of what is above we<br>> > had:<br>> > *blah1 (Simon Huggins)
<br>> > *blah2 (Emanuele Rocca)<br>> > ...<br>> > *blahn (Simon Huggins)<br>> > so they are added chronologically (as the changelogs themselves) not<br>> > per author.<br>><br>> I really don't like this. I much prefer the two original formats I
<br>> suggested.<br><br>I prefeer them as well, and they're also used by other big project<br>(apache, for instance). Not that we should do what others do, but<br>in these situations I like to follow the "de-facto standards".
</blockquote><div><br>I am ok with the original changelog as long as the first entry can be written 'classicaly'<br>Then if another change is done *by another devel * the onus is on him to prettify the changelog.<br><br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > this would make automatic handling a lot easier (I am now sedding<br>> > across the files, and adding Bump Version to
3.6.2 (Jani Monoses) to<br>> > 23 files would be way easier if the format wasn't hierarchical and<br>> > the corresponding header didn't have to be looked up.<br>><br>> Automatic handling isn't a big issue. Sure you've had to change 23
<br>> changelogs and it's a bit of a pain but someone has to then upload 23<br>> packages and inspect and check them all which is more pain :)</blockquote><div><br>But easing my pain does not make your bigger in this case so...it's not like
<br>'I have tedious work to do, why can't you be a man and take some too' ;) ?<br></div>In this case changelog format and the upload frequency are orthogonal<br>so what you said is really not an argument against my proposed format.
<br><br>Tedious work is the one that gets postponed and avoided the most in my experience.<br></div><br><br>Jani<br>