Merging Monolith to trunk

[Owen Winkler]

It has been said on IRC that if code lingers in a branch without moving
to trunk, then it is forgotten.

I'm interested in moving Monolith to trunk for the purposes of getting
other coders helping in producing it. I think that as a group the
majority is interested in seeing Monolith (or a derivative of Monolith
that is an improvement on the current admin design) happen, and I think
that as group, we should all work on achieving that. Letting the code
languish in a branch thinking that "someone else" will get to it and
make it happen is not going to get it done.

So here's one day's notice that you're about to see trunk break
exquisitely with the inclusion of Monolith branch code.

Owen

[GeirDM]

Hi, I'm new to Habari. Want to ditch the Automattic thing and get
involved with this project.
I'm going to check out Habari from the repository after work, but
seeing this message I think
I'll wait for the Monolith branch inclusion. I do have one question,
will I be able to try out
Habari locally with Monolith enabled? I mean, how much functionality
exists in the Monolith
branch at the moment?

GeirDM

[Graham Christensen]

GeirDM,
At the moment, I would check out the current Habari to see it's full
functionality. Monolith is currently in-development, and appears to have
about 50% of the functionality actually functional. Getting yourself
aquanted with the software would be a good first step, and then maybe
jump into the new source-code.
As was said before, the point behind this is to force everyone to
get more involved with Monolith, and drive development. Monolith is a
generally considered a great admin-interface, but we've just been
dragging our feet on writing the code.

Graham Christensen

http://itrebal.com - Customized Web Hosting
Graham.Ch...@iamgraham.net

[GeirDM]

On May 4, 2:02 am, Graham Christensen

<graham.christen...@iamgraham.net> wrote:
> GeirDM,
>     At the moment, I would check out the current Habari to see it's full
> functionality. Monolith is currently in-development, and appears to have
> about 50% of the functionality actually functional. Getting yourself
> aquanted with the software would be a good first step, and then maybe
> jump into the new source-code.
>     As was said before, the point behind this is to force everyone to
> get more involved with Monolith, and drive development. Monolith is a
> generally considered a great admin-interface, but we've just been
> dragging our feet on writing the code.
>
> Graham Christensen
>
> http://itrebal.com- Customized Web Hosting

> Graham.Christen...@iamgraham.net

Ok, thanks! I'll check out both the current version, and the new
containing the Monolith inclusion. Will try to soak up as much as I
possibly can of Habari through the current, and start to experiment a
little with the new. Hopefully I can contribute something along the
way. Looking forward to "getting my hands dirty"

GeirDM

[Michael Heilemann]

Great news!

My overly busy April is over, so I'm about ready to get into the fight as well. (Though I do not have trunk access).

--
Michael Heilemann
http://binarybonsai.com

[ringmaster]

On May 3, 6:56 pm, Owen Winkler <epit...@gmail.com> wrote:
>
> So here's one day's notice that you're about to see trunk break
> exquisitely with the inclusion of Monolith branch code.
>

Threat executed.

Owen

[Michael Bishop]

Michael,

Was the intention to move completely away from Blueprint? I'm seeing
some references to it (options, user, users, for example).
Specifically using the BP grid spans. And if we are going to keep BP
around, should we update to latest version?

~miklb

On May 4, 3:10 am, "Michael Heilemann" <heilem...@gmail.com> wrote:
> Great news!
> My overly busy April is over, so I'm about ready to get into the fight as
> well. (Though I do not have trunk access).
>
>
>
> On Sun, May 4, 2008 at 2:09 AM, GeirDM <gmart...@gmail.com> wrote:
>
> > On May 4, 2:02 am, Graham Christensen
> > <graham.christen...@iamgraham.net> wrote:
> > > GeirDM,
> > >     At the moment, I would check out the current Habari to see it's full
> > > functionality. Monolith is currently in-development, and appears to have
> > > about 50% of the functionality actually functional. Getting yourself
> > > aquanted with the software would be a good first step, and then maybe
> > > jump into the new source-code.
> > >     As was said before, the point behind this is to force everyone to
> > > get more involved with Monolith, and drive development. Monolith is a
> > > generally considered a great admin-interface, but we've just been
> > > dragging our feet on writing the code.
>
> > > Graham Christensen
>

> > >http://itrebal.com-Customized Web Hosting

[Michael Heilemann]

On Mon, May 5, 2008 at 7:07 AM, Michael Bishop <miklb....@gmail.com> wrote:

Michael,

Was the intention to move completely away from Blueprint?  I'm seeing

No, parts of it are being used throughout, like reset and font stuff.

[Michael Bishop]

but what about the spans? reserving those for certain elements? as I
mentioned, the options page is using them, and a few of the other
pages that you didn't provide mocks for like user, users, logs are
using them, and before tackling them, I'd like a general sense of
which to use.

~miklb

So should we go ahead and update BP to the latest stable tag then?


On May 5, 2:14 am, "Michael Heilemann" <heilem...@gmail.com> wrote:
> On Mon, May 5, 2008 at 7:07 AM, Michael Bishop <miklb.onl...@gmail.com>

[Michael Heilemann]

I think it'd be a good idea to get the latest stable.

In the Monolith CSS there's a percentage-based column system, which I'm personally partial to. It might be worth using that instead of the BP one, if that's what you're asking?

[Rich Bowen]

Since I'm roughly two days behind in reading email, a one-day notice didn't do me a lot of good. But them's the breaks.

Would you be so good as to define "break exquisitely" in rather more specific detail, for those of us who are running live site(s) out of trunk? In what way, specifically, will it break?

On a more general, philosophical note, why would we choose to merge something into trunk if we know it's going to break things? Surely the goal would be to merge trunk into the branch, and get that working, before merging the resulting (functional) changes back into trunk. Isn't that what branches are for?

--

Happiness isn't something you experience; it's something you remember.

Oscar Levant

[Owen Winkler]

Rich Bowen wrote:
>
> Would you be so good as to define "break exquisitely" in rather more
> specific detail, for those of us who are running live site(s) out of
> trunk? In what way, specifically, will it break?

There are areas in the admin that do not function as well as they had
previously. For example, the interface for comment moderation is not
yet (last I looked?) connected to the back end. The backend continues
to persist as it has and should not affect the outward site at all.

> On a more general, philosophical note, why would we choose to merge
> something into trunk if we know it's going to break things? Surely the
> goal would be to merge trunk into the branch, and get that working,
> before merging the resulting (functional) changes back into trunk. Isn't
> that what branches are for?

I covered this in my original message:

> I think that as a group the
> majority is interested in seeing Monolith (or a derivative of Monolith
> that is an improvement on the current admin design) happen, and I think
> that as group, we should all work on achieving that. Letting the code
> languish in a branch thinking that "someone else" will get to it and
> make it happen is not going to get it done.

I don't know what basis there is for assuming that trunk will always be
functional. Although we should strive to make that the case, I think
it's expected especially during major changes such as this that things
not be 100% working. If you're looking for 100%, tags is the place to look.

Owen

[Rich Bowen]

On May 5, 2008, at 12:13, Owen Winkler wrote:

I don't know what basis there is for assuming that trunk will always be 
functional.  Although we should strive to make that the case, I think 
it's expected especially during major changes such as this that things 
not be 100% working.  If you're looking for 100%, tags is the place to look.

I think this attitude made sense before we had public releases. It makes less sense over time, and even seems contradictory. We should strive to make trunk functional, but nobody expects that we'll achieve this, so it's ok to intentionally break it? Doesn't strike me as consistent.

I'm well aware that I'm in the minority on this topic. But I think there's a significant gap between "we can't always expect it to work, because it's leading edge", and "let's intentionally break it so that people are motivated to work on it." In many projects committing broken code to trunk is grounds for immediate rollback.

--

"There are two kinds of light--the glow that illuminates, and the glare that obscures."

James Thurber

[Scott Merrill]

> I'm well aware that I'm in the minority on this topic. But I think there's a
> significant gap between "we can't always expect it to work, because it's
> leading edge", and "let's intentionally break it so that people are
> motivated to work on it." In many projects committing broken code to trunk
> is grounds for immediate rollback.

The discussion on IRC prior to Owen's email announcing his intention
was quite divided on this subject. Some felt very strongly that
committing Monolith in its current state was a huge disservice. I
don't necessarily disagree with that sentiment.

The other group felt strongly that getting more eyes looking at bugs
would get Monolith whipped into shape far faster than anything else.
It's sat in the branch relatively untouched by the majority of users
and developers. I don't necessarily disagree with this position,
either.

I don't think there's any intention to make this the standard mode of
operation. I think Monolith represents an anomaly in Habari
development. I think the result of the merge has been largely
successful: a flurry of incremental patches submitted by lots of
concerned participants. More people are now familiar with the
Monolith code, and said code is quickly improving into a usable state.

I hear your concerns, and I share them to a degree. It was my
understanding that we're still in "commit, then review", so I think
Owen's action was acceptable, especially in light of the warning.
Perhaps more warning would have been beneficial, and gotten some
action in the branch prior to the merge. We can use this as a
learning opportunity for the next time a major change needs to be
integrated.

Cheers,
Scott

[Sean T Evans]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think, that considering we have public releases, which we are
maintaining, it's should be _more_ acceptable to break trunk. The SVN
repository is, in my mind, a development environment. The goal is to
have development happen there. If the goal of a given user is to have a
stable application, they should use the public releases. In my mind,
keeping something out of trunk simply because it will break things
hinders growth. Owen's logic, as he presented it in IRC (and as I
understood it) was that the branches are places where people with a
specific interest in a chunk of code can experiment without risk,
whereas trunk is where the community as a whole is able to focus on
advancing Habari as a whole. Monolith had reached the stage where it
needed more attention to advance significantly and that other portions
of the project needed the aid of a more "finalized" admin design.
Therefore, broken or not, it was ready to move to trunk.

That's why, when this merge was suggested I found myself being in
support of the idea. Obviously, as a non-coder, and as someone who does
not run any of my sites off of SVN, I suffer the negative aspects of
this much less than some others. But from my point of view, this was the
correct decision for the community as a whole.

- --
Sean T. Evans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIH1yomQpMBUWJpdsRAvlPAJ0blxCw1ENGT8Lno+U/8CcH0Hn1HQCgtdbP
6qJvAQ95vndmCVaLCBwfGY8=
=wpva
-----END PGP SIGNATURE-----

[Rich Bowen]

A few more remarks on this topic, if I may.

1) The notion that code "languishes in a branch" is, I believe, an artifact of the very harmful attitude that this branch is "owned" by someone. If people are interested in the branch, they should `svn switch` to the branch and see what it does. When there's this notion that the branch is owned by one person, and other people are encourage to keep their filthy mitts off, that's what breeds languishment.

2) I found the warning message insufficient, for three reasons.

a) The time period wasn't enough for everyone to see it

b) If you're going to announce that it's going to break things, tell us what those things are. Be specific.

c) If you know it's going to break things, then why not instead enumerate those things and encourage people who care about them to svn switch and fix them in branch?

But, it's done, and perhaps there's actual benefit that I'll see when I svn up, or perhaps I'll regret it when I svn up. Time will tell. However, as the code gets progressively more complicated, each time I look at it I understand it less. Perhaps I should just switch to the latest tag and leave it at that until life is a little less busy.

I'll be sure to post effusive glowing praise when I svn up and all my grumpy-old-man-ness is dissipated in the ponies and rainbows of Monolith.

--

Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end of the bar.

Edward R. Murrow

[Christian Mohn]

The problem was, and has been, that nothing happened in the branch. Forcing this out in the open did bring an initial spur of commits and fixes, and that can’t really be a bad thing. You are correct in the assessment of branches being “owned” and in this particular case something had to be done to make it move forward. I believe this was the right step to take at this point. It’s probably not the best way in all cases, but this time I think it was, and still is, a good idea.

 

Christian

[Andy C]

Does it actually work ?

The only Monolith option I can get to work is 'Logout'.

Using FF3b5, I get assorted 'Undefined index' when trying to do
anything else.

[Andy C]

This looks like Ticket #294 'Monolith dashboard links don't work.' Nor
do drugs by the way.

The patch was supposedly applied in r1651 but the issues is still
present in r1652 for me at least.

[Chris J. Davis]

The other problem we have now, is that with Monolith in trunk Mike
can no longer work on it as he has since the beginning. Sure we can
tell him to submit patches, but what we have effectively just done is
reward his effort, which he gave a lot of, with less authority.

I don't really care a rats ass about what people think of him
personally right now. This has nothing to do with personal feelings.
We just took a giant step backwards and I for one am not happy about
it. Not to mention that everyone is ignoring him in IRC at the
moment. We decided on the branches model so that people could
contribute while not having access to trunk, it was not only a good
way to help people come into the cabal, but a great way to have new
code created, tested and included.

Mike stopped no one from contributing in the monolith branch, he
reverted no changes. To say that he owned that branch is bullshit.
The community decided he owned it, largely based on conduct from
people on this list.

Mike is my friend, so this is pissing me off more than it probably
should, but sometimes a good pissed off is what is needed. We need to
do something now. Is this how we want to go forward? I for one am not
in favor of this ever happening again. How about everyone else?

Chris

On May 5, 2008, at 4:44 PM, Andy C wrote:

>
> Does it actually work ?
>
> The only Monolith option I can get to work is 'Logout'.
>
> Using FF3b5, I get assorted 'Undefined index' when trying to do
> anything else.
>
> On May 5, 9:39 pm, "Christian Mohn" <h0b...@gmail.com> wrote:
>> The problem was, and has been, that nothing happened in the
>> branch. Forcing
>> this out in the open did bring an initial spur of commits and
>> fixes, and
>> that can't really be a bad thing. You are correct in the
>> assessment of
>> branches being "owned" and in this particular case something had
>> to be done
>> to make it move forward. I believe this was the right step to take
>> at this
>> point. It's probably not the best way in all cases, but this time
>> I think it
>> was, and still is, a good idea.
>>
>> Christian
>>

[Chris J. Davis]

I just noticed that this went to the public list, which wasn't my
intent, but right now, I don't really care. The community is the
project and from time to time, I think we should share what we are
wrestling with in the PMC. If this bothers you, you have my apologies.

Chris

[Arthus Erea]

> The other problem we have now, is that with Monolith in trunk Mike  
> can no longer work on it as he has since the beginning. Sure we can  
> tell him to submit patches, but what we have effectively just done is  
> reward his effort, which he gave a lot of, with less authority.

I agree with this... Mike should have the ability to have strong
authority over a project he created and founded. Plus, it is very
tedious for work to continue with every single little change having to
get a ticket and patch opened for it.


That being said, I think the intendend purpose of energizing monolith
development has been successful: just look at the sheer amount of
changes right now.

I think an ideal solution would be to put monolith in a branch but
place much more focus on it: make it a community priority.

[Michael Heilemann]

If anyone felt I 'owned' the Monolith branch, I'm puzzled. I would say that I was sorry, except I don't remember ever doing anything to keep people away from it. In fact, I on several occasions invited people to pop in and commit to it in whatever form they could and had time for. And other than that, I did my best to make sure people on this list had some idea what was going on in there, since I if nothing else felt responsible for Monolith as long as I was its main contributor.

I'm happy that it's in trunk. More work has been done on it over the weekend than in all of last month (where I was absent, writing a screenplay). If nothing else.

[Owen Winkler]

Rich Bowen wrote:
>
> 1) The notion that code "languishes in a branch" is, I believe, an
> artifact of the very harmful attitude that this branch is "owned" by
> someone. If people are interested in the branch, they should `svn
> switch` to the branch and see what it does. When there's this notion
> that the branch is owned by one person, and other people are encourage
> to keep their filthy mitts off, that's what breeds languishment.

There is no such notion that a branch is for one person to work on. If
anyone had that impression, that's their mistake - we have given branch
access so far to anyone who has asked. Perpetuating this myth is what's
truly harmful.

People have been interested and enthusiastic about what the branch
provides, but have been unwilling to switch to the branch to contribute
to its development. I think this is because they are under the
impression that some unnamed group of other people is working on the
features they're looking forward to. This is very similar to the
Bystander Effect. See:

http://en.wikipedia.org/wiki/Bystander_effect

> 2) I found the warning message insufficient, for three reasons.
> a) The time period wasn't enough for everyone to see it

24 hours has been the required timeframe for other things in the past.
It seems unwise to update to the latest revision without reading the dev
list or commit log. I'm not sure what benefit waiting longer provides,
assuming people prudently read the logs or stage before running head
code on live servers.

Even if you fail to read the logs and update anyway, you can always
execute `svn up -r1610` to go to a revision that doesn't include the
monolith changes until they are complete enough to keep up with head.

> b) If you're going to announce that it's going to break things, tell us
> what those things are. Be specific.

I should have thought of that. Was my subsequent reply to this question
sufficient?

> c) If you know it's going to break things, then why not instead
> enumerate those things and encourage people who care about them to svn
> switch and fix them in branch?

We did as you suggested and it didn't work, most likely due to the
bystander effect noted above. I've lobbied excessively on IRC to get
people working on the branch, and we saw very little action.

Assuming there are people interested but apparently unwilling to help
unless the code is unavoidable, how else do we convince them to work on
the code they want unless they have no other choice? I know I'm not the
only person guilty of committing things that I knew would incite other
people to change them.

Owen

[Sean T Evans]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris J. Davis wrote:
> The other problem we have now, is that with Monolith in trunk Mike
> can no longer work on it as he has since the beginning. Sure we can
> tell him to submit patches, but what we have effectively just done is
> reward his effort, which he gave a lot of, with less authority.
>
> I don't really care a rats ass about what people think of him
> personally right now. This has nothing to do with personal feelings.
> We just took a giant step backwards and I for one am not happy about
> it. Not to mention that everyone is ignoring him in IRC at the
> moment. We decided on the branches model so that people could
> contribute while not having access to trunk, it was not only a good
> way to help people come into the cabal, but a great way to have new
> code created, tested and included.
>
> Mike stopped no one from contributing in the monolith branch, he
> reverted no changes. To say that he owned that branch is bullshit.
> The community decided he owned it, largely based on conduct from
> people on this list.
>
> Mike is my friend, so this is pissing me off more than it probably
> should, but sometimes a good pissed off is what is needed. We need to
> do something now. Is this how we want to go forward? I for one am not
> in favor of this ever happening again. How about everyone else?
>
> Chris
>

First, let me say that I think Monolith is great, I have since the first
time I sat and watched the very long screen cast and read the pdf that
came with it. I still think it's brilliant and will completely change
what people expect from their blogging platform. I also think that
Michael Heilemann has done some fantastic things with it and that he
should be proud that it was considered important enough to push into
core before it was 100% complete.

That said, I think that the line between Heilemann and what he has
created is being blurred in this discussion. The contribution he has
made to the application is fantastic, and I want to be very clear that I
feel that way. But the question isn't "should we give _Monolith_ access
to our core code." it's "should we give Michael Heilemann access to our
core code." And that a discussion that was happening on the PMC list.
Give the very open nature of our community (perhaps in this instance a
bit more open than some people would like, thanks to Chris's misdirected
message.), we try very hard to keep as little as possible on the PMC
list. In the interest of fairness to the community, I'd like to give my
reasons for why I voted against this access.

I want to make it very, very clear that I'm speaking only for myself.
Not for the PMC, not for the Community, not for anyone else in favor of
or opposed to Michael, Monolith, Ponies or Bunnies. Also, I want to make
clear that I am speaking from the perspective of someone who doesn't
code, doesn't really know how to even view a branch, and (shamefully)
doesn't even manage to put out the level of work that I think I should,
let alone what anyone else does.

My objection stems from my perception that when Monolith was presented
it was presented as "This is how this should be done." The process up to
that point did not involve the community and the presentation had an air
of "This is what I'm doing, admire it (and it is admirable) and I'll get
back to you when it's done." At that point there was some discussion of
if Monolith, as great as it was, was worth the sacrifice of our
community model. It was decided that as young a Community as we are, and
as new as this model is to some (or all) of us, a lot of flexibility was
warranted. It was also noted that, because of the nature of major design
decisions, we needed a way that people could explore ideas and work
through them so that we could find a working balance between community
consensus and the horrors of "design by committee". This was when
opening up branches to non-PMC developers was hit upon as a compromise.
It was hoped that by more closely integrating these "spur projects" we
would help people more closely integrate themselves into the community,
as the projects that they worked on were more closely integrated. From
my point of view, I don't see that this has happened with Monolith. From
my perspective the ownership issue isn't that other people didn't feel
like they could work on Monolith (and if there were people who did, I
don't feel that Michael is in any way to blame for that) but that I
didn't see any involvement from Michael with anything other than
Monolith. I understand that between "scratching your own itch" and the
fact that he has a passion for what he's doing with Monolith, Michael's
Habari-related effort is directed at that. However, because his efforts
are so focused, I don't feel that he's had the opportunity to become an
integral part of the community _as a whole_. And that is the basis of
why I opposed giving him access to trunk at this time.

I think both Monolith and Micheal Heilemann are great for Habari, and I
want to see both of them become an even greater part of what we're
doing. I also understand that we need a way to reward for great work
people separately from PMC membership. And I'm greatful for the passion
that people in this community have for this project as well as for their
friendships. In the end, I think it's that passion for doing what's best
for the community that will keep us going, even if we don't always agree
what "best" is.

This project is still young. We're still learning to walk, and we're
going to trip every now and then and sometimes when we run, we're going
to fall on our faces. But as long as we get up, try again, and learn
something from the experience, in the end, skinned knees and all, it'll
be worth it. (How's that for torturing an analogy.)

With Respect,

Sean T. Evans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIH4rEmQpMBUWJpdsRAg6fAKCeW4Vwt8ibdV09VYJ4lB4dVHZmxACeJni5
NDVf/meJC6tGGvxF3I7roSA=
=1Q47
-----END PGP SIGNATURE-----

[Owen Winkler]

Sean T Evans wrote:

> It was hoped that by more closely integrating these "spur projects" we
> would help people more closely integrate themselves into the community,
> as the projects that they worked on were more closely integrated. From
> my point of view, I don't see that this has happened with Monolith. From
> my perspective the ownership issue isn't that other people didn't feel
> like they could work on Monolith (and if there were people who did, I
> don't feel that Michael is in any way to blame for that) but that I
> didn't see any involvement from Michael with anything other than
> Monolith. I understand that between "scratching your own itch" and the
> fact that he has a passion for what he's doing with Monolith, Michael's
> Habari-related effort is directed at that. However, because his efforts
> are so focused, I don't feel that he's had the opportunity to become an
> integral part of the community _as a whole_. And that is the basis of
> why I opposed giving him access to trunk at this time.

I think that the use of branches in development was absolutely essential
for collaborative development on large and complex additions to the
code. I don't think that the purpose of the branches is to foster
community integration. Rather, I think the willingness to be
community-integrated is a prerequisite for the desire to employ a branch.

That monolith was in a branch at all demonstrates precisely the kind of
community-mindedness that I would not expect from someone with the
self-centered mentality I've heard Michael being accused of.

As for working only within monolith, I'm not sure what suggestion you're
making for how he could become involved with the community "as a whole".
Surely you wouldn't expect him to write user documentation or code
database access? With what limited time we all have, should we expect
people to work on things outside of their comfort zone or interest? I
think absolutely not. I can think of a few people in the PMC who focus
on a single thing, and that's served the community well.

Michael's expertise is in design. He has shared his time and effort
with our community, and in a way that others can contribute, too. He's
been willing to guide other contributors in the design process of the
admin by providing interface guidelines. He hangs out on IRC as his
time permits, and answers questions pertaining to design in our mailing
lists. In spite of early sentiments conveyed, I think he's demonstrated
an adequate and active willingness to do what it takes to be a part of
our community. And in this paragraph, I haven't yet referred to the
substantial body of work in the monolith code.

I think it's a shame that all this is somehow not enough, and I'm hoping
that someone can tell me in explicit terms what he's going to have to do
to prove himself. I can't figure it out.

Owen

[Raman Ng (tinyau)]

On Tue, May 6, 2008 at 4:44 AM, Andy C <andy...@gmail.com> wrote:

Does it actually work ?

The only Monolith option I can get to work is 'Logout'.

Using FF3b5, I get assorted 'Undefined index' when trying to do
anything else.

I have encountered this problem in my testing environment and I found that the cause of this problem is blogroll plugin.  After I deactivated it, the admin dashboard is running properly.


--
Cheers,
Raman (tinyau)
Blog: http://blog.tinyau.net

[Raman Ng (tinyau)]

On Tue, May 6, 2008 at 7:27 AM, Raman Ng (tinyau) <tinyau....@gmail.com> wrote:

On Tue, May 6, 2008 at 4:44 AM, Andy C <andy...@gmail.com> wrote:

Does it actually work ?

The only Monolith option I can get to work is 'Logout'.

Using FF3b5, I get assorted 'Undefined index' when trying to do
anything else.

I have encountered this problem in my testing environment and I found that the cause of this problem is blogroll plugin.  After I deactivated it, the admin dashboard is running properly.

I mean remove it from the plugins folder.  :P

[Rich Bowen]

On May 5, 2008, at 16:54, Chris J. Davis wrote:

Mike stopped no one from contributing in the monolith branch, he  
reverted no changes. To say that he owned that branch is bullshit.   
The community decided he owned it, largely based on conduct from  
people on this list.

Yes, well, that was precisely what I was referring to - people's perception. Of course he didn't actually own it. I had commit access to his branch, and could have tinkered with it at any moment. The trouble is the *perception* that he owns it. Not entirely certain how to counteract that belief, since I'm not entirely sure how it sprang up in the first place.

--

http://feathercast.org/

[Christopher Davis]

I apologize Rich, I was torked out of shape quite a bit, and it seemed as though you were saying that.

Chris

[Matt Read]

> I have encountered this problem in my testing environment and I found
> that the cause of this problem is blogroll plugin. After I
> deactivated it, the admin dashboard is running properly.

This is true, the blogroll plugin causes errors in the menu. Blogroll
adds to the menu for the manage and publish menus, but the menu
structure in Monolith is completely changed. The Plugin just needs to be
updated to return the proper menu arrays.

[Andy C]

I don't use the blogroll plugin but I think the 'monthly archives'
plugin may have a similar problem. When I deactivated that plugin, I
was finally able to see what all the fuss was about :-)

>  signature.asc
> 1KDownload

[Raman Ng (tinyau)]

On Wed, May 7, 2008 at 12:19 AM, Andy C <andy...@gmail.com> wrote:

I don't use the blogroll plugin but I think the 'monthly archives'
plugin may have a similar problem. When I deactivated that plugin, I
was finally able to see what all the fuss was about :-)

Monthly Archives doesn't add any custom menu to dashboard.  I have Monthly Archives plugin activated without any problem.

[Rich Bowen]

On May 5, 2008, at 16:15, Rich Bowen wrote:

I'll be sure to post effusive glowing praise when I svn up and all my grumpy-old-man-ness is dissipated in the ponies and rainbows of Monolith.

So, for the record, I 'svn up'ed, and it didn't break anything. Well, sure, my theme broke, but that happens almost every time I update, so that wasn't unexpected or upsetting.

The admin interface is certainly different, but doesn't appear to either lack any features I had before, or have any nre ones, so the "break exquisitely" warning seemed a little over the top. There are various widgets in the admin interface with no readily discernible function, but as far as I can tell, they all have tickets open about them.

So, in all, it was a fairly uneventful 'svn up', which is, as always, a pleasure. Rather than having everything break, I rather, instead, found myself wondering what all the controversy was about.

As always, impressed with the quality of code that the Habari community produces.

--Rich

--

"Reality is that which, when you stop believing in it, doesn't go away." (Philip K. Dick)

[Michael Bishop]

I wonder if you would have had the same response if you svn upped a
week or so ago ;)

~miklb

[Michael C. Harris]

I've read this just before going to bed. I laughed and it put me in a
good mood, for several reasons. I second Michael's comment though -
if you feel so inclined you should have a look at the number of
commits since the merge :)

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog