[Pkg-xfce-devel] README: Proposal for unreleased packages/changelog entries

Jani Monoses jani.monoses at gmail.com
Tue Dec 20 18:38:26 UTC 2005


>
> * Simon Huggins <huggie at earth.li>, [2005-12-20 17:41 +0000]:
> >  On Tue, Dec 20, 2005 at 02:44:31PM +0200, Jani Monoses wrote:
> >  > This may not be practical because of the time a package needs to be
> >  > tested before being considered ready for upload, but we should still
> >  > strive for upload 'early and often' IMHO, for avoiding bottlenecks
> and
> >  > the introduction of unrelated changes in a revision which
> >  > theoretically make bug hunting harder.
> >
> >  I find this argument specious - it's all in SVN so if we want to we can
> >  work out exactly what caused the introduction of a bug.


I have just written define:specious in google. Hmm :)
We may  be able to work out the bug eventually using svn, but if a user says
X.Y-1 worked
X.Y-2 did not then the chances to see the bug increase as the delta between
1 and 2 is smaller.
In the other case you may have to start posting diffs (parts of the changes
between 1 and 2)
to the user and work it out in a probably longer time interval.

I do not know how much load the debian buildd-s are under, so I cannot call
your argument specious :)
But it seems to be the bad tradeoff - precious developer and user time
traded against automatic machine resources.

Maybe some set of rules should be worked out:
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.
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.

Yep, I agree. Moreover, an 'upload early and often' strategy requires
> efforts and a lot of spare time, with the bad side effect that the more
> you upload, the more you may introduce new bugs (not to mention
> buildds resources and so on).


How do you introduce more bugs the more you upload? You mean the chances
of   SNAFU increase?
that is valid but I suppose you do not mean bugs in the package or the code?
The more you upload the more it gets tested, some packages are pending
upload for months in svn.


>  > In the cases when an upload is not made in time and another commiter
> >  > has changes to the package I think the layout of the changelog would
> >  > be better if it was a stricter format, so instead of what is above we
> >  > had:
> >  >  *blah1 (Simon Huggins)
> >  >  *blah2 (Emanuele Rocca)
> >  >  ...
> >  >  *blahn (Simon Huggins)
> >  > so they are added chronologically (as the changelogs themselves) not
> >  > per author.
> >
> >  I really don't like this.  I much prefer the two original formats I
> >  suggested.
>
> I prefeer them as well, and they're also used by other big project
> (apache, for instance). Not that we should do what others do, but
> in these situations I like to follow the "de-facto standards".


I am ok with the original changelog as long as the first  entry  can be
written  'classicaly'
Then if another change is done *by another devel * the onus is on him to
prettify the changelog.


>  > this would make automatic handling a lot easier (I am now sedding
> >  > across the files, and adding Bump Version to 3.6.2 (Jani Monoses) to
> >  > 23 files  would be way easier if the format wasn't hierarchical and
> >  > the corresponding header didn't have to be looked up.
> >
> >  Automatic handling isn't a big issue.  Sure you've had to change 23
> >  changelogs and it's a bit of a pain but someone has to then upload 23
> >  packages and inspect and check them all which is more pain :)


But easing my pain does not make your bigger in this case so...it's not like
'I  have tedious work to do, why can't you be a man and take some too' ;) ?
In this case changelog format and the upload frequency are orthogonal
so what you said is really not an argument against my proposed format.

Tedious work is the one that gets postponed and avoided the most in my
experience.


Jani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20051220/f6bc7f19/attachment-0001.htm


More information about the Pkg-xfce-devel mailing list