You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Brett Porter <br...@gmail.com> on 2005/08/15 01:09:02 UTC
temporarily disable nags for Directory in gump?
Hi,
Having looked at the recent problems with Apache Directory, I can't
immediately fix them. The checkout is locked and I don't have access
to vmgump. I hadn't been tracking these since it moved from brutus.
While you might want to look into automating svn cleanup on locked
checkouts, I'm proposing we disable the directory descriptors (or at
least the nags) for now. There seem to be a steady flow of problems in
the build that are not actually broken builds.
This would just be until such time as:
a) somebody else in the gump tree depends on directory libraries (at
which point gump becomes useful as a regression test, and it is worth
the effort to keep them up to date, but at the moment nothing does)
b) gump3 goes live which should be able to read the maven descriptors
directly which should just mean that nags are actually things broken,
not gump integration issues
Any thoughts?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: temporarily disable nags for Directory in gump?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Brett Porter wrote:
>Hi,
>
>Having looked at the recent problems with Apache Directory, I can't
>immediately fix them. The checkout is locked and I don't have access
>to vmgump. I hadn't been tracking these since it moved from brutus.
>
>While you might want to look into automating svn cleanup on locked
>checkouts, I'm proposing we disable the directory descriptors (or at
>least the nags) for now. There seem to be a steady flow of problems in
>the build that are not actually broken builds.
>
>
Right this is the reason why I want notifications turned off. There's no
gain atm from gump. Also no one is willing to maintain it for
directory. I'd rather move on to more modern tools.
>This would just be until such time as:
>a) somebody else in the gump tree depends on directory libraries (at
>which point gump becomes useful as a regression test, and it is worth
>the effort to keep them up to date, but at the moment nothing does)
>
>
+1
>b) gump3 goes live which should be able to read the maven descriptors
>directly which should just mean that nags are actually things broken,
>not gump integration issues
>
>
>
+1
>Any thoughts?
>
>
I couldn't agree with you more. How can we turn gump off for the moment
or at least turn off the nag notifications? Is there a switch someone
can turn off?
Alex
Re: temporarily disable nags for Directory in gump?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 15 August 2005 14:13, Brett Porter wrote:
> > Would you like access?
>
> If you trust me to poke around without damaging anything when a
> project goes down, I'm happy to go in and fix it again - sure.
They trusted me, so you'll be Ok :o)
> > Heck, would you like to be on the Gump PMC?
>
> I have to admit my interests lay with getting projects to play
> together more than the implementation of gump itself, so I'm not sure
> I could do that justice :)
Brett seems to fit "my profile" and since I stopped due to "lost the morale"
when the huge success percentage drop occurred, I am sure he will be a great
addition to the team.
Cheers
Niclas
Re: temporarily disable nags for Directory in gump?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 15 August 2005 14:13, Brett Porter wrote:
> > Would you like access?
>
> If you trust me to poke around without damaging anything when a
> project goes down, I'm happy to go in and fix it again - sure.
They trusted me, so you'll be Ok :o)
> > Heck, would you like to be on the Gump PMC?
>
> I have to admit my interests lay with getting projects to play
> together more than the implementation of gump itself, so I'm not sure
> I could do that justice :)
Brett seems to fit "my profile" and since I stopped due to "lost the morale"
when the huge success percentage drop occurred, I am sure he will be a great
addition to the team.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: temporarily disable nags for Directory in gump?
Posted by Brett Porter <br...@gmail.com>.
On 8/15/05, Leo Simons <ma...@leosimons.com> wrote:
> Would you like access?
If you trust me to poke around without damaging anything when a
project goes down, I'm happy to go in and fix it again - sure.
> Heck, would you like to be on the Gump PMC?
I have to admit my interests lay with getting projects to play
together more than the implementation of gump itself, so I'm not sure
I could do that justice :)
(also not sure if you are serious :)
> leosimons@vmgump:/usr/local/gump/public/workspace/directory-naming$ svn
> cleanup
> svn: '' is not a working copy directory
>
> Could you be more specific?
I was just going off of:
http://vmgump.apache.org/gump/public/apacheds/gump_work/update_apacheds.html
naming is fine, but appears to be under a cvs subdirectory of workspace:
http://vmgump.apache.org/gump/public/gump_repo/gump_work/update_directory-naming.html
> If that's what you really want. Just comment out the <nag/> elements in the
> descriptors and no e-mail will be sent.
Ok, we can discuss that at greater length on directory-dev. I just
wanted to get your opinion on the matter.
> I'll point out that in general if your build "keeps breaking" (rather than
> being broken all the time) that's because it keeps changing in
> non-compatible ways. I know I've always have had loads of trouble getting it
> all to compile everytime I tried to look at it. Directory does have a
> problem there.
Agreed - that should settle as the individual parts stabilise. But as
they chase each others development it will be a problem without a
monolithic build. Again, I might put this to the list as a separate
item.
There is an additional problem in having to maintain two descriptors,
which seems to be where a lot of the breakages come from. The addition
of dependencies is often needing to be hunted down and added to gump.
That could also be viewed as a good thing to take addition of
dependencies more seriously, but a hassle when its already been well
considered. I guess the thing about it is that even if it isn't a big
deal, it is annoying that a perfectly legitimate build will break
under gump.
> Oh, and the second bit I'll mention is that it seems no-one ever pays
> attention to the builds for their project unless they get e-mail, so
> there'll probably be a 'hump' to get over once you get back to sending
> yourself e-mail :-)
So densensitized to warning mails now, that I think that's an issue
either way :)
> There's a few example of bigger maven-based builds (for example I know about
> Excalibur) that tend to build fine.
Yep, I don't think there is anything wrong with the Maven support.
> Mind you -- that's still going to be a while.
for gump3, sure - but hopefully some other projects will find
directory stuff useful soon. I've already seen talk of MINA on the
incubator list today...
Thanks for your feedback Leo.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: temporarily disable nags for Directory in gump?
Posted by Brett Porter <br...@gmail.com>.
On 8/15/05, Leo Simons <ma...@leosimons.com> wrote:
> Would you like access?
If you trust me to poke around without damaging anything when a
project goes down, I'm happy to go in and fix it again - sure.
> Heck, would you like to be on the Gump PMC?
I have to admit my interests lay with getting projects to play
together more than the implementation of gump itself, so I'm not sure
I could do that justice :)
(also not sure if you are serious :)
> leosimons@vmgump:/usr/local/gump/public/workspace/directory-naming$ svn
> cleanup
> svn: '' is not a working copy directory
>
> Could you be more specific?
I was just going off of:
http://vmgump.apache.org/gump/public/apacheds/gump_work/update_apacheds.html
naming is fine, but appears to be under a cvs subdirectory of workspace:
http://vmgump.apache.org/gump/public/gump_repo/gump_work/update_directory-naming.html
> If that's what you really want. Just comment out the <nag/> elements in the
> descriptors and no e-mail will be sent.
Ok, we can discuss that at greater length on directory-dev. I just
wanted to get your opinion on the matter.
> I'll point out that in general if your build "keeps breaking" (rather than
> being broken all the time) that's because it keeps changing in
> non-compatible ways. I know I've always have had loads of trouble getting it
> all to compile everytime I tried to look at it. Directory does have a
> problem there.
Agreed - that should settle as the individual parts stabilise. But as
they chase each others development it will be a problem without a
monolithic build. Again, I might put this to the list as a separate
item.
There is an additional problem in having to maintain two descriptors,
which seems to be where a lot of the breakages come from. The addition
of dependencies is often needing to be hunted down and added to gump.
That could also be viewed as a good thing to take addition of
dependencies more seriously, but a hassle when its already been well
considered. I guess the thing about it is that even if it isn't a big
deal, it is annoying that a perfectly legitimate build will break
under gump.
> Oh, and the second bit I'll mention is that it seems no-one ever pays
> attention to the builds for their project unless they get e-mail, so
> there'll probably be a 'hump' to get over once you get back to sending
> yourself e-mail :-)
So densensitized to warning mails now, that I think that's an issue
either way :)
> There's a few example of bigger maven-based builds (for example I know about
> Excalibur) that tend to build fine.
Yep, I don't think there is anything wrong with the Maven support.
> Mind you -- that's still going to be a while.
for gump3, sure - but hopefully some other projects will find
directory stuff useful soon. I've already seen talk of MINA on the
incubator list today...
Thanks for your feedback Leo.
- Brett
Re: temporarily disable nags for Directory in gump?
Posted by Leo Simons <ma...@leosimons.com>.
On 15-08-2005 01:09, "Brett Porter" <br...@gmail.com> wrote:
> Having looked at the recent problems with Apache Directory, I can't
> immediately fix them. The checkout is locked and I don't have access
> to vmgump. I hadn't been tracking these since it moved from brutus.
Would you like access? Heck, would you like to be on the Gump PMC?
> While you might want to look into automating svn cleanup on locked
> checkouts,
Aye.
leosimons@vmgump:/usr/local/gump/public/workspace/directory-naming$ svn
cleanup
svn: '' is not a working copy directory
Could you be more specific?
> I'm proposing we disable the directory descriptors (or at
> least the nags) for now. There seem to be a steady flow of problems in
> the build that are not actually broken builds.
If that's what you really want. Just comment out the <nag/> elements in the
descriptors and no e-mail will be sent.
I'll point out that in general if your build "keeps breaking" (rather than
being broken all the time) that's because it keeps changing in
non-compatible ways. I know I've always have had loads of trouble getting it
all to compile everytime I tried to look at it. Directory does have a
problem there.
Oh, and the second bit I'll mention is that it seems no-one ever pays
attention to the builds for their project unless they get e-mail, so
there'll probably be a 'hump' to get over once you get back to sending
yourself e-mail :-)
There's a few example of bigger maven-based builds (for example I know about
Excalibur) that tend to build fine.
> This would just be until such time as:
> a) somebody else in the gump tree depends on directory libraries (at
> which point gump becomes useful as a regression test, and it is worth
> the effort to keep them up to date, but at the moment nothing does)
> b) gump3 goes live which should be able to read the maven descriptors
> directly which should just mean that nags are actually things broken,
> not gump integration issues
Mind you -- that's still going to be a while.
- Leo
Re: temporarily disable nags for Directory in gump?
Posted by Leo Simons <ma...@leosimons.com>.
On 15-08-2005 01:09, "Brett Porter" <br...@gmail.com> wrote:
> Having looked at the recent problems with Apache Directory, I can't
> immediately fix them. The checkout is locked and I don't have access
> to vmgump. I hadn't been tracking these since it moved from brutus.
Would you like access? Heck, would you like to be on the Gump PMC?
> While you might want to look into automating svn cleanup on locked
> checkouts,
Aye.
leosimons@vmgump:/usr/local/gump/public/workspace/directory-naming$ svn
cleanup
svn: '' is not a working copy directory
Could you be more specific?
> I'm proposing we disable the directory descriptors (or at
> least the nags) for now. There seem to be a steady flow of problems in
> the build that are not actually broken builds.
If that's what you really want. Just comment out the <nag/> elements in the
descriptors and no e-mail will be sent.
I'll point out that in general if your build "keeps breaking" (rather than
being broken all the time) that's because it keeps changing in
non-compatible ways. I know I've always have had loads of trouble getting it
all to compile everytime I tried to look at it. Directory does have a
problem there.
Oh, and the second bit I'll mention is that it seems no-one ever pays
attention to the builds for their project unless they get e-mail, so
there'll probably be a 'hump' to get over once you get back to sending
yourself e-mail :-)
There's a few example of bigger maven-based builds (for example I know about
Excalibur) that tend to build fine.
> This would just be until such time as:
> a) somebody else in the gump tree depends on directory libraries (at
> which point gump becomes useful as a regression test, and it is worth
> the effort to keep them up to date, but at the moment nothing does)
> b) gump3 goes live which should be able to read the maven descriptors
> directly which should just mean that nags are actually things broken,
> not gump integration issues
Mind you -- that's still going to be a while.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org