Sigh, honestly I found a pain following patching activities in the devel tree.
Bugzilla is not the best, but at least in other projects I find
patches and patch updates attached to every single bug before committing.
Maybe you should seriously consider to adopt a decent bug tracking
system, else packaging activity is really a tragedy...
Just my 2cents.
--
Francesco P. Lovergine
Hi,
I asked Markus about this some time a go. He din't sed "no". I also
hope to see some more useful bug tracking system in future. Migration
from old mailinglists to new (grass-user,grass-dev) could be a good
time to change other things as well.
I also wote for Bugzilla.
Maris.
2006/1/31, Francesco Paolo Lovergine <frankie@debian.org>:
Sigh, honestly I found a pain following patching activities in the devel
tree.
Bugzilla is not the best, but at least in other projects I find
patches and patch updates attached to every single bug before committing.
Maybe you should seriously consider to adopt a decent bug tracking
system, else packaging activity is really a tragedy...Just my 2cents.
--
Francesco P. Lovergine_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
On 1/31/06, Francesco Paolo Lovergine <frankie@debian.org> wrote:
Sigh, honestly I found a pain following patching activities in the devel tree.
Bugzilla is not the best, but at least in other projects I find
patches and patch updates attached to every single bug before committing.
Do you mean to create patch file and send it to bugtracker before commit.
That is too much work in my opinion.
Radim
Maybe you should seriously consider to adopt a decent bug tracking
system, else packaging activity is really a tragedy...Just my 2cents.
--
Francesco P. Lovergine_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
On Wed, Feb 01, 2006 at 10:05:34AM +0100, Radim Blazek wrote:
On 1/31/06, Francesco Paolo Lovergine <frankie@debian.org> wrote:
> Sigh, honestly I found a pain following patching activities in the devel tree.
> Bugzilla is not the best, but at least in other projects I find
> patches and patch updates attached to every single bug before committing.Do you mean to create patch file and send it to bugtracker before commit.
That is too much work in my opinion.
Well, bug solutions should be sufficiently atomic to allow that. That's
not required for main development, but is extremely useful in bug
tracking for the stable tree.
--
Francesco P. Lovergine
On Tue, Jan 31, 2006 at 11:01:14PM +0200, M?ris Narti?s wrote:
Hi,
I asked Markus about this some time a go. He din't sed "no".
Hi,
note that the bugtracker is hosted at Intevation. Bernhard
proposed to implement a new bugtracker, but I don't know if
he started to do so.
I also
hope to see some more useful bug tracking system in future. Migration
from old mailinglists to new (grass-user,grass-dev) could be a good
time to change other things as well.
What do you mean here? Please explain.
Markus
I also wote for Bugzilla.
Maris.
2006/1/31, Francesco Paolo Lovergine <frankie@debian.org>:
> Sigh, honestly I found a pain following patching activities in the devel
> tree.
> Bugzilla is not the best, but at least in other projects I find
> patches and patch updates attached to every single bug before committing.
> Maybe you should seriously consider to adopt a decent bug tracking
> system, else packaging activity is really a tragedy...
>
> Just my 2cents.
>
> --
> Francesco P. Lovergine
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Hi,
2006/2/1, Markus Neteler <neteler@itc.it>:
Hi,
note that the bugtracker is hosted at Intevation. Bernhard
proposed to implement a new bugtracker, but I don't know if
he started to do so.
Any reason why it cannot be hosted at grass.itc.it site?
> I also
> hope to see some more useful bug tracking system in future. Migration
> from old mailinglists to new (grass-user,grass-dev) could be a good
> time to change other things as well.What do you mean here? Please explain.
Markus
I refer to "[GRASS5] Rename of development mailing list?"
http://grass.itc.it/pipermail/grass5/2006-January/020655.html
If there is new server, new names for mailing lists, adding yet
another important change - bugzilla - would be right in time - one BIG
change, one announcement. People would more easy adapt such changes -
"Oh, look, they have new mailing lists, bug tracking system and new
stable version..." All at once - so nobody could miss that.
Radim:
Do you mean to create patch file and send it to bugtracker before commit.
That is too much work in my opinion.
I agree, but IMHO just a notification from bugzilla when bug is closed
with fix in CVS could be enough to keep track on fixes for stable
versions.
Just another 2 c:
bugzilla is useful to tracking code submissions by developers w/o
write access to CVS. This way works Gentoo bugzilla. New ebuild first
is submitted as bug, then users/developers interested in it make tests
etc. and when it looks OK, bug gets closed as ebuild moves to portage.
I hope this time everybody will understand what I was trying to say 
Maris.
On Tue, Feb 07, 2006 at 11:53:41AM +0200, M?ris Narti?s wrote:
Hi,
2006/2/1, Markus Neteler <neteler@itc.it>:
> Hi,
>
> note that the bugtracker is hosted at Intevation. Bernhard
> proposed to implement a new bugtracker, but I don't know if
> he started to do so.Any reason why it cannot be hosted at grass.itc.it site?
No technical reason at least.
It's historically hosted at intevation.de.
Now, in the light of the new foundation there will probably be
the option/request to move code management to a centralized
foundation infrastructure.
Of course an agreement on which bug tracking system to use is
pending. This will be discussed in the near future.
> > I also
> > hope to see some more useful bug tracking system in future. Migration
> > from old mailinglists to new (grass-user,grass-dev) could be a good
> > time to change other things as well.
>
> What do you mean here? Please explain.
>
> MarkusI refer to "[GRASS5] Rename of development mailing list?"
http://grass.itc.it/pipermail/grass5/2006-January/020655.htmlIf there is new server, new names for mailing lists, adding yet
another important change - bugzilla - would be right in time - one BIG
change, one announcement. People would more easy adapt such changes -
"Oh, look, they have new mailing lists, bug tracking system and new
stable version..." All at once - so nobody could miss that.
Good point.
I have to check with the foundation ideas - we don't want too many
changes in case the GRASS community intends to use the foundation
infrastructure (once provided).
However, I suggest to move the user list to grass.itc.it as soon as
possible.
Radim:
>Do you mean to create patch file and send it to bugtracker before commit.
>That is too much work in my opinion.I agree, but IMHO just a notification from bugzilla when bug is closed
with fix in CVS could be enough to keep track on fixes for stable
versions.
Maybe Intevation could implement this into the existing RT?
Just another 2 c:
bugzilla is useful to tracking code submissions by developers w/o
write access to CVS. This way works Gentoo bugzilla. New ebuild first
is submitted as bug, then users/developers interested in it make tests
etc. and when it looks OK, bug gets closed as ebuild moves to portage.I hope this time everybody will understand what I was trying to say
Yes, understood now. This sounds reasonable to me.
Markus
On Tue, Feb 07, 2006 at 10:44:51PM +0100, Markus Neteler wrote:
>
> I agree, but IMHO just a notification from bugzilla when bug is closed
> with fix in CVS could be enough to keep track on fixes for stable
> versions.Maybe Intevation could implement this into the existing RT?
> Just another 2 c:
> bugzilla is useful to tracking code submissions by developers w/o
> write access to CVS. This way works Gentoo bugzilla. New ebuild first
> is submitted as bug, then users/developers interested in it make tests
> etc. and when it looks OK, bug gets closed as ebuild moves to portage.
>
> I hope this time everybody will understand what I was trying to sayYes, understood now. This sounds reasonable to me.
Yes, that was also my intended idea. Single/alternative patches could be
tested well before committing, also by users for instance.
I would also add - but I know I'm pretending so much - that probably a
different SCM could be considered. SVN for instance works better with
patchsets and alternative trees in respect with CVS...
--
Francesco P. Lovergine
On Sun, Feb 19, 2006 at 11:44:08AM +0100, Francesco Paolo Lovergine wrote:
On Tue, Feb 07, 2006 at 10:44:51PM +0100, Markus Neteler wrote:
> >
> > I agree, but IMHO just a notification from bugzilla when bug is closed
> > with fix in CVS could be enough to keep track on fixes for stable
> > versions.
>
> Maybe Intevation could implement this into the existing RT?
>
> > Just another 2 c:
> > bugzilla is useful to tracking code submissions by developers w/o
> > write access to CVS. This way works Gentoo bugzilla. New ebuild first
> > is submitted as bug, then users/developers interested in it make tests
> > etc. and when it looks OK, bug gets closed as ebuild moves to portage.
> >
> > I hope this time everybody will understand what I was trying to say
>
> Yes, understood now. This sounds reasonable to me.
>Yes, that was also my intended idea. Single/alternative patches could be
tested well before committing, also by users for instance.
I would also add - but I know I'm pretending so much - that probably a
different SCM could be considered. SVN for instance works better with
patchsets and alternative trees in respect with CVS...
Our idea at Intevation is to offer our gforge installation with SVN
to GRASS development. We currently ironing out some problems
with gforge (and SVN), before I think it is the best time for a move for GRASS.
Note that the jump to SVN will put some stress on GRASS developers,
as CVS was used the first time for them in GRASS, so there will
be a learning curve.