dspam-commit Mailing List for DSPAM (Page 3)
Brought to you by:
paulcockings,
sbajic
Menu
▾
▴
dspam-commit — Code Commit Notices for Auto QA/RE
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(59) |
Jun
(59) |
Jul
(24) |
Aug
(42) |
Sep
(7) |
Oct
(44) |
Nov
(28) |
Dec
(58) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(27) |
Feb
(5) |
Mar
(6) |
Apr
(33) |
May
(19) |
Jun
(4) |
Jul
(10) |
Aug
(27) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(6) |
Jun
(8) |
Jul
(24) |
Aug
(34) |
Sep
(4) |
Oct
(3) |
Nov
(13) |
Dec
(2) |
| 2012 |
Jan
|
Feb
(5) |
Mar
|
Apr
(12) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tom H. <why...@us...> - 2011-08-22 21:43:15
|
- Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: CHANGELOG | 10 ++ README | 66 +++++----- contrib/Makefile.am | 3 + .../dspam-retrain-forward.pl | 5 +- contrib/plugins/thunderbird/install.rdf | 2 +- doc/postfix.txt | 4 +- doc/relay.txt | 16 ++-- m4/.gitignore | 7 + src/dspam.conf.in | 16 ++-- src/tools.pgsql_drv/.gitignore | 2 + src/tools/dspam_notify.in | 6 +- txt/firstrun.txt | 10 +- txt/firstspam.txt | 8 +- txt/quarantinefull.txt | 8 +- webui/cgi-bin/admin.cgi | 1 - webui/cgi-bin/configure.pl.in | 2 +- webui/cgi-bin/dspam.cgi | 11 +-- webui/cgi-bin/subadmins | 6 +- webui/cgi-bin/templates/fr/nav_admin_error.html | 4 +- .../templates/fr/nav_admin_preferences.html | 11 +- webui/cgi-bin/templates/fr/nav_admin_status.html | 10 +- webui/cgi-bin/templates/fr/nav_admin_user.html | 4 +- webui/cgi-bin/templates/fr/nav_alerts.html | 12 +- webui/cgi-bin/templates/fr/nav_analysis.html | 10 +- webui/cgi-bin/templates/fr/nav_error.html | 6 +- webui/cgi-bin/templates/fr/nav_fragment.html | 14 ++- webui/cgi-bin/templates/fr/nav_history.html | 10 +- webui/cgi-bin/templates/fr/nav_performance.html | 8 +- webui/cgi-bin/templates/fr/nav_preferences.html | 11 +- webui/cgi-bin/templates/fr/nav_quarantine.html | 8 +- webui/cgi-bin/templates/fr/nav_viewmessage.html | 6 +- webui/cgi-bin/templates/fr/strings.pl | 124 ++++++++++---------- webui/cgi-bin/templates/nav_admin_error.html | 4 +- webui/cgi-bin/templates/nav_admin_preferences.html | 4 +- webui/cgi-bin/templates/nav_admin_status.html | 8 +- webui/cgi-bin/templates/nav_admin_user.html | 4 +- webui/cgi-bin/templates/nav_alerts.html | 10 +- webui/cgi-bin/templates/nav_analysis.html | 10 +- webui/cgi-bin/templates/nav_error.html | 6 +- webui/cgi-bin/templates/nav_fragment.html | 10 +- webui/cgi-bin/templates/nav_history.html | 8 +- webui/cgi-bin/templates/nav_performance.html | 8 +- webui/cgi-bin/templates/nav_preferences.html | 8 +- webui/cgi-bin/templates/nav_quarantine.html | 8 +- webui/cgi-bin/templates/nav_viewmessage.html | 6 +- 45 files changed, 288 insertions(+), 227 deletions(-) create mode 100644 m4/.gitignore create mode 100644 src/tools.pgsql_drv/.gitignore hooks/post-receive -- dspam |
|
From: Tom H. <why...@us...> - 2011-08-22 20:47:22
|
- Log -----------------------------------------------------------------
commit 87f6b1d30c3c7a8491f7e29753de61c2c1cc34fa
Author: Tom Hendrikx <to...@wh...>
Date: Mon Aug 22 22:45:52 2011 +0200
Add dspam_alias_retrain to release tarball contents.
MFM: 0days
-----------------------------------------------------------------------
Summary of changes:
contrib/Makefile.am | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-18 20:45:21
|
- Log -----------------------------------------------------------------
commit e707c2b556699fe506b7c6770952accdd46900fb
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 18 22:44:19 2011 +0200
Added some more stuff to gitignore
-----------------------------------------------------------------------
Summary of changes:
m4/.gitignore | 7 +++++++
src/tools.pgsql_drv/.gitignore | 2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 m4/.gitignore
create mode 100644 src/tools.pgsql_drv/.gitignore
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-17 22:53:22
|
- Log -----------------------------------------------------------------
commit d0fa4834d827eaceae96312b413929253baa122c
Merge: 3949421 02e3e7a
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 18 00:52:36 2011 +0200
Merge branch 'master' of ssh://dspam.git.sourceforge.net/gitroot/dspam/dspam
commit 39494218d9ad8a08c85486d9f560a5aa63e09ce5
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 18 00:47:28 2011 +0200
Some more HTML fixes
-----------------------------------------------------------------------
Summary of changes:
webui/cgi-bin/templates/nav_fragment.html | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-17 20:46:48
|
- Log -----------------------------------------------------------------
commit 02e3e7af0fc906f3f878d1a8dace4da09c1a1125
Author: Julien Valroff <ju...@ki...>
Date: Wed Aug 17 22:44:50 2011 +0200
Added updated templates for fr translation of webui.
Bug-ID: 3055182
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 2 +
webui/cgi-bin/templates/fr/nav_admin_error.html | 4 +-
.../templates/fr/nav_admin_preferences.html | 11 +-
webui/cgi-bin/templates/fr/nav_admin_status.html | 10 +-
webui/cgi-bin/templates/fr/nav_admin_user.html | 4 +-
webui/cgi-bin/templates/fr/nav_alerts.html | 12 +-
webui/cgi-bin/templates/fr/nav_analysis.html | 10 +-
webui/cgi-bin/templates/fr/nav_error.html | 6 +-
webui/cgi-bin/templates/fr/nav_fragment.html | 14 ++-
webui/cgi-bin/templates/fr/nav_history.html | 10 +-
webui/cgi-bin/templates/fr/nav_performance.html | 8 +-
webui/cgi-bin/templates/fr/nav_preferences.html | 11 +-
webui/cgi-bin/templates/fr/nav_quarantine.html | 8 +-
webui/cgi-bin/templates/fr/nav_viewmessage.html | 6 +-
webui/cgi-bin/templates/fr/strings.pl | 124 ++++++++++----------
15 files changed, 131 insertions(+), 109 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-16 22:27:31
|
- Log -----------------------------------------------------------------
commit 82442890b84d1a421911a566bf1f821b2de57a50
Author: Tom Hendrikx <to...@wh...>
Date: Wed Aug 17 00:16:27 2011 +0200
Updated all template files in english language to validate in the w3c validator.
Some volunteers would be appreciated to port these changes to the various other language templates.
MFM: 3d
Bug-ID: 3055182
Bug-Reported-By: The Duck <du...@us...>
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 2 ++
webui/cgi-bin/dspam.cgi | 2 +-
webui/cgi-bin/templates/nav_admin_error.html | 4 +++-
webui/cgi-bin/templates/nav_admin_preferences.html | 4 +++-
webui/cgi-bin/templates/nav_admin_status.html | 8 +++++---
webui/cgi-bin/templates/nav_admin_user.html | 4 +++-
webui/cgi-bin/templates/nav_alerts.html | 10 ++++++----
webui/cgi-bin/templates/nav_analysis.html | 10 ++++++----
webui/cgi-bin/templates/nav_error.html | 6 ++++--
webui/cgi-bin/templates/nav_fragment.html | 8 +++++---
webui/cgi-bin/templates/nav_history.html | 8 +++++---
webui/cgi-bin/templates/nav_performance.html | 8 +++++---
webui/cgi-bin/templates/nav_preferences.html | 8 ++++----
webui/cgi-bin/templates/nav_quarantine.html | 8 +++++---
webui/cgi-bin/templates/nav_viewmessage.html | 6 ++++--
15 files changed, 61 insertions(+), 35 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-16 20:42:13
|
- Log -----------------------------------------------------------------
commit 9e0336ba0c46ab03e7301f51d57afb7da6e721b2
Author: Tom Hendrikx <to...@wh...>
Date: Tue Aug 16 22:32:18 2011 +0200
Updated webui to use POSIX::ctime() in stead of ctime.pl, which is marked deprecated by Perl developers.
MFM: 3d
Bug-ID: 3389943
Bug-Reported-By: Antal Kovacs <do...@us...>
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 2 ++
webui/cgi-bin/admin.cgi | 1 -
webui/cgi-bin/dspam.cgi | 7 +------
3 files changed, 3 insertions(+), 7 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-15 18:01:15
|
- Log -----------------------------------------------------------------
commit ba4dea1f8a1646a402a00023352b7b58bc24e0e6
Author: Tom Hendrikx <to...@wh...>
Date: Mon Aug 15 20:00:06 2011 +0200
Updated dspam.sf.net to full length dspam.sourceforge.net URLs
-----------------------------------------------------------------------
Summary of changes:
README | 6 +++---
contrib/plugins/thunderbird/install.rdf | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-15 17:33:43
|
- Log -----------------------------------------------------------------
commit 153afaf6d6eda1327835f4ca0f23ee8f2cb31cf4
Author: Tom Hendrikx <to...@wh...>
Date: Mon Aug 15 19:33:01 2011 +0200
more example domain cleanups
-----------------------------------------------------------------------
Summary of changes:
README | 38 +++++++++++++++++++-------------------
doc/relay.txt | 16 ++++++++--------
src/dspam.conf.in | 2 +-
src/tools/dspam_notify.in | 6 +++---
webui/cgi-bin/dspam.cgi | 2 +-
webui/cgi-bin/subadmins | 6 +++---
6 files changed, 35 insertions(+), 35 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-15 16:30:06
|
- Log -----------------------------------------------------------------
commit 6936fd44a05c706df3e06b7eea90d2bb329dbfce
Author: Tom Hendrikx <to...@wh...>
Date: Mon Aug 15 18:28:07 2011 +0200
Do not use existing domains in examples if you don't own them (especially if they're owned by stupid advertising companies)
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 2 ++
README | 22 +++++++++++-----------
doc/postfix.txt | 4 ++--
src/dspam.conf.in | 14 +++++++-------
txt/firstrun.txt | 10 +++++-----
txt/firstspam.txt | 8 ++++----
txt/quarantinefull.txt | 8 ++++----
webui/cgi-bin/configure.pl.in | 2 +-
8 files changed, 36 insertions(+), 34 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Stevan B. <sb...@us...> - 2011-08-11 20:22:57
|
- Log -----------------------------------------------------------------
commit 64cc9f25726470d17eb626031e052584dc879e36
Author: Stevan Bajic <st...@ba...>
Date: Thu Aug 11 22:21:39 2011 +0200
Adding license to dspam-retrain-forward.pl
MFM: 0 days
Bug-ID: 3390214
Bug-Reported-By: Tom Hendrikx <why...@us...>
Security: none
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 2 ++
.../dspam-retrain-forward.pl | 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-11 15:40:54
|
- Log -----------------------------------------------------------------
commit d8394cb5c704c99b8991ffbdaebb549978372531
Merge: 9fd7dc0 7af2900
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 11 17:28:59 2011 +0200
Merge branch 'RELENG_3_10' into RELENG_3_10_1
-----------------------------------------------------------------------
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-11 15:40:49
|
- Log -----------------------------------------------------------------
commit d8394cb5c704c99b8991ffbdaebb549978372531
Merge: 9fd7dc0 7af2900
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 11 17:28:59 2011 +0200
Merge branch 'RELENG_3_10' into RELENG_3_10_1
commit 9fd7dc07066ada2480407f433e44c1d506b8fe88
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 11 17:05:01 2011 +0200
set version number for release
-----------------------------------------------------------------------
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-11 15:40:15
|
- Log -----------------------------------------------------------------
commit 7af29009616eaf9cfd7b7c5c92bc40f639de83c4
Merge: f14b729 82abede
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 11 17:27:24 2011 +0200
Merge branch 'RELENG_3' into RELENG_3_10
commit f14b729176ae11685b300cc62cb86f49d5f7dd57
Author: Stevan Bajic <st...@ba...>
Date: Wed Aug 10 14:26:49 2011 +0200
Do not use (for now) static functions/variables when computing/reading virtual_table, virtual_uid, virtual_username and MySQLUIDInSignature
MFM: 30 days
Bug-ID: 3388293
Bug-Reported-By: Paul Cockings, Guillaume Hilt, Antal Kovacs
Security: none
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 7 +++-
README | 2 +-
RELEASE.NOTES | 56 ++++++++++++++---------------
src/mysql_drv.c | 107 ++++++++++++++++++++++++++++++++++++++++++++----------
4 files changed, 121 insertions(+), 51 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-11 15:39:45
|
- Log -----------------------------------------------------------------
commit 82abedee364a2157ed16188fb824f61a56136429
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 11 17:24:55 2011 +0200
update version number for next release
commit 2e9d902c91eb52fadbf8d9fc18891e07eb87d9d0
Author: Stevan Bajic <st...@ba...>
Date: Wed Aug 10 14:26:49 2011 +0200
Do not use (for now) static functions/variables when computing/reading virtual_table, virtual_uid, virtual_username and MySQLUIDInSignature
MFM: 30 days
Bug-ID: 3388293
Bug-Reported-By: Paul Cockings, Guillaume Hilt, Antal Kovacs
Security: none
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 7 +++-
README | 2 +-
RELEASE.NOTES | 56 ++++++++++++++---------------
src/mysql_drv.c | 107 ++++++++++++++++++++++++++++++++++++++++++++----------
4 files changed, 121 insertions(+), 51 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-11 15:39:18
|
- Log -----------------------------------------------------------------
commit d3f224916c7be42dbe87fc99fb353a6ec3ebc71e
Author: Tom Hendrikx <to...@wh...>
Date: Thu Aug 11 17:24:55 2011 +0200
update version number for next release
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 5 ++++-
README | 2 +-
RELEASE.NOTES | 56 +++++++++++++++++++++++++++-----------------------------
3 files changed, 32 insertions(+), 31 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Stevan B. <sb...@us...> - 2011-08-10 12:28:25
|
- Log -----------------------------------------------------------------
commit 2a2cd34348cb72a6a04c685d71e048a81e0f585c
Author: Stevan Bajic <st...@ba...>
Date: Wed Aug 10 14:26:49 2011 +0200
Do not use (for now) static functions/variables when computing/reading virtual_table, virtual_uid, virtual_username and MySQLUIDInSignature
MFM: 30 days
Bug-ID: none
Bug-Reported-By: none
Security: none
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 2 +
src/mysql_drv.c | 107 ++++++++++++++++++++++++++++++++++++++++++++----------
2 files changed, 89 insertions(+), 20 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-07 21:16:39
|
- Log -----------------------------------------------------------------
commit 2ecfb94affdd15eb1d962e1d044c67c49b7ea372
Author: Tom Hendrikx <to...@wh...>
Date: Tue Aug 2 11:53:17 2011 +0200
Add doc/cssclean.txt back to Makefile.
Reported-By: Julien Valroff <ju...@ki...>
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 3 +++
doc/Makefile.am | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Tom H. <why...@us...> - 2011-08-07 21:16:30
|
- Log -----------------------------------------------------------------
commit 82ca5d10b808d09387037e58677a1d3156f42bc8
Author: Tom Hendrikx <to...@wh...>
Date: Tue Aug 2 11:53:17 2011 +0200
Add doc/cssclean.txt back to Makefile.
Reported-By: Julien Valroff <ju...@ki...>
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 3 +++
doc/Makefile.am | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
hooks/post-receive
--
dspam
|
|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-03 08:08:08
|
On Wed, 03 Aug 2011 00:00:00 +0200 Tom Hendrikx <to...@wh...> wrote: > On 02/08/11 18:44, Ion-Mihai Tetcu wrote: > > On Tue, 02 Aug 2011 14:09:41 +0200 > > Tom Hendrikx <to...@wh...> wrote: > > > >> On 02/08/11 13:36, Ion-Mihai Tetcu wrote: > >>> On Tue, 2 Aug 2011 09:54:11 +0000 > >>> "Tom Hendrikx" <why...@us...> wrote: > >>> > >>>> > >>>> - Log > >>>> ----------------------------------------------------------------- > >>>> commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e Author: Tom > >>>> Hendrikx <to...@wh...> Date: Tue Aug 2 11:53:17 2011 > >>>> +0200 > >>>> > >>>> Add doc/cssclean.txt back to Makefile. > >>> > >>> Is this commit supposed to be merged down in RELENG_3 at some > >>> point? > >> > >> yes :) > > > > Thought so :) > > > >>> In this case please add a > >>> MFM:<TAB><TAB> N days > >>> to the commit message. The idea is to have all changes tested in > >>> MASTER, and after the appropiate period of time has passed, to > >>> have them merged in the stable branch; so the ``N'' is at > >>> committer's discretion, depending on the potential implact the > >>> change might have. > >> > >> This looks like some common practice I do not know about. Is there > >> any documentation where I can find more about this and other > >> practices? > > > > -admins ML archive, mostly. See the mails from 2009-04 - 2009-06 and > > 2009-07-13 - 2009-07-15. Ping me if you don't find the messages and > > I'll fw them. > > This is the closest thing > > http://sourceforge.net/apps/mediawiki/dspam/index.php?title=Create_new_release > > > >> I would also think that the way the RELENG branches are currently > >> structured, have some bigger plan behind it that I do not know > >> about. Again, any references to documentation on this would be > >> nice. > > > > The whole structure came from some discussion back then. > > > > A a side note, I think this way of using branches is more clear that > > odd/even-numbered releases some favor. > > I need to read up on the bigger idea behind the odd/even releases, There's none, really :) Some think that eg. odd release are experimental while even are stable. We don't follow this. IMO is a bad idea, it just lowers the bar from a QA/RE point of view. > but I see the way the branches are intended. While it makes sense for > our own work, I'd still not like to see users running a snapshot of > some RELENG branch from some undefined point in time. In the end, > they choose by themselves, but this is more about giving them too > much rope (apart from the additional work that needs to be done). IMMV ... > >>> This model would (theoretically, since we never really did the > >>> merging down in time) allow users to track a more stable branch > >>> that MASTER. > >> > >> I would opt for a micro release in less than a month, containing > >> this sort of issues that are likely to come up after people start > >> using the release. > > > > +1 > > > >> Supporting multiple branches is a nice idea but there is no > >> manpower to do so, I'm afraid (or else it would have been done in > >> the past). > > > > +1 > > > >> IMO there are typically 3 types of users: > >> 1) use only stable releases > >> 2) use git HEAD and know what they're doing > >> 3) use git HEAD (or stable releases with patches) because they are > >> forced to do so. > >> > >> If we keep the release cycle narrow, we can keep the number of > >> users in 3) down. > > > > Yes, indeed. > > > >> Users that insist on having a git version running, should be well > >> aware of the fact that they are doing so, and can always be > >> instructed to try today's HEAD before filing bugs. With the current > >> slow release cycle, this is problematic because there are too many > >> users in 3). > > > > The way I see it: > > - users like to run a release in production > > - users might need some patches sooner committed since the last > > release, but basically they don't want to risk big changes - > > they'd track a stable branch (eg. RELENG_3_10) > > > > Ah yes, I'm beginning to the reasoning behind it all. The RELENG_3 and > RELENG_3_10 are not only updated while working on a new release, but > also after bug fixes on earlier releases. Eventually, when enough bug > fixes have accumulatedin RELENG_3_10, you just branch RELENG_3_10_1 > from that, and release the tarball with all bug fixes. This makes it > easier to add new functionality to master without polluting the > bugfix releases. Exactly. We could have a script that would parse the commits for the MFM tags and send a reminder when the period has passed. > But regarding external users in need of specific patches: I'm used to > picking patches directly from master when I need them, like most > patch-savvy users I think. Yeh, but not all users are. More, if you pick one patch from MASTER, you'll have to check how the changes in it might interfere with the rest of the code, while checking out a branch is very straitforward. > >> When someone is distributing .deb packages based on git checkouts, > >> you know there's something wrong. > > > > I agree. The whole idea with the branches is to make minor releases > > easier to get out, by being conservative and consistent in what we > > merge down in stable branches. > > > >> Finally, sending out releases (even for trivial bugfixes, used with > >> caution) also shows to the general public that the project is > >> alive. This can only have positive effects on attracting users, > >> developers, distro inclusion, etc. > > > > Yes, yes, yes. :) > > > >>> Also, please give credits > >>> Reported-By:<TAB>..... > >>> > >> > >> I noticed I forgot to add his name to the commit message when I was > >> waiting for git push to complete. Better luck next time :/ > > > > If I'd be pedantic about it, I'd say do a force commit :) > > > > I tried to do this, merely as a means of getting more git voodoo. > I did git --amend on my latest commit, and git log looks fine after > that. But pushing the change to SF bails with an error, which sounds > logical: > > ! [rejected] master -> master (non-fast-forward) > error: failed to push some refs to > 'ssh://why...@ds.../gitroot/dspam/dspam' > To prevent you from losing history, non-fast-forward updates were > rejected > > git push --force sounds like the way to go, but I'd like to know for > sure before I break something :) Well, personally I dislike git and the "chaotic" model it seems to encourage. -- Ion-Mihai Tetcu <it...@Fr...> |
|
From: Tom H. <to...@wh...> - 2011-08-02 22:00:15
|
On 02/08/11 18:44, Ion-Mihai Tetcu wrote: > On Tue, 02 Aug 2011 14:09:41 +0200 > Tom Hendrikx <to...@wh...> wrote: > >> On 02/08/11 13:36, Ion-Mihai Tetcu wrote: >>> On Tue, 2 Aug 2011 09:54:11 +0000 >>> "Tom Hendrikx" <why...@us...> wrote: >>> >>>> >>>> - Log >>>> ----------------------------------------------------------------- >>>> commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e Author: Tom >>>> Hendrikx <to...@wh...> Date: Tue Aug 2 11:53:17 2011 +0200 >>>> >>>> Add doc/cssclean.txt back to Makefile. >>> >>> Is this commit supposed to be merged down in RELENG_3 at some point? >> >> yes :) > > Thought so :) > >>> In this case please add a >>> MFM:<TAB><TAB> N days >>> to the commit message. The idea is to have all changes tested in >>> MASTER, and after the appropiate period of time has passed, to have >>> them merged in the stable branch; so the ``N'' is at committer's >>> discretion, depending on the potential implact the change might >>> have. >> >> This looks like some common practice I do not know about. Is there any >> documentation where I can find more about this and other practices? > > -admins ML archive, mostly. See the mails from 2009-04 - 2009-06 and > 2009-07-13 - 2009-07-15. Ping me if you don't find the messages and > I'll fw them. > This is the closest thing > http://sourceforge.net/apps/mediawiki/dspam/index.php?title=Create_new_release > >> I would also think that the way the RELENG branches are currently >> structured, have some bigger plan behind it that I do not know about. >> Again, any references to documentation on this would be nice. > > The whole structure came from some discussion back then. > > A a side note, I think this way of using branches is more clear that > odd/even-numbered releases some favor. I need to read up on the bigger idea behind the odd/even releases, but I see the way the branches are intended. While it makes sense for our own work, I'd still not like to see users running a snapshot of some RELENG branch from some undefined point in time. In the end, they choose by themselves, but this is more about giving them too much rope (apart from the additional work that needs to be done). > >>> This model would (theoretically, since we never really did the >>> merging down in time) allow users to track a more stable branch that >>> MASTER. >> >> I would opt for a micro release in less than a month, containing this >> sort of issues that are likely to come up after people start using the >> release. > > +1 > >> Supporting multiple branches is a nice idea but there is no manpower >> to do so, I'm afraid (or else it would have been done in the past). > > +1 > >> IMO there are typically 3 types of users: >> 1) use only stable releases >> 2) use git HEAD and know what they're doing >> 3) use git HEAD (or stable releases with patches) because they are >> forced to do so. >> >> If we keep the release cycle narrow, we can keep the number of users >> in 3) down. > > Yes, indeed. > >> Users that insist on having a git version running, should be well >> aware of the fact that they are doing so, and can always be >> instructed to try today's HEAD before filing bugs. With the current >> slow release cycle, this is problematic because there are too many >> users in 3). > > The way I see it: > - users like to run a release in production > - users might need some patches sooner committed since the last > release, but basically they don't want to risk big changes - they'd > track a stable branch (eg. RELENG_3_10) > Ah yes, I'm beginning to the reasoning behind it all. The RELENG_3 and RELENG_3_10 are not only updated while working on a new release, but also after bug fixes on earlier releases. Eventually, when enough bug fixes have accumulatedin RELENG_3_10, you just branch RELENG_3_10_1 from that, and release the tarball with all bug fixes. This makes it easier to add new functionality to master without polluting the bugfix releases. But regarding external users in need of specific patches: I'm used to picking patches directly from master when I need them, like most patch-savvy users I think. >> When someone is distributing .deb packages based on git checkouts, you >> know there's something wrong. > > I agree. The whole idea with the branches is to make minor releases > easier to get out, by being conservative and consistent in what we > merge down in stable branches. > >> Finally, sending out releases (even for trivial bugfixes, used with >> caution) also shows to the general public that the project is alive. >> This can only have positive effects on attracting users, developers, >> distro inclusion, etc. > > Yes, yes, yes. :) > >>> Also, please give credits >>> Reported-By:<TAB>..... >>> >> >> I noticed I forgot to add his name to the commit message when I was >> waiting for git push to complete. Better luck next time :/ > > If I'd be pedantic about it, I'd say do a force commit :) > I tried to do this, merely as a means of getting more git voodoo. I did git --amend on my latest commit, and git log looks fine after that. But pushing the change to SF bails with an error, which sounds logical: ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'ssh://why...@ds.../gitroot/dspam/dspam' To prevent you from losing history, non-fast-forward updates were rejected git push --force sounds like the way to go, but I'd like to know for sure before I break something :) -- Tom |
|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-02 16:44:50
|
On Tue, 02 Aug 2011 14:09:41 +0200 Tom Hendrikx <to...@wh...> wrote: > On 02/08/11 13:36, Ion-Mihai Tetcu wrote: > > On Tue, 2 Aug 2011 09:54:11 +0000 > > "Tom Hendrikx" <why...@us...> wrote: > > > >> > >> - Log > >> ----------------------------------------------------------------- > >> commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e Author: Tom > >> Hendrikx <to...@wh...> Date: Tue Aug 2 11:53:17 2011 +0200 > >> > >> Add doc/cssclean.txt back to Makefile. > > > > Is this commit supposed to be merged down in RELENG_3 at some point? > > yes :) Thought so :) > > In this case please add a > > MFM:<TAB><TAB> N days > > to the commit message. The idea is to have all changes tested in > > MASTER, and after the appropiate period of time has passed, to have > > them merged in the stable branch; so the ``N'' is at committer's > > discretion, depending on the potential implact the change might > > have. > > This looks like some common practice I do not know about. Is there any > documentation where I can find more about this and other practices? -admins ML archive, mostly. See the mails from 2009-04 - 2009-06 and 2009-07-13 - 2009-07-15. Ping me if you don't find the messages and I'll fw them. This is the closest thing http://sourceforge.net/apps/mediawiki/dspam/index.php?title=Create_new_release > I would also think that the way the RELENG branches are currently > structured, have some bigger plan behind it that I do not know about. > Again, any references to documentation on this would be nice. The whole structure came from some discussion back then. A a side note, I think this way of using branches is more clear that odd/even-numbered releases some favor. > > This model would (theoretically, since we never really did the > > merging down in time) allow users to track a more stable branch that > > MASTER. > > I would opt for a micro release in less than a month, containing this > sort of issues that are likely to come up after people start using the > release. +1 > Supporting multiple branches is a nice idea but there is no manpower > to do so, I'm afraid (or else it would have been done in the past). +1 > IMO there are typically 3 types of users: > 1) use only stable releases > 2) use git HEAD and know what they're doing > 3) use git HEAD (or stable releases with patches) because they are > forced to do so. > > If we keep the release cycle narrow, we can keep the number of users > in 3) down. Yes, indeed. > Users that insist on having a git version running, should be well > aware of the fact that they are doing so, and can always be > instructed to try today's HEAD before filing bugs. With the current > slow release cycle, this is problematic because there are too many > users in 3). The way I see it: - users like to run a release in production - users might need some patches sooner committed since the last release, but basically they don't want to risk big changes - they'd track a stable branch (eg. RELENG_3_10) > When someone is distributing .deb packages based on git checkouts, you > know there's something wrong. I agree. The whole idea with the branches is to make minor releases easier to get out, by being conservative and consistent in what we merge down in stable branches. > Finally, sending out releases (even for trivial bugfixes, used with > caution) also shows to the general public that the project is alive. > This can only have positive effects on attracting users, developers, > distro inclusion, etc. Yes, yes, yes. :) > > Also, please give credits > > Reported-By:<TAB>..... > > > > I noticed I forgot to add his name to the commit message when I was > waiting for git push to complete. Better luck next time :/ If I'd be pedantic about it, I'd say do a force commit :) -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> it...@Fr..., PGP Key ID 057E9F8B493A297B |
|
From: Tom H. <to...@wh...> - 2011-08-02 12:09:58
|
On 02/08/11 13:36, Ion-Mihai Tetcu wrote: > On Tue, 2 Aug 2011 09:54:11 +0000 > "Tom Hendrikx" <why...@us...> wrote: > >> >> - Log >> ----------------------------------------------------------------- >> commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e Author: Tom Hendrikx >> <to...@wh...> Date: Tue Aug 2 11:53:17 2011 +0200 >> >> Add doc/cssclean.txt back to Makefile. > > Is this commit supposed to be merged down in RELENG_3 at some point? yes :) > In this case please add a > MFM:<TAB><TAB> N days > to the commit message. The idea is to have all changes tested in > MASTER, and after the appropiate period of time has passed, to have > them merged in the stable branch; so the ``N'' is at committer's > discretion, depending on the potential implact the change might have. This looks like some common practice I do not know about. Is there any documentation where I can find more about this and other practices? I would also think that the way the RELENG branches are currently structured, have some bigger plan behind it that I do not know about. Again, any references to documentation on this would be nice. > This model would (theoretically, since we never really did the > merging down in time) allow users to track a more stable branch that > MASTER. I would opt for a micro release in less than a month, containing this sort of issues that are likely to come up after people start using the release. Supporting multiple branches is a nice idea but there is no manpower to do so, I'm afraid (or else it would have been done in the past). IMO there are typically 3 types of users: 1) use only stable releases 2) use git HEAD and know what they're doing 3) use git HEAD (or stable releases with patches) because they are forced to do so. If we keep the release cycle narrow, we can keep the number of users in 3) down. Users that insist on having a git version running, should be well aware of the fact that they are doing so, and can always be instructed to try today's HEAD before filing bugs. With the current slow release cycle, this is problematic because there are too many users in 3). When someone is distributing .deb packages based on git checkouts, you know there's something wrong. Finally, sending out releases (even for trivial bugfixes, used with caution) also shows to the general public that the project is alive. This can only have positive effects on attracting users, developers, distro inclusion, etc. > > Also, please give credits > Reported-By:<TAB>..... > I noticed I forgot to add his name to the commit message when I was waiting for git push to complete. Better luck next time :/ -- Regards, Tom PGP key ID: 7D54EFF5 PGP key FP: C26F 374F 5E13 157B 5B42 7A1B 93DF 319D 7D54 EFF5 |
|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-02 11:36:47
|
On Tue, 2 Aug 2011 09:54:11 +0000 "Tom Hendrikx" <why...@us...> wrote: > > - Log > ----------------------------------------------------------------- > commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e Author: Tom Hendrikx > <to...@wh...> Date: Tue Aug 2 11:53:17 2011 +0200 > > Add doc/cssclean.txt back to Makefile. Is this commit supposed to be merged down in RELENG_3 at some point? In this case please add a MFM:<TAB><TAB> N days to the commit message. The idea is to have all changes tested in MASTER, and after the appropiate period of time has passed, to have them merged in the stable branch; so the ``N'' is at committer's discretion, depending on the potential implact the change might have. This model would (theoretically, since we never really did the merging down in time) allow users to track a more stable branch that MASTER. Also, please give credits Reported-By:<TAB>..... Thanks, -- Ion-Mihai Tetcu <it...@Fr...> |
|
From: Tom H. <why...@us...> - 2011-08-02 09:54:25
|
- Log -----------------------------------------------------------------
commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e
Author: Tom Hendrikx <to...@wh...>
Date: Tue Aug 2 11:53:17 2011 +0200
Add doc/cssclean.txt back to Makefile.
-----------------------------------------------------------------------
Summary of changes:
CHANGELOG | 3 +++
doc/Makefile.am | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
hooks/post-receive
--
dspam
|
